Grow Your Team In 90 Days
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Gore-Schaefer, Cheryl
So you want to work with an awesome ruby developer? Great! But finding one is hard. It’s much easier to hire that apprentice or bootcamp grad, but that person is not an awesome developer. How do you help them get there? You will learn how to build a learning plan and become the best mentor to a budding software developer. You have the opportunity to mold your apprentice’s skill set into exactly what you need, while benefiting from their diverse skills and experiences. We will build an example learning plan of a developer learning Ruby, showing clear and specific choices and likely outcomes.
 Good to see you all here. Thanks for coming. It's 420. And we're going to talk about some strategies to help you mentor new developers. Let's just talk about me. I'm Cheryl Schaefer. You might have guessed from the program. I was a flute teacher and a performer. I have a master's degree in music. Of course, being a musician, I also worked a bunch of other jobs. I did photography. I was an optician. I worked for some dentists. I had a lot of opportunities to learn different domains of knowledge. I started in software by going to local meetups with my brother Chris. I took a couple of classes at the local university. Then there was a meetup that started in my town for women that I started attending. From there, I got an apprenticeship at LaunchCode, which is a non-profit. I was working under Mike Many. I've been there for almost two years now. And recently I recently mentored my first hire. LaunchCode, the non-profit, is basically serving unemployed or underemployed adults, like working towards upward mobility, helping people get their first tech job. And offers a lot of free education opportunities. But if about me, let's talk about you. You could maybe use some help. It's hard to find enough people to help you. Beginners cost a lot less. Plus, you can make sure they use the right editor. And we all know that teams of people with diverse skills levels and experiences really do produce better software. You can build that team around you. In part of that process, you're going to learn and grow yourself. Kind of like metaprogramming. You set them going and they will produce more people. And then it just turns into this greatness there. I'm not going to talk about interviewing right now, but if you want to talk about how do you interview people who without degrees and stuff, you can come catch me later. But so we already found someone. I'm thinking of gender neutral names like Chris, Pat. Let's say we found a Sam. Meet Sam. I know what you're thinking. What I really meant was any hobbit who would follow Gandalf. Sam is driven and smart and talented. But they don't have a degree or maybe it's something else. They went to a boot camp or a launch code class. Maybe Sam actually did a project in C sharp or Java or something and they don't know Ruby yet. You could probably get HR to give Sam a chance, but they're going to have to prove themselves and show that they can really learn and really do it. How can you help them be successful? One way is to build a learning plan together. Especially if you've got someone who like I said did something else for their stack. So I think there's a couple things to this whole learning plan that I'd like to bring out first. So really this is about Sam, this isn't about you as a mentor. And so everything you think about as you work with them is focused on Sam and Sam's choices. And maybe how Sam feels. They're most successful when they feel responsible, when they feel challenged and when they feel confident. If Sam says to you I need to do this, I can really do it if I try hard, I can meet this challenge. That's when you know Sam's going to make it. So it helps to be flexible if you can make your plan flexible enough to adjust for Sam's learning styles. And Sam's learning tricks are going to work better for themselves than yours will work for them. So you want to try and encourage Sam to make self-assessments. So you don't need to do the assessment. Sam makes the assessment. What you provide is framing. You're going to tell them context and ideas that they don't know about yet. You want to tell them what to think. This is kind of a delicate line. But figure out what questions they can ask. So let's pause here for a second. Because this is the most often asked question that I get talking about different kinds of mentoring and code reviews and things. The first thing that happens when you start mentoring is they're showing somebody, you're showing somebody code and they look at you and nod. Somebody has mentored here. Uh-oh. He says, can you interpret what that means? I don't know what it means when you nod, but I do it a lot when other people are helping me through code I don't know yet. It means I'm paying attention. It doesn't mean I understand yet. It doesn't mean I won't if you keep going the way you are. But it doesn't mean I will either. So people start asking questions. Do you know what this means? Is this going to return a string or a symbol? That's better than not asking any questions, but it's not really asking the right kind of questions. If it can be answered with a yes or a no, you didn't learn anything about them by asking that question. Try and ask something more vague, especially when you don't know where they are at all. What do you know about strung parameters instead of do you know how strung parameters works? If you ask something general like that, you're going to get a much more nuanced conversation. You can lead them towards what you think they need to know. You'll be able to find out right away how to direct your efforts. What level of detail are they aware of? You don't waste your time on stuff they already know and it's boring to them, but you don't talk over their head if, oh, I just worked on something old and I don't know that yet. So avoid yes and no questions. So basically, it's trying to empower Sam. Sam is not ready for Valorog yet, but they can hold that Orc inventory off for you while you fight the demon. And then Sam will eventually grow into this awesome dev who can fight demons too. It's very big and you're going to improve Sam's chances of success. So there's four main activities we're going to talk about, like how you're going to steer the ship, setting big goals, like figuring out, identifying what it is you want to accomplish is the first step. And then making sure that you've devoted adequate time and resources so that it's achievable. And then we're going to cycle back and forth between this little circle of assessing what they've done, what you want to do, reprioritizing what you want to do, and acknowledging when you've succeeded. And then once in a while cycle back. So step one, we're going to set some goals. Identifying what it is we want to do. Sit down with someone, the person who wants to learn, who's asked you for help. And say, what is it that you want help with? If they just say I want a job, that's maybe not super helpful. But you can always suggest one. Well, I know Ruby. You could get a job in Ruby. You want to be an awesome Ruby dev. I think that'd be awesome. But try and get Sam to suggest some ideas. What do you think it means to be awesome at Ruby? What are some adjacent skills that you're going to need? You can't just do Ruby all day. It'd be great. But you need other things too. You need a little bash. Try to get Sam to write a lot of things. Figure out, oh, I want to be full stack. I hear that one a lot. I want to do the full stack. You don't know what you're asking for. But okay, yeah, it sounds like fun. And then Sam can keep asking stuff. You want to learn how to write tests? That's great. Get fast with your editors. Oh my gosh. Oh my gosh. There's so many things we could do. It's so great. Oh my god. It's out of control. This is actually my list. No, it is actually. But that's a great sign. It's a great sign. You've got a curious, a bright mind. All those things sound awesome to me too. You've let the constraints go. You're free. You could learn anything. Don't fall for the ambiguity effect. Are you guys familiar with the ambiguity effect? Raise your hand if you know the ambiguity effect. The ambiguity effect is one of those strawman arguments where it's like, I don't know what I don't know yet. It must not be that much. It's not that important. I probably couldn't do it anyway. It's kind of like a self-defacing sort of, I should have made a slide about that too. It's basically like limiting your horizons based on where you are now. So just break free of that. You could do anything. And we're just organizing it right now. So let's organize it. Let's set it up. Okay. All right. As much as I want to know how to speak Japanese and go talk to my hats, I did have dinner with them. But I don't know Japanese yet. It's not really important if you're working on a Ruby job. So organize your time by the things that are distractions right now. That's not saying you'll never learn them. It's just like, I'm not actually going to work on that right now. Organize them by the things I'm going to work on. And those two are in a category that's important and it's going to take a lot of time. And that's the first category there the most time. And then, you know, okay, I'm going to read some special stuff about pair programming, some blog articles or whatever. But it's not going to take as long to learn how to do that. And I'm going to practice that sort of implicitly anyway. So I don't need to explicitly practice, like read as much on that as I do different design patterns. So these things will take less time. These things will take more time. And we're going to organize the learning plane around these topics. So that way, the topics that you're learning on are the topics that you need. So you don't waste any time on topics that somebody else says are important, but they aren't applicable to your situation. So here's the hard part, breaking it down. For this style of like the apprenticeship for them, we do, you're going to spend some time pairing with them and code reviewing, I'm sure, anyway. And to do this plan, like you need probably an hour every week, like just a meeting together, where you can have a conversation. Especially at first, you're going to take probably, I don't know, I just guessed out here, half a day to assess new resources that will go down. The more people you talk to because you already assessed some of those resources, Sam's going to have to put the bulk of the work in, right, the one learning. And you know, laptops, subscriptions, maybe you need to order some books, that kind of stuff. And you know, you're maybe going to have a little reduced, like some opportunity cost and reduced capacity from you as a dev while you're pairing with Sam and doing stuff that's like a little bit easier that Sam's going to be able to understand at first. And then where are you going to organize our plan in? I don't actually really care. People talk about this, like, of the people I've talked about this, this is probably like the biggest like, oh, what could I use? We could have fun with this. I could make my own thing. Ah, it doesn't matter. The little cards are cool. But as long as you can go both get in there, add things and check them off, you know, don't make it too perfect until you've done at least two or three people and then, you know, you can start breaking it down. I just change stuff so much between people that I don't even use anything fancy. So all right. Thinking more of big thoughts about the plan. So the plan is actually Sam's. So you're going to need to release ownership of the plan. That's hard because you want to make choices about the plan. But what we want to do is guide Sam to make the right choices instead of making choices ourselves. So the plan belongs to Sam. Even if Sam's going to make some wrong steps, let them do it. Maybe not like a big wrong step, but some small wrong steps, you know, protect them from the big wrong steps. Do lots of little steps and then that way if they make a wrong step, they can see that error themselves and correct it. You want to make it a list of to-do items and every one of them should apply like the topic of every one of them. You're going to learn something that was one of those topics in the previous slide. So as you assess resources, pick ones that are exactly what you want to learn. Make sure that they're not too long. You don't want anything, especially the beginning, that takes more than a couple of hours to complete if it's going to take like a big book. You're going to read Sandy Metz's photo book. That's a great goal for the end, but the first couple of weeks don't do it. It's too easy to get lost. And another big point is your capacity to learn varies a lot by method of transmission. So you've just worked nine hours today on your laptop. That blog post is great or that screencast is great, but your eyes are going to be fatigued. The paper book might be a better choice, just maybe pick one chapter at a time instead of the whole thing. But print it out even. Print out your blog article. Sorry, trees. It'll be great. Sorry, trees, but it'll be great for your learning. So assessing learning tools. And that's what I'm talking about is like just collecting screencasts and blog articles and that kind of thing. Podcasts that you listen to, books that you've read, things on online places like edX or Coursera. Assess them for quality effectiveness and speed of use. So the main thing to think about when you're assessing things is not to just be like, oh, this is about SQL. They need to know some SQL. Here you go. You should read it first. And then think, okay, what will Sam be able to do after learning the concepts that this presents? Will they be able to learn those concepts the way that it's been presented here? What exactly topic does it cover? Okay, it's on SQL. You need to know some SQL. Okay, is it accurate? How dated is it? That's a big deal for us, right? How thorough is it? Who is the author? What was the person's motivation to create this resource? It's great if you just want to share, and that's what we'd like to do is just share our knowledge, right? But maybe somebody is a little skewed one way or the other for some other reason. Compare the difficulty of the material to Sam's current output. And here's a good one. So I'm just talking, right? And I'll do this at the end. Does it link other resources? Some do and some really don't at all. If it leads you on a journey like that, it shows that it's a lot more, it's showing you like what you can learn next, and it's more legitimate. You can prove that the things that they've said are true, or here's an argument for, here's an argument against. Here's some evidence that would lead us to believe that. And then the format thing. Is it on paper? Is it a print? How long is it going to take Sam to complete? And is it interesting? Is it going to engage them so that they stick with it and learn? It makes it easier for you to stick with it and learn. So we'll sit together and come up with a list. You should probably come up with a list the first week. And I just threw together one that was like full of some stuff that I've done for a few other people to use for this talk. And I just didn't cheat because it's really easy for me to give you a link there. So get a list of things that you would want to know the topics that they're about. Pick a few. Like here's one about Ruby. Here's one about learning. Here's some Rails and Web and Unix. Okay, great. And then put those together and make sure it's a little bit more than they're going to be able to get done that week. Give them a little bit of a stretch room. So it's not like, okay, it's a deadline. Here's where you get done. You're going to work through a little bit every day and see how far you can get. Grab one from each topic and then mix in some things you need urgently. You may not be able to do that as much at the beginning, but as you go down, hey, I need this CSV import. Okay, here's a blog article about how that library works. But make it so that it's easy to just grab one, click the link, read it, and do it. A checklist, really. And to learn the concepts inside of it. So that's the first big steps towards empowering SAM. SAM is ready to go. SAM is going to get this done. The next thing to consider, though, is that we're managing them at work, too, right? That's going to affect SAM's outcome a lot. So let's talk about it. When you're selecting, like, what stories SAM is going to do, what ones you're going to pair together on, you know, I usually was selecting the work, the learning around the stories I knew were coming. But sometimes you can do the other way around. You can select the work around what they've learned. So go for it. Try and pair program with them as much as you can. That's probably the most important thing. Although that turns out to be a really difficult thing to measure. I try to get some stuff on that at work. It's just tough to measure because everyone defines it slightly differently. But if you can get time with you pairing it with them, especially if you can get other people that are a varied experience level to pair with the apprentice or the, you know, junior person you've just started, it takes a village. If you can get, like, a more experience of wide range, they can see how each person deals with things slightly differently and learn from that. And of course, I'm all about trial by fire. Go for what really matters. If it doesn't, if it matters, why aren't you going for it? Try and get some code live their first day if you can. I mean, at least the first week, get something live so they can point and be like, that was me, I did it, I can do this. And build that trust with SAM and with your coworkers that, you know, I'm going to let you take some small missteps, but I'm going to guide you away from the big cliff edge. So your coworkers know they're going to take care of SAM and SAM knows you're going to help take care of them. One other thing, try and keep their work exciting. Don't give them intern work. It's boring. And code reviews. There's so many resources online. I'm not going to talk too much about that. But I think it's a great feedback mechanism to measure the success in learning. When I was teaching, that was always the thing, right? Everybody wants to take a quiz. Everybody wants to take a test. It stresses them out. You don't have to do that. They wrote code. There's an artifact right there. Right? You don't have to make them make a test. It's great. It's already there. Sandwich the criticism between complaints. Like, tell them what they're doing well as well as telling them what they're not doing well. Ask the questions and then see if you can get them to explain to you how they might fix it. Maybe you can choose between two or three different paths. That's a great way to teach them stuff. But if they really don't know what's going on, give them a bunch of exemplars. Show them examples of somebody else's code, even on some other project, and provide some context. Like, I think they chose this code here because they're under a time limit. It works. But if I had time, I would do it this way. Here's another example. So they can understand when a decision is going to be called bad by someone and when it's going to be called the same decision might otherwise be called good. There's some more resources about this in the downloadable plan that I've included at the end. So they hop on and check off things as they complete them. You go hunt for more resources and add them to the bottom of the list. And then, you know, they start adding stuff too. Maybe they've found. And then once a week, have a check-in. They're checking meeting. And discuss how everything's going. They can brain dump on you. This is what I thought about this article. I didn't understand this thing about whatever here, the joins, what happened. And then maybe you can adjust your resource collection based on that feedback. So you make that as immediate as possible. Okay. So maybe at the beginning, you're feeling a little overwhelmed. I don't know how well you can see Sam in that picture. He's looking overwhelmed. So let's talk about how to prioritize your work. There's so much to learn. You may have heard this. President Eisenhower said, I have two kinds of problems, the urgent and the important. The urgent are not important and the important are never urgent. So this is popularized by the book Seven Habits of Highly Effective People. If you imagine urgency on the x-axis and importance on the y, you can see, okay, maybe we need that CSB important by Tuesday, but CSB imports aren't that important for them to learn. It's really important that they learn about dependency management or something. So that's kind of a good way to throw out things that you don't need. Let's scope it down a little bit, and then once you've combined those into the things that are important and urgent and the things that are important as in your priority level, then you can also add that axis of cost and say, okay, this is really important. It's really urgent and it's cheap. Just do it. And then the big high cost items, you're going to want to split across multiple weeks so that you hit it a little bit every time and that's going to add up over the time. So keep doing that every week. They keep learning. You keep checking in with them. And then every month or so, every four weeks, I would say, do a check in on your larger goals and reassess. Are we working towards Rails and Ruby? Or did they end up doing a lot of server scripting? Is what we end up doing actually what we thought we needed at the beginning? Maybe we steered off and maybe that is actually where we should have steered to begin with, or maybe we just need to strain back out. So in the middle, it can be a little depressing. You're working towards a big goal and it's hard. Maybe that's a little overwhelming. The dragon's coming. You can see him. He's here. Let's try and stay positive. Here, I have a nice little chart there. At first, you knew you were going to lose some capacity to training and it can kind of feel impossible. But you're at the big point of the trilogy. Please go up from here. By the end, you can see you're doing so much more than you were at the beginning. See my completely made up chart. Actually, okay. It's not really completely made up. This is actually story points of my capacity. It was later around 20 and then we brought on Dave. And then Dave got super independent and here we're way above where I was by myself already. But I was right here and so it's hard to feel positive right when you're down here. But this part is coming. It kind of looks like the big dipper. It happens to the apprentices too. I did that part too but it's been a little longer ago. So at Launch Code where we do surveys of people who are going through the apprenticeship program because they're working at different companies so it's like it's hard to stay communicating with them. So we send them stuff. Find out how they're doing. Mostly so we can intervene if somebody's in trouble. But we're also getting this general rating and I always wondered what was going on with that. So we did this little study of it. This data has been normalized. This is actually the response data from people. It's normalized over the length of the apprenticeship. So if it took six weeks or if it took 20 that's 100% of the length of time. And the ratings are also normalized. So we removed people who only answered once and things like that. Or if you answered like exactly the same every time we took that out. And what it shows really is that they actually feel really like it's going up the whole time as they start to realize how well they could do. That's really great. And this is also only successful apprentices. That's like 90 something percent. So that's pretty much almost all of them anyway. So it's trending up. They're getting happier with a little range of doubt because our numbers aren't like super high on responses. Who wants to fill out surveys right. But you have these outliers. Do you see these little guys down here at the bottom. That person made it. But they felt so bad. Oops. We went around here. Sorry guys. This person here felt bad. And these people here they felt bad. Oh my gosh. But they made it. So they just didn't know what they didn't know. And they didn't know. You know there was like that moment of doubt and that imposter syndrome happening sometime in the middle. It could happen anytime. But it can be overcome. So how can you overcome that. Here we are. We're software developers but we're managing people's motivation. That's what you have to do to communicate right. So there's a lot of confusion about this but I'll go over it really fast. Reinforcement attempts to increase behaviors you want. Punishment you're attempting to reduce and eliminate behaviors you don't want. And both of these can be negative or positive. And negative is removing a thing. So like negative reinforcement a lot of people who when they first get this kind of a job are really happy. The negative reinforcement happens naturally. They had an income straw that you removed. Now they have room for hope. But you want to try and do we want to try and do positive reinforcement because that's the strongest motivator right. But how can you apply this to software. I think it's still shaping even if it's whatever you're in. It can be as simple as that compliment you gave them on the code review. Don't just point out the flaws in the code review. Any time they're working like I found this article on Active Record and you need to use that and then you should recognize work in that direction. Or point it out in front of other person. Morning stand up tell them oh Sam already finished that whole book. Can you believe that. That's awesome. Sometimes this is called success of approximation it works on yourself. Use it. It works on your pets. Use it. It works on your spouse. I mean nothing. Sorry honey. But the point that you need to come across to use this correctly so you don't like just end up being happy all the time right. Wait. No. The point so that it actually changes behavior is that once you've done the same correct thing that's closer to correct but it's not exactly correct you start reducing one of these dimensions of strength. They don't get rewarded every single time maybe like oh that's great. Instead of talking about it for ten minutes latency I don't have to explain that to you guys. You just wait to respond that reduces the strength of that response and so then they're going to have to go a little they're going to try to try a little harder get a little more accurate to achieve that same level of response again and then that's how you can change the behavior in the direction you want to go. So Sam is starting to feel confident. Sam has been working. Sam is getting there. Week eight time for another big points check in. How's it going? You can start to introduce some more like complicated things and larger books and like you should subscribe to this podcast instead of just check off items like read this one blog article. If you're doing the contract a higher type situation you should talk about it but even if you're not this is like a one this is like a project right. So see if we're going to make our 90 day goal. If you don't think we are see if you can scope it down a little bit you know maybe we wanted to be full stack but that's kind of a lot of stuff maybe you could just do one side for the first 90 days and then learn the other one. What if we added a couple of weeks or maybe four weeks could we make it then? I mean if it's just a week or two add it. But if they are make sure you tell them they are you know keep working hard you can push through this let's go. Same thing if you do anything. Same thing if you do anything. By week 12 it should be like just a couple of things left. What absolutely must be finished if it doesn't absolutely have to be finished get it off there. There's still going to be a junior developer when they're done with this but they're going to be so much like need less direct support and have gotten so much knowledge out of this. See if there's some kind of symbol of success that you can directly tie to completion. So with the apprenticeship things most people will convert then they get a title they switch to salary things are great. If it's a private type thing situation like you're just helping someone on the side come up with some kind of symbol of success and then that like gives that moment at the end. You reach the end of the video game and it gave you this vast screen it seems like an easy and small thing but it matters so much. And celebrate celebrate enjoy tell other people how Sam succeeded tell them how Sam succeeded you know maybe you're a humble brag at a level Sam succeeded. Oh yeah I did I did too. And when you're done to take some time off before your next thing both of you give yourself some introvert time introvert for a while. It's not sustainable to do this level of work long term. Sam probably used up some asks from family and friends just to maintain this level of work. But most people cycle back in as their lives allow to allow for their progress in their careers that we want to help other people too. And it's so rewarding to see that kind of compounding like pay it forward stuff that you know I help this person and they help these three people and now there's like 20 people who are all like grand babies basically. By the way I did not make this shit up. That's a lot of stuff to have made up though honestly like most of this is based on my own experiences and it's basically what I did to my flu students just on software. And what Mike Benet did to me at launch code thanks Mike. Here's some springboards where you can go learn more about these things and of course there's always the Google search to just find everything else that you might want to know but then you don't have that assessment that has already been checked out by me. One other thing I touched upon we talked about a little bit about learning strategies being flexible to allow theirs. It's not the focus of this talk so I don't really want to take questions on these but I'd be really happy to discuss them later. Really what I mean by that is things that they address like specific behaviors you can do to address one type of issue. So it applies probably to some group of people like 10 or 20% of people but it's not relevant to other people. That's what I mean when I say like learning strategies. For example if you have trouble like staying focused or you can't break focus people will set a timer. Oh I can set a 25 minute timer and I can keep myself focused and no one to break. That's really helpful but for people who don't have a problem with that it's kind of like a waste of time. There are so many of those things. We've been here for a long time. So tweet them to me. Let me know. Send me to Cheryl G. Schaefer there. Rather than taking question time on this. Let me know what your favorite one is. What you've done with other people. And we can just help each other all learn. So I hope everybody caught my main thesis here is that building the plan is really more important than what the content of the plan is. So process over content. You can change the content and tweak it to what you need if you have a good process already done. So that's it for this one. Does anybody have any questions? Okay the question was can I talk about specific things that have gone wrong in pair programming and how to avoid them. I think probably the thing that goes wrong for me pairing the most. Well there's two things. The first one is chatting. I like to talk. I find a lot of topics interesting. And really a web form is not one of those things that I find interesting. So something like I had a chat fromkaga. you you you you you
 Good to see you all here.  Thanks for coming.  It's 420.  And we're going to talk about some strategies to help you mentor new developers.  Let's just talk about me.  I'm Cheryl Schaefer.  You might have guessed from the program.  I was a flute teacher and a performer.  I have a master's degree in music.  Of course, being a musician, I also worked a bunch of other jobs.  I did photography.  I was an optician.  I worked for some dentists.  I had a lot of opportunities to learn different domains of knowledge.  I started in software by going to local meetups with my brother Chris.  I took a couple of classes at the local university.  Then there was a meetup that started in my town for women that I started attending.  From there, I got an apprenticeship at LaunchCode, which is a non-profit.  I was working under Mike Many.  I've been there for almost two years now.  And recently I recently mentored my first hire.  LaunchCode, the non-profit, is basically serving unemployed or underemployed adults, like working  towards upward mobility, helping people get their first tech job.  And offers a lot of free education opportunities.  But if about me, let's talk about you.  You could maybe use some help.  It's hard to find enough people to help you.  Beginners cost a lot less.  Plus, you can make sure they use the right editor.  And we all know that teams of people with diverse skills levels and experiences really  do produce better software.  You can build that team around you.  In part of that process, you're going to learn and grow yourself.  Kind of like metaprogramming.  You set them going and they will produce more people.  And then it just turns into this greatness there.  I'm not going to talk about interviewing right now, but if you want to talk about how  do you interview people who without degrees and stuff, you can come catch me later.  But so we already found someone.  I'm thinking of gender neutral names like Chris, Pat.  Let's say we found a Sam.  Meet Sam.  I know what you're thinking.  What I really meant was any hobbit who would follow Gandalf.  Sam is driven and smart and talented.  But they don't have a degree or maybe it's something else.  They went to a boot camp or a launch code class.  Maybe Sam actually did a project in C sharp or Java or something and they don't know  Ruby yet.  You could probably get HR to give Sam a chance, but they're going to have to prove themselves  and show that they can really learn and really do it.  How can you help them be successful?  One way is to build a learning plan together.  Especially if you've got someone who like I said did something else for their stack.  So I think there's a couple things to this whole learning plan that I'd like to bring  out first.  So really this is about Sam, this isn't about you as a mentor.  And so everything you think about as you work with them is focused on Sam and Sam's choices.  And maybe how Sam feels.  They're most successful when they feel responsible, when they feel challenged and when they feel  confident.  If Sam says to you I need to do this, I can really do it if I try hard, I can meet this  challenge.  That's when you know Sam's going to make it.  So it helps to be flexible if you can make your plan flexible enough to adjust for Sam's  learning styles.  And Sam's learning tricks are going to work better for themselves than yours will work  for them.  So you want to try and encourage Sam to make self-assessments.  So you don't need to do the assessment.  Sam makes the assessment.  What you provide is framing.  You're going to tell them context and ideas that they don't know about yet.  You want to tell them what to think.  This is kind of a delicate line.  But figure out what questions they can ask.  So let's pause here for a second.  Because this is the most often asked question that I get talking about different kinds of  mentoring and code reviews and things.  The first thing that happens when you start mentoring is they're showing somebody, you're  showing somebody code and they look at you and nod.  Somebody has mentored here.  Uh-oh.  He says, can you interpret what that means?  I don't know what it means when you nod, but I do it a lot when other people are helping  me through code I don't know yet.  It means I'm paying attention.  It doesn't mean I understand yet.  It doesn't mean I won't if you keep going the way you are.  But it doesn't mean I will either.  So people start asking questions.  Do you know what this means?  Is this going to return a string or a symbol?  That's better than not asking any questions, but it's not really asking the right kind  of questions.  If it can be answered with a yes or a no, you didn't learn anything about them by asking  that question.  Try and ask something more vague, especially when you don't know where they are at all.  What do you know about strung parameters instead of do you know how strung parameters works?  If you ask something general like that, you're going to get a much more nuanced conversation.  You can lead them towards what you think they need to know.  You'll be able to find out right away how to direct your efforts.  What level of detail are they aware of?  You don't waste your time on stuff they already know and it's boring to them, but you don't  talk over their head if, oh, I just worked on something old and I don't know that yet.  So avoid yes and no questions.  So basically, it's trying to empower Sam.  Sam is not ready for Valorog yet, but they can hold that Orc inventory off for you while  you fight the demon.  And then Sam will eventually grow into this awesome dev who can fight demons too.  It's very big and you're going to improve Sam's chances of success.  So there's four main activities we're going to talk about, like how you're going to steer  the ship, setting big goals, like figuring out, identifying what it is you want to accomplish  is the first step.  And then making sure that you've devoted adequate time and resources so that it's achievable.  And then we're going to cycle back and forth between this little circle of assessing what  they've done, what you want to do, reprioritizing what you want to do, and acknowledging when  you've succeeded.  And then once in a while cycle back.  So step one, we're going to set some goals.  Identifying what it is we want to do.  Sit down with someone, the person who wants to learn, who's asked you for help.  And say, what is it that you want help with?  If they just say I want a job, that's maybe not super helpful.  But you can always suggest one.  Well, I know Ruby.  You could get a job in Ruby.  You want to be an awesome Ruby dev.  I think that'd be awesome.  But try and get Sam to suggest some ideas.  What do you think it means to be awesome at Ruby?  What are some adjacent skills that you're going to need?  You can't just do Ruby all day.  It'd be great.  But you need other things too.  You need a little bash.  Try to get Sam to write a lot of things.  Figure out, oh, I want to be full stack.  I hear that one a lot.  I want to do the full stack.  You don't know what you're asking for.  But okay, yeah, it sounds like fun.  And then Sam can keep asking stuff.  You want to learn how to write tests?  That's great.  Get fast with your editors.  Oh my gosh.  Oh my gosh.  There's so many things we could do.  It's so great.  Oh my god.  It's out of control.  This is actually my list.  No, it is actually.  But that's a great sign.  It's a great sign.  You've got a curious, a bright mind.  All those things sound awesome to me too.  You've let the constraints go.  You're free.  You could learn anything.  Don't fall for the ambiguity effect.  Are you guys familiar with the ambiguity effect?  Raise your hand if you know the ambiguity effect.  The ambiguity effect is one of those strawman arguments where it's like, I don't know what  I don't know yet.  It must not be that much.  It's not that important.  I probably couldn't do it anyway.  It's kind of like a self-defacing sort of, I should have made a slide about that too.  It's basically like limiting your horizons based on where you are now.  So just break free of that.  You could do anything.  And we're just organizing it right now.  So let's organize it.  Let's set it up.  Okay.  All right.  As much as I want to know how to speak Japanese and go talk to my hats, I did have dinner with  them.  But I don't know Japanese yet.  It's not really important if you're working on a Ruby job.  So organize your time by the things that are distractions right now.  That's not saying you'll never learn them.  It's just like, I'm not actually going to work on that right now.  Organize them by the things I'm going to work on.  And those two are in a category that's important and it's going to take a lot of time.  And that's the first category there the most time.  And then, you know, okay, I'm going to read some special stuff about pair programming,  some blog articles or whatever.  But it's not going to take as long to learn how to do that.  And I'm going to practice that sort of implicitly anyway.  So I don't need to explicitly practice, like read as much on that as I do different design  patterns.  So these things will take less time.  These things will take more time.  And we're going to organize the learning plane around these topics.  So that way, the topics that you're learning on are the topics that you need.  So you don't waste any time on topics that somebody else says are important, but they  aren't applicable to your situation.  So here's the hard part, breaking it down.  For this style of like the apprenticeship for them, we do, you're going to spend some  time pairing with them and code reviewing, I'm sure, anyway.  And to do this plan, like you need probably an hour every week, like just a meeting together,  where you can have a conversation.  Especially at first, you're going to take probably, I don't know, I just guessed out  here, half a day to assess new resources that will go down.  The more people you talk to because you already assessed some of those resources, Sam's going  to have to put the bulk of the work in, right, the one learning.  And you know, laptops, subscriptions, maybe you need to order some books, that kind of  stuff.  And you know, you're maybe going to have a little reduced, like some opportunity cost  and reduced capacity from you as a dev while you're pairing with Sam and doing stuff that's  like a little bit easier that Sam's going to be able to understand at first.  And then where are you going to organize our plan in?  I don't actually really care.  People talk about this, like, of the people I've talked about this, this is probably like  the biggest like, oh, what could I use?  We could have fun with this.  I could make my own thing.  Ah, it doesn't matter.  The little cards are cool.  But as long as you can go both get in there, add things and check them off, you know, don't  make it too perfect until you've done at least two or three people and then, you know, you  can start breaking it down.  I just change stuff so much between people that I don't even use anything fancy.  So all right.  Thinking more of big thoughts about the plan.  So the plan is actually Sam's.  So you're going to need to release ownership of the plan.  That's hard because you want to make choices about the plan.  But what we want to do is guide Sam to make the right choices instead of making choices  ourselves.  So the plan belongs to Sam.  Even if Sam's going to make some wrong steps, let them do it.  Maybe not like a big wrong step, but some small wrong steps, you know, protect them  from the big wrong steps.  Do lots of little steps and then that way if they make a wrong step, they can see that  error themselves and correct it.  You want to make it a list of to-do items and every one of them should apply like the  topic of every one of them.  You're going to learn something that was one of those topics in the previous slide.  So as you assess resources, pick ones that are exactly what you want to learn.  Make sure that they're not too long.  You don't want anything, especially the beginning, that takes more than a couple of hours to  complete if it's going to take like a big book.  You're going to read Sandy Metz's photo book.  That's a great goal for the end, but the first couple of weeks don't do it.  It's too easy to get lost.  And another big point is your capacity to learn varies a lot by method of transmission.  So you've just worked nine hours today on your laptop.  That blog post is great or that screencast is great, but your eyes are going to be fatigued.  The paper book might be a better choice, just maybe pick one chapter at a time instead of  the whole thing.  But print it out even.  Print out your blog article.  Sorry, trees.  It'll be great.  Sorry, trees, but it'll be great for your learning.  So assessing learning tools.  And that's what I'm talking about is like just collecting screencasts and blog articles  and that kind of thing.  Podcasts that you listen to, books that you've read, things on online places like edX or  Coursera.  Assess them for quality effectiveness and speed of use.  So the main thing to think about when you're assessing things is not to just be like, oh,  this is about SQL.  They need to know some SQL.  Here you go.  You should read it first.  And then think, okay, what will Sam be able to do after learning the concepts that this  presents?  Will they be able to learn those concepts the way that it's been presented here?  What exactly topic does it cover?  Okay, it's on SQL.  You need to know some SQL.  Okay, is it accurate?  How dated is it?  That's a big deal for us, right?  How thorough is it?  Who is the author?  What was the person's motivation to create this resource?  It's great if you just want to share, and that's what we'd like to do is just share our knowledge,  right?  But maybe somebody is a little skewed one way or the other for some other reason.  Compare the difficulty of the material to Sam's current output.  And here's a good one.  So I'm just talking, right?  And I'll do this at the end.  Does it link other resources?  Some do and some really don't at all.  If it leads you on a journey like that, it shows that it's a lot more, it's showing you  like what you can learn next, and it's more legitimate.  You can prove that the things that they've said are true, or here's an argument for,  here's an argument against.  Here's some evidence that would lead us to believe that.  And then the format thing.  Is it on paper?  Is it a print?  How long is it going to take Sam to complete?  And is it interesting?  Is it going to engage them so that they stick with it and learn?  It makes it easier for you to stick with it and learn.  So we'll sit together and come up with a list.  You should probably come up with a list the first week.  And I just threw together one that was like full of some stuff that I've done for a few  other people to use for this talk.  And I just didn't cheat because it's really easy for me to give you a link there.  So get a list of things that you would want to know the topics that they're about.  Pick a few.  Like here's one about Ruby.  Here's one about learning.  Here's some Rails and Web and Unix.  Okay, great.  And then put those together and make sure it's a little bit more than they're going to be  able to get done that week.  Give them a little bit of a stretch room.  So it's not like, okay, it's a deadline.  Here's where you get done.  You're going to work through a little bit every day and see how far you can get.  Grab one from each topic and then mix in some things you need urgently.  You may not be able to do that as much at the beginning, but as you go down, hey, I  need this CSV import.  Okay, here's a blog article about how that library works.  But make it so that it's easy to just grab one, click the link, read it, and do it.  A checklist, really.  And to learn the concepts inside of it.  So that's the first big steps towards empowering SAM.  SAM is ready to go.  SAM is going to get this done.  The next thing to consider, though, is that we're managing them at work, too, right?  That's going to affect SAM's outcome a lot.  So let's talk about it.  When you're selecting, like, what stories SAM is going to do, what ones you're going  to pair together on, you know, I usually was selecting the work, the learning around the  stories I knew were coming.  But sometimes you can do the other way around.  You can select the work around what they've learned.  So go for it.  Try and pair program with them as much as you can.  That's probably the most important thing.  Although that turns out to be a really difficult thing to measure.  I try to get some stuff on that at work.  It's just tough to measure because everyone defines it slightly differently.  But if you can get time with you pairing it with them, especially if you can get other  people that are a varied experience level to pair with the apprentice or the, you know,  junior person you've just started, it takes a village.  If you can get, like, a more experience of wide range, they can see how each person deals  with things slightly differently and learn from that.  And of course, I'm all about trial by fire.  Go for what really matters.  If it doesn't, if it matters, why aren't you going for it?  Try and get some code live their first day if you can.  I mean, at least the first week, get something live so they can point and be like, that was  me, I did it, I can do this.  And build that trust with SAM and with your coworkers that, you know, I'm going to let  you take some small missteps, but I'm going to guide you away from the big cliff edge.  So your coworkers know they're going to take care of SAM and SAM knows you're going to  help take care of them.  One other thing, try and keep their work exciting.  Don't give them intern work.  It's boring.  And code reviews.  There's so many resources online.  I'm not going to talk too much about that.  But I think it's a great feedback mechanism to measure the success in learning.  When I was teaching, that was always the thing, right?  Everybody wants to take a quiz.  Everybody wants to take a test.  It stresses them out.  You don't have to do that.  They wrote code.  There's an artifact right there.  Right?  You don't have to make them make a test.  It's great.  It's already there.  Sandwich the criticism between complaints.  Like, tell them what they're doing well as well as telling them what they're not doing  well.  Ask the questions and then see if you can get them to explain to you how they might fix  it.  Maybe you can choose between two or three different paths.  That's a great way to teach them stuff.  But if they really don't know what's going on, give them a bunch of exemplars.  Show them examples of somebody else's code, even on some other project, and provide some  context.  Like, I think they chose this code here because they're under a time limit.  It works.  But if I had time, I would do it this way.  Here's another example.  So they can understand when a decision is going to be called bad by someone and when  it's going to be called the same decision might otherwise be called good.  There's some more resources about this in the downloadable plan that I've included at  the end.  So they hop on and check off things as they complete them.  You go hunt for more resources and add them to the bottom of the list.  And then, you know, they start adding stuff too.  Maybe they've found.  And then once a week, have a check-in.  They're checking meeting.  And discuss how everything's going.  They can brain dump on you.  This is what I thought about this article.  I didn't understand this thing about whatever here, the joins, what happened.  And then maybe you can adjust your resource collection based on that feedback.  So you make that as immediate as possible.  Okay.  So maybe at the beginning, you're feeling a little overwhelmed.  I don't know how well you can see Sam in that picture.  He's looking overwhelmed.  So let's talk about how to prioritize your work.  There's so much to learn.  You may have heard this.  President Eisenhower said, I have two kinds of problems, the urgent and the important.  The urgent are not important and the important are never urgent.  So this is popularized by the book Seven Habits of Highly Effective People.  If you imagine urgency on the x-axis and importance on the y, you can see, okay, maybe we need  that CSB important by Tuesday, but CSB imports aren't that important for them to learn.  It's really important that they learn about dependency management or something.  So that's kind of a good way to throw out things that you don't need.  Let's scope it down a little bit, and then once you've combined those into the things  that are important and urgent and the things that are important as in your priority level,  then you can also add that axis of cost and say, okay, this is really important.  It's really urgent and it's cheap.  Just do it.  And then the big high cost items, you're going to want to split across multiple weeks  so that you hit it a little bit every time and that's going to add up over the time.  So keep doing that every week.  They keep learning.  You keep checking in with them.  And then every month or so, every four weeks, I would say, do a check in on your larger  goals and reassess.  Are we working towards Rails and Ruby?  Or did they end up doing a lot of server scripting?  Is what we end up doing actually what we thought we needed at the beginning?  Maybe we steered off and maybe that is actually where we should have steered to begin with,  or maybe we just need to strain back out.  So in the middle, it can be a little depressing.  You're working towards a big goal and it's hard.  Maybe that's a little overwhelming.  The dragon's coming.  You can see him.  He's here.  Let's try and stay positive.  Here, I have a nice little chart there.  At first, you knew you were going to lose some capacity to training and it can kind of feel  impossible.  But you're at the big point of the trilogy.  Please go up from here.  By the end, you can see you're doing so much more than you were at the beginning.  See my completely made up chart.  Actually, okay.  It's not really completely made up.  This is actually story points of my capacity.  It was later around 20 and then we brought on Dave.  And then Dave got super independent and here we're way above where I was by myself already.  But I was right here and so it's hard to feel positive right when you're down here.  But this part is coming.  It kind of looks like the big dipper.  It happens to the apprentices too.  I did that part too but it's been a little longer ago.  So at Launch Code where we do surveys of people who are going through the apprenticeship  program because they're working at different companies so it's like it's hard to stay communicating  with them.  So we send them stuff.  Find out how they're doing.  Mostly so we can intervene if somebody's in trouble.  But we're also getting this general rating and I always wondered what was going on with  that.  So we did this little study of it.  This data has been normalized.  This is actually the response data from people.  It's normalized over the length of the apprenticeship.  So if it took six weeks or if it took 20 that's 100% of the length of time.  And the ratings are also normalized.  So we removed people who only answered once and things like that.  Or if you answered like exactly the same every time we took that out.  And what it shows really is that they actually feel really like it's going up the whole time  as they start to realize how well they could do.  That's really great.  And this is also only successful apprentices.  That's like 90 something percent.  So that's pretty much almost all of them anyway.  So it's trending up.  They're getting happier with a little range of doubt because our numbers aren't like super  high on responses.  Who wants to fill out surveys right.  But you have these outliers.  Do you see these little guys down here at the bottom.  That person made it.  But they felt so bad.  Oops.  We went around here.  Sorry guys.  This person here felt bad.  And these people here they felt bad.  Oh my gosh.  But they made it.  So they just didn't know what they didn't know.  And they didn't know.  You know there was like that moment of doubt and that imposter syndrome happening sometime  in the middle.  It could happen anytime.  But it can be overcome.  So how can you overcome that.  Here we are.  We're software developers but we're managing people's motivation.  That's what you have to do to communicate right.  So there's a lot of confusion about this but I'll go over it really fast.  Reinforcement attempts to increase behaviors you want.  Punishment you're attempting to reduce and eliminate behaviors you don't want.  And both of these can be negative or positive.  And negative is removing a thing.  So like negative reinforcement a lot of people who when they first get this kind of a job  are really happy.  The negative reinforcement happens naturally.  They had an income straw that you removed.  Now they have room for hope.  But you want to try and do we want to try and do positive reinforcement because that's  the strongest motivator right.  But how can you apply this to software.  I think it's still shaping even if it's whatever you're in.  It can be as simple as that compliment you gave them on the code review.  Don't just point out the flaws in the code review.  Any time they're working like I found this article on Active Record and you need to use  that and then you should recognize work in that direction.  Or point it out in front of other person.  Morning stand up tell them oh Sam already finished that whole book.  Can you believe that.  That's awesome.  Sometimes this is called success of approximation it works on yourself.  Use it.  It works on your pets.  Use it.  It works on your spouse.  I mean nothing.  Sorry honey.  But the point that you need to come across to use this correctly so you don't like just  end up being happy all the time right.  Wait.  No.  The point so that it actually changes behavior is that once you've done the same correct  thing that's closer to correct but it's not exactly correct you start reducing one of  these dimensions of strength.  They don't get rewarded every single time maybe like oh that's great.  Instead of talking about it for ten minutes latency I don't have to explain that to you  guys.  You just wait to respond that reduces the strength of that response and so then they're  going to have to go a little they're going to try to try a little harder get a little  more accurate to achieve that same level of response again and then that's how you can  change the behavior in the direction you want to go.  So Sam is starting to feel confident.  Sam has been working.  Sam is getting there.  Week eight time for another big points check in.  How's it going?  You can start to introduce some more like complicated things and larger books and like you should  subscribe to this podcast instead of just check off items like read this one blog article.  If you're doing the contract a higher type situation you should talk about it but even  if you're not this is like a one this is like a project right.  So see if we're going to make our 90 day goal.  If you don't think we are see if you can scope it down a little bit you know maybe we wanted  to be full stack but that's kind of a lot of stuff maybe you could just do one side for  the first 90 days and then learn the other one.  What if we added a couple of weeks or maybe four weeks could we make it then?  I mean if it's just a week or two add it.  But if they are make sure you tell them they are you know keep working hard you can push  through this let's go.  Same thing if you do anything.  Same thing if you do anything.  By week 12 it should be like just a couple of things left.  What absolutely must be finished if it doesn't absolutely have to be finished get it off  there.  There's still going to be a junior developer when they're done with this but they're going  to be so much like need less direct support and have gotten so much knowledge out of this.  See if there's some kind of symbol of success that you can directly tie to completion.  So with the apprenticeship things most people will convert then they get a title they switch  to salary things are great.  If it's a private type thing situation like you're just helping someone on the side come  up with some kind of symbol of success and then that like gives that moment at the end.  You reach the end of the video game and it gave you this vast screen it seems like an  easy and small thing but it matters so much.  And celebrate celebrate enjoy tell other people how Sam succeeded tell them how Sam succeeded  you know maybe you're a humble brag at a level Sam succeeded.  Oh yeah I did I did too.  And when you're done to take some time off before your next thing both of you give yourself  some introvert time introvert for a while.  It's not sustainable to do this level of work long term.  Sam probably used up some asks from family and friends just to maintain this level of  work.  But most people cycle back in as their lives allow to allow for their progress in their  careers that we want to help other people too.  And it's so rewarding to see that kind of compounding like pay it forward stuff that  you know I help this person and they help these three people and now there's like 20  people who are all like grand babies basically.  By the way I did not make this shit up.  That's a lot of stuff to have made up though honestly like most of this is based on my  own experiences and it's basically what I did to my flu students just on software.  And what Mike Benet did to me at launch code thanks Mike.  Here's some springboards where you can go learn more about these things and of course  there's always the Google search to just find everything else that you might want to know  but then you don't have that assessment that has already been checked out by me.  One other thing I touched upon we talked about a little bit about learning strategies being  flexible to allow theirs.  It's not the focus of this talk so I don't really want to take questions on these but  I'd be really happy to discuss them later.  Really what I mean by that is things that they address like specific behaviors you can  do to address one type of issue.  So it applies probably to some group of people like 10 or 20% of people but it's not relevant  to other people.  That's what I mean when I say like learning strategies.  For example if you have trouble like staying focused or you can't break focus people will  set a timer.  Oh I can set a 25 minute timer and I can keep myself focused and no one to break.  That's really helpful but for people who don't have a problem with that it's kind of like  a waste of time.  There are so many of those things.  We've been here for a long time.  So tweet them to me.  Let me know.  Send me to Cheryl G. Schaefer there.  Rather than taking question time on this.  Let me know what your favorite one is.  What you've done with other people.  And we can just help each other all learn.  So I hope everybody caught my main thesis here is that building the plan is really more  important than what the content of the plan is.  So process over content.  You can change the content and tweak it to what you need if you have a good process already  done.  So that's it for this one.  Does anybody have any questions?  Okay the question was can I talk about specific things that have gone wrong in pair programming  and how to avoid them.  I think probably the thing that goes wrong for me pairing the most.  Well there's two things.  The first one is chatting.  I like to talk.  I find a lot of topics interesting.  And really a web form is not one of those things that I find interesting.  So something like I had a chat fromkaga.  you  you  you  you  you
Grow_Your_Team_In_90_Days_0_47.png Grow_Your_Team_In_90_Days_48_107.png Grow_Your_Team_In_90_Days_108_155.png Grow_Your_Team_In_90_Days_156_239.png Grow_Your_Team_In_90_Days_240_395.png Grow_Your_Team_In_90_Days_396_707.png Grow_Your_Team_In_90_Days_708_2375.png Grow_Your_Team_In_90_Days_2376_4763.png Grow_Your_Team_In_90_Days_4764_9131.png Grow_Your_Team_In_90_Days_9132_11939.png Grow_Your_Team_In_90_Days_11940_15227.png Grow_Your_Team_In_90_Days_15228_15323.png Grow_Your_Team_In_90_Days_15324_20123.png Grow_Your_Team_In_90_Days_20124_23483.png Grow_Your_Team_In_90_Days_23484_25199.png Grow_Your_Team_In_90_Days_25200_25511.png Grow_Your_Team_In_90_Days_25512_30995.png Grow_Your_Team_In_90_Days_30996_31655.png Grow_Your_Team_In_90_Days_31656_35471.png Grow_Your_Team_In_90_Days_35472_37607.png Grow_Your_Team_In_90_Days_37608_37667.png Grow_Your_Team_In_90_Days_37668_38267.png Grow_Your_Team_In_90_Days_38268_38519.png Grow_Your_Team_In_90_Days_38520_38567.png Grow_Your_Team_In_90_Days_38568_39479.png Grow_Your_Team_In_90_Days_39480_41735.png Grow_Your_Team_In_90_Days_41736_41867.png Grow_Your_Team_In_90_Days_41868_43247.png Grow_Your_Team_In_90_Days_43248_44723.png Grow_Your_Team_In_90_Days_44724_45023.png Grow_Your_Team_In_90_Days_45024_45971.png Grow_Your_Team_In_90_Days_45972_46907.png Grow_Your_Team_In_90_Days_46908_48539.png Grow_Your_Team_In_90_Days_48540_48947.png Grow_Your_Team_In_90_Days_48948_49103.png Grow_Your_Team_In_90_Days_49104_49307.png Grow_Your_Team_In_90_Days_49308_49367.png Grow_Your_Team_In_90_Days_49368_49703.png Grow_Your_Team_In_90_Days_49704_49787.png Grow_Your_Team_In_90_Days_49788_50159.png Grow_Your_Team_In_90_Days_50160_50783.png Grow_Your_Team_In_90_Days_50784_50975.png Grow_Your_Team_In_90_Days_50976_51143.png Grow_Your_Team_In_90_Days_51144_52175.png Grow_Your_Team_In_90_Days_52176_53171.png Grow_Your_Team_In_90_Days_53172_53267.png Grow_Your_Team_In_90_Days_53268_53975.png Grow_Your_Team_In_90_Days_53976_54023.png Grow_Your_Team_In_90_Days_54024_54947.png Grow_Your_Team_In_90_Days_54948_55031.png Grow_Your_Team_In_90_Days_55032_55091.png Grow_Your_Team_In_90_Days_55092_55883.png Grow_Your_Team_In_90_Days_55884_55967.png Grow_Your_Team_In_90_Days_55968_57167.png Grow_Your_Team_In_90_Days_57168_57287.png Grow_Your_Team_In_90_Days_57288_57455.png Grow_Your_Team_In_90_Days_57456_57481.png