 It is 2.40, so I'm going to go ahead and get started. I'm going to be talking about power charging apprenticeship programs today. And you are probably wondering, who is this lady? Hi, I'm Louisa. I work at the Turing School of Software and Design. I am the founding instructor, and I'm currently the director of the front-end engineering program. And that means that I work with, I don't know if you're familiar with Turing, but this is Jeff Casimir, here's our founder. He's not here today, so I can pick on him a little bit. So back to me now. So since I'm on the front-end team, I like design, and I like code, and I also like teaching. And that means that I, basically, I spend my days hurting humans, talking about typography, JavaScript, and, if you will excuse my pardon in my French, CSS. And I am extremely bad at Twitter, but this is my Twitter handle. And it's like, it's really embarrassing how bad I am at Twitter, so just don't judge me. So I'm a front-end person. I am at a Ruby conference, so that's weird. Why am I here? Firstly, extremely good at Ruby, as you can tell. Like this. And mostly, jokes, I'm good at it. OK, woo, all right. Anyway, so what I'm actually here to talk to you about is apprenticeships. So for the last couple of years, I'm also used to walking around when I talk. So if I keep walking away from the mic, please forgive me, and I'll come back to it. So for the last couple of years, my whole job has been to figure out the best and most repeatable techniques to get people ramped up into junior dev level skill levels to do that really quickly and to do that really consistently. And obviously, I'm working at a school, so I'm in a more education-based place. But that's essentially what an apprenticeship is. It's in a little bit more business-minded format rather than an education-based format. So I do this a lot. This is my job. And I just want to talk to you about it. And part of why I want to do that is because my background is in design. I was a designer for a very long time. I've been in the creative industries for many years before I switched over to writing code. And it was really interesting to me coming from the creative industry where apprenticeships and internships are just kind of like part of the game. And it's like expected that you will have had some sort of an apprenticeship or some sort of an internship at some point before you have your first real job. And often, again, because it's a creative industry, those jobs are those internships or those apprenticeships are often unpaid because of reasons like experience. And you're passionate about it, which is a load of crap. But it was really interesting coming into software development because it was a very different kind of mindset around them. They were a little bit less common. I think people took them a lot more seriously. And I feel like part of the reason that they did that is because there's this expectation that you should be compensated fairly for your work in this industry, which is what a fantastic thing. That's great. But it means that people take it a little bit more seriously and that people are more concerned about making sure that it's actually fair and that people are being treated right. But at the same time, that means that I feel like there are potentially fewer opportunities to get your foot in the door in an apprenticeship type situation at a company unless it's a really big organization that has a lot of wiggle room and funding for it. But the thing is that apprenticeships are really valuable to teams. I think that they are really great experiences for both the person who is the actual apprentice and then also the team that they're working with. And really the biggest thing is just to structure them correctly and just be mindful of how you're putting them together in order for them to really be successful and really be a good experience for everyone. So, yes, setting up a successful apprenticeship is not impossible and it is not scary. And they really are worth it. And part of that is just because it is so energizing to have somebody who's new to the industry as a part of your team. They are incredibly motivated, they're really excited and they're also just really fun to work with. They see things from new perspectives and different angles and it's just really exciting and fun to be a part of it when you're on a team with someone like that. So, yes, all of you could absolutely build in a successful apprenticeship program and your team will be significantly stronger for it. So, if you are still thinking that like an apprenticeship program seems like it's just like kind of like a high risk time and money vacuum and you're kind of wondering if that investment is really gonna pay off. Yes, it will. In my experience, the benefits to the team and just like the general company ecosystem are actually really big. An apprenticeship can be, or just bringing on an apprentice is a really great way to re-energize a team even if you just have like, if you are able to have a team of just senior people bringing on somebody who's brand new is a really energizing and fun thing to do and they can bring a lot of just joy and fun to the group that you may not expect. And remember, it also isn't something that's forever for either party, right? Like an apprenticeship is a termed thing that somebody's gonna grow out of. They're gonna grow into a more experienced role. They're gonna be a junior. They're gonna become a mid-level person at some point. They're gonna move into a senior position at some point down the road. So, like they're super motivated. They know that there's a light at the end of the tunnel. They know that they're gonna be progressing quickly. So they're gonna be working really hard and they're gonna get better really fast. And so investing in them at that point in their careers is really beneficial to you and them and it really will pay off quickly. So again, in conclusion, you absolutely can have an apprenticeship program and they will make your team better and you will have a lot of really new weird jokes which is always great, right? More jokes. So, the plan. You should have one. Perfect, great. So again, like before you get started, the very first thing you should do is just make sure that your whole team, so like top down, understands like what the point of an apprentice is and it is an educational learning relationship, right? So like you're bringing on someone who is there to learn from you and someone who you've committed to teaching for us that amount of time. And keeping that in mind that this is something that you have agreed to do, that you're like agreeing to teach someone and they're agreeing to learn from you. We're gonna talk about some strategies that will help teams plan and prepare for a successful apprenticeship program. And there are three phases of planning that I'm gonna be talking about today. So, first, like what to do before you start an apprenticeship. So like systems and processes to have in place, things to do before you actually get rolling with it. How to hire for an apprenticeship. So how to actually find the right candidate and then hire the right person. And then just what to do during the apprenticeship. Like how do you keep somebody on track? How do you make sure that they're making progress and how do you keep the wheels on the bus? I guess is how you could say that. So, those are the things we're gonna be talking about and we're gonna just dive right into what to do before you start an apprenticeship. So, like most things that are worth doing, this does take a little bit of work to put a program like this together and that's okay. It's kind of like, it's not really that different than like when you start a new, like if you bring out a new client project or you just start a new software project, it's just planning, right? So in these phases, this is just sort of like strategy and planning and making sure everybody's on board. And like a new client project or a new software project, it's in your best interest to put about five to 10% of your time in upfront to make sure that you're in a good place to have things that you can like goals and a game plan to execute on throughout the duration of your program. So the work you put in should start before you even start thinking about interviewing candidates and it's really gonna pay you back 10 fold once you actually bring someone onto your team. So with that in mind, let's dig into it. So something to consider before you get started again is just put the wise before the house, right? So this is really trying to understand the reasons and motivations that are driving you to start a program like this. There's not necessarily like a wrong motivation or a right motivation, but there are different motivators and it's very important to just make sure that you're paying attention to that. Cause if you are sort of angling, if you're taking it at an angle that isn't really truly targeting the motivations and the reasons that you're doing this, you could potentially not have as successful an experience as you would otherwise. So why is behind bringing on an apprentice can there can be a big range of reasons like lots of different reasons why you might do this and they might range from like educational, like you might feel like you really wanna just bring someone into the industry and help them get a toehold and just get a good solid start. Or they might be financial, like maybe you're at a really small company and you need more hands on deck and like the reality is that you don't have the budget to bring on a mid-level or senior person and an apprentice is sort of like, okay, I'm gonna get this person started but I also, it's gonna help me because I can actually like afford to pay them. And again, those are both valid reasons. There's not necessarily that there isn't like a right way or a wrong way to do this. It's just be honest about it and be clear with yourself, your team and the person you're bringing on so that everybody's really on the same page about like what's going on and why they're coming on to the team. So and because those two sort of like two spectrums of motivations are very different, they're going to impact how you actually approach a program like this. So if you tell yourself that you are going to help like a newbie get a toehold in the industry, that's gonna really sort of direct your choices and how you structure things very differently than if what you need is somebody who is gonna be able to actually hit the ground running a little bit faster and really start contributing to code because you just need more hands on deck. So just make sure that you're clear on that and then your planning and your execution will be more aligned. And again, just being honest with yourself about that will lead to more successes. So making sure that you are planning carefully, hiring strategically and then having an actionable curriculum strategy which sounds scarier than it actually is are going to make sure that you have set yourself up for success with your team. Before, again, like before you bring on, before you start hiring anybody or anything like that but this is all still part of the planning phase of things, you wanna make sure that you have buy-in from the whole team. So this is basically top-down buy-in. Like you wanna pitch this and sell it to your whole team. So what that kind of means is that you end up making sure that management needs to understand the reasoning behind this, why it offers value and then your team should also be on board them understanding that this is something that they're excited about and invested in. So everybody needs to be on the same page about how time and energy is gonna be allocated for something like this. And then because people have an easier time saying yes when they can clearly see the path to success, here are some ways that you can be strategic and communicate your plan to the whole team to get go-ahead from everybody. So you wanna make your case and you wanna be specific about it. So you wanna understand, you wanna have a defendable business reason and like team-building reasons for why adding this position is gonna be beneficial and you wanna be like very explicit and direct around what roles everyone is gonna be responsible for when you get someone on the team. And again like the stronger you can make a case for this now the more your team will understand like where you're heading, where your head's at and that's like the plan and they will be able to support you better. And again this comes from management down. So you wanna go top-down, everyone should be bought in, everybody should be on the same page. Because then ultimately what you wanna do is be, you wanna have it be as supportive as you can for this new person that you're bringing on. And again like the whole point of this is to just make it easy for the team to say yes to this. So you need to be prepared to explain why this program is valuable to the team and then to be clear about who is responsible for what. So just make sure that you have like a strategy and a plan around like how things are happening and when they're gonna happen and all that. And some things you can dig into are to build a strong case for this, know who the primary point person is gonna be. So you wanna make sure that you have someone who's gonna be like an owner of this apprenticeship and they're going to be the primary mentor. You want to be clear about how key team members will have bandwidth in their schedule. So if it's possible to sort of like address scheduling issues and make sure that people aren't gonna feel totally overloaded. So just sort of like being able to adjust schedules in such a way or just address scheduling issues in such a way to make sure that people actually have the bandwidth to support this person. And then just being clear that teaching actually makes your team a lot stronger. So if you have a team of very senior people, there are a lot of opportunities for teaching a brand new beginner that will make them better. Having to explain something at a really granular, like specific level to somebody who doesn't understand the bigger picture is really difficult and it's actually surprising how many senior people struggle with that. So bringing somebody on who's super junior and doesn't have a lot of exposure to these things is actually really great, even if you have a primarily senior level team. It also brings on a lot of different perspectives and skill sets, especially, I mean, even if you're hiring from a traditional CS program, but if you're hiring from an accelerated training program or a boot camp, you're gonna get all of this life history and career experience that is really interesting and kind of exciting. So it's gonna re-energize your team and it's gonna bring on a lot of interesting perspectives and approaches to the work, which is great. And then you should also just be very clear about how your apprentice's time will be spent and how they're gonna be progressively ramping up so they are able to take on more and more billable work. Like there's an expectation that initially you're gonna be, you know, not have as much billable time and then as you taper off towards the end of your apprenticeship that you should be pretty much mostly billable, right? So be clear about that and then just have a game plan for how they're going to get up to that skill level so they are more billable. So then we have backwards planning. So this is something around, this is probably something that's gonna be happening around the same time as your team buy-in conversations and this is something that's going to help you do that, right? So backwards planning is essentially helping you make a case for why this is doable and achievable and it also helps you just set up a game plan for how you're gonna structure things, right? So when I'm talking about backwards planning, what I'm essentially talking about is just curriculum planning. So it's basically like, so first of all, curriculum's not a scary word, you can do this. It's basically just saying that you are going to start out figuring out where the person needs to end up and then working your way backwards. So at the end of the program, they should have this set of skills and I know that and then how do I actually break that down from day one to make them successful to hit that point that I need them to be at. So around curriculum planning, things that you can do to organize this is, so you start, again, like you start with the list of skills and competencies that you want them to have mastery of at the very end of the program, right? So you're gonna go ahead and make sure that you have been very clear and explicit about that. So we're basically starting at the biggest picture view and then we're working our way into a more granular level. So again, we start out with end of the program, where do they need to be? Then we work our way out from that, we work our way in from there, so we say like 10,000 foot view, how do I get them there? So this is when you start thinking about if I need them to know this whole big set of stuff, how do I actually break that down into bite-sizable pieces so I'm not just thrown them in the deep end expecting them to know how to swim and if I haven't put little water wings on them at all. So that's this next step. Then finally, we kind of go down into a week-by-week breakdown of goals. So this is when we really start getting granular, we really start breaking this bigger end goal down into these little pieces. And again, this isn't all that different from project planning, right? So it's essentially like you are taking this big problem and you're breaking it into little pieces that don't seem so intimidating. But again, this is about education, so we're dealing with how do we take this larger problem and then we break it down into little pieces. So this is gonna be something where you figure out from week one, what do I need them to know? And then I'm gonna build on that and you're just gonna build your way upwards towards the end of the program. You also need to understand what success looks like at all of these various stages of the apprenticeship and then also additionally, so you need to understand what success looks like and then in parallel with that, you need to understand what kind of a plan do you have if they start falling behind? And it's likely that they'll have several different things that they need to be working on at the same time or that they'll be ramping up on and not everybody learns the same skills at the same pace. So it could be that there are certain things that they're really excelling at and then certain things that they're sort of struggling with. So just being prepared for that and then having some sort of a game plan so you can kind of hop in and start helping them out if they get stuck. And then another thing is just to be sure that you have clear ways that someone can understand what skills they need to know and then how they can improve on those. And again, to get a whole team buy-in, it's important that you have set up this information in a way that is accessible to the whole team. So everybody's able to be on the same page and just be clearly communicating at the same time to both the apprenticeship and each other about where they are at. And this is also really helpful because the apprentice can then sort of self-assess along the way and it's not just totally on you to have to hand-hold them and tell them where they're at. Yeah, so again, it just allows the team to be aligned and you're not getting mixed messages from everyone. All right. So again, to understand how to track progress for once your apprentice gets started, this is something that is a little bit tricky, right? Because it can feel a little bit ambiguous and you've got a lot of different things that you need to kind of pay attention to because if software is not the simple things, you need to have, there's gonna be multiple things that they're ramping up on at the same time. And so you need some sort of a rubric that you can balance against and check against so people understand where they're at. And they have actionable steps that they can take to get better at certain specific skills. And so things that I've seen great success with are when we have like a tiered scoring system, essentially. So these can be either rankings from like red to green. So red would be something that someone is struggling with and green is something that they're just cruising, they don't need a lot of help with that. You could have like sort of a number system. So one to four or even just something like from novice to expert, right? So you can just have just some sort of ranking that somebody understands the tiers and like the structure that they can keep working their way up from. It should be kept somewhat simple. You don't wanna get so complex that it's overly tricky to understand or to use. So I'd say probably between three and five sort of skill levels per skill that they're mastering. So different levels that they can work their way up from. And it should really have clear and explicit steps that explain how to move forward from one level to the next. Something else to consider is just semantics, right? So how you phrase things really matters, especially when someone's in a situation where they're learning something new that they're a little bit uncomfortable with. And it can actually have a really big impact on people if you use poorly chosen words and you can really negatively impact someone's progress and their growth. So you don't have to treat them like a delicate flower. You don't have to be like well really warm and fuzzy about everything. But it is important to just use language that builds them up rather than tears them down. So as an example of that, here's an example of some positive language that we use at Turing. So this is a very high level breakdown of just the language that we use for students in the first few weeks of Turing. So you see we have a breakdown from novice, advanced beginner, proficient to exceptional. So we have four levels of skills. And then within there, so novice is defined as, and again this is very high level. This isn't broken down into granular sections of skills. This is just a big picture, 10,000 foot view of how they're doing. So it says can function but needs a lot of oversight for novice. Advanced beginner is can function with very little oversight. Proficient is can confidently implement code without the need for rigid feedback. And then exceptional is understands and execute advanced concepts. So there's a pretty clear progression of skills and understanding there. And it allows them to like, they can go and read this and they don't need us to necessarily sit next to them and like guide them. And that's really useful because it means that there's much more, they're able to take control of their own learning and you don't have to like, can't hold them quite so much. Then we have another slightly more in depth example. So this is an example for just get how they understand version control. And again, we have the four-tier breakdown from novice to exceptional. With novice essentially just saying they can use commits. They can articulate what a commit is. So that's good. Hooray. And then they also, but they're kind of taking like big commits and then shove them all up to master which is a little bit of a dangerous game. And then we take it up to exceptional which is that they understand or that they know how to reset to previous commits, rebase large sets of small commits and then if applicable, use other advanced Git maneuvers. So we have a pretty drastic change in their understanding of the specific skill set which is really useful. And so again, like you would just sort of break down each sort of step of the skills that you'd want them to understand in this way so they can go in and self-assess. And this should be something that is available and accessible to your whole team. So everyone who's working with the apprentice or everyone who needs to support them and guide them so everyone's on the same page and being consistent with the messaging that they're giving them. So everyone's just communicating consistently to them and they can also self-assess. So those are things that you should handle before you get a human on board, right? So that's gonna be something that's going to allow you to be in a good place to just start working with them once you get somebody on board and then you're gonna have all your systems in place, your teams on board, you have a game plan, you know where you need them to be and then you need to actually find the right human. So it's not really all that different than hiring like for another dev position. The biggest thing is that you are, you're looking for somebody, you're investing in someone as a prospect rather than someone with a proven track record. So it takes a little bit of, a little bit of, I guess potentially a little bit more finesse than just hiring someone who you know like you've seen their work at other companies, you've seen them speaking at conferences, you've seen them around, you've seen their blog posts, like you know what they've been doing and you know they're really good. This is someone who's kind of an unknown and it's a little bit of a risk. But there are definitely things you can look for that will be really helpful in guiding you to find the right person and the right fit and that's actually a big part of what I do at Turing, right, so a big part of my job is to really just quickly and accurately gauge who has the right like personality or just attitude and perspective to be successful in this type of environment where it's a little bit less supported and it's someone that they can, something that they can sort of learn on their own and they can be successful there. So things that I look for, so I tried not to use GIFs but I should have put a GIF in here. Anyway, so something that I'm sure that most companies have some sort of structure around how to evaluate people for the role that they're looking to fill and it's super useful to do that for apprentices as well and you also have to just consider like what are your goals for this person? Like where do you want them to land and what do you actually need them to do? Like are you looking for somebody who's gonna be just a hotshot right out of the gate that has like leadership potential and who's gonna make your company and probably your program just look amazing because they're just really good but potentially you're gonna get poached away for something a little bit more fancy pretty quickly like you never know. Or do you want somebody who's gonna be really solid who's gonna just like get into your code base and just learn it really, really deeply and really effectively and be happy to hang out for a couple years. Like you understand like where you want this person to go and what they're gonna do for your program and then hire appropriately, right? So not all personalities are gonna fill the same role in the same way. So things to look for are just like thinking about how they're gonna fit in the group. So there's this interesting idea when you're thinking about group dynamics and you'll see this a lot in just companies and organizations and it's this like 1080-10 rule which means that essentially when you have a group of people, they'll be broken out into three groups. So you'll have the top 10%, these are sort of like the leaders. These are the people who are, they're going to excel kind of no matter where you put them they're really motivated, they're gonna push really hard and they really just are sort of driven to lead. These are the people who tend, you kind of tend to gravitate to, you're like, oh I want to hire that person but they're also the people who maybe that's not actually what you want, right? They're the people who are kind of gonna be the movers and shakers and they might mix things up and change things a little bit. The middle 80%, these are the people who are more than happy to do the work that is asked of them, they're not gonna rock the boat, they're gonna be really consistent, they're solid, they're really stable and they're gonna execute really well and they're consistent. This is like obviously 80%, this is the majority of people that you end up working with and then there's the bottom 10% which are, they're kind of like the dumpster fires that are cleverly disguised as humans. So we're gonna just assume that you can tell when those people are in front of you and you're not gonna hire them so we're gonna focus on the top 10% and that middle 80% and again like the group that you want your apprentice to come from really just depends on what your long-term goals are for that person and for that role and so you just have to make sure that you're hiring from the right group. So, things to consider when you are looking for your apprentice that attitude really counts for a lot. So I've worked with around 150 people that have taken from like zero to getting jobs and I focus on the first section of their time at Turing. So I'm like mama bearing them when they're in their first like what is happening to me phases of school and so the patterns, I've gotten very good at like noticing patterns and behaviors that indicate someone is gonna be successful in this environment and then which patterns indicate that somebody might not be. And people who really excel in these types of situations in these sort of like semi-self-directed learning environments have a shared set of qualities. So, things that they tend to do they're very engaged. So these are people who they're very curious they wanna go investigate if they see something they don't understand they don't wait for you to kinda give them a nudge to go check it out they're just in it. They just, they start checking it out they start digging around and start poking around and investigating things on their own. And they also generally because they're really curious and they're really engaged they find ways to make it fun for themselves. And fun makes you learn things better. It makes you learn faster if you're able to make things interesting for yourself. It means that learning is gonna come easier to you. They're also loyal. These are people who like if things get if things get harder kinda go off course because this is a business and you never know like maybe you're gonna lose a client maybe something weird's gonna happen. They're not gonna they're not gonna bail they're not gonna freak out they're gonna like they're gonna stay the course. They're vocal and they're honest, right? So these are people who they're not gonna be confrontational and they're not gonna be irrational but if something is wrong or if they don't like something they're gonna speak up and they're gonna talk to you about it. You have high standards? They have high standards. These people are often top performers they're used to excelling at things they understand what success looks like and they understand how much work it takes to get to that point. So they understand effort and they understand what it takes to get there. And then they're dedicated. So again, if you give them something they're gonna do it to the best of their ability and they're not and they're if they get stuck they're gonna ask you for help. Great. Obviously like again when things get hard they're not gonna bail on you they're gonna keep cranking they're not gonna give up even if things get uncomfortable because they know that things will get better and that they'll grow. And then they're just good natured. Programming is hard. Learning to program is hard. You wanna be working with someone who's gonna make it a fun experience for you and for them. So, and then again like you have that it's like it's one thing to have like that list of like what to look for but then it's another thing to actually be able to like like identify that in a candidate. Like how do you actually know that they're really like that? It's very easy for some. I mean some people are really good at just jazz handsing their way through interviews and then they actually show up show up on day one and you're like oh you are not who I thought you were. So it's like how do you how do you avoid that? Right, so that's a little bit of a tricky thing. So it's important to start to think about like how do you separate the people who are really great from the people who are just really good at interviewing. So things to look at their track record. What have they been up to? Like have they actually shown that they are able to tough out hard things when things get hard do they do they bail? Or do they tough it out? Like have they been floating out like as Wayne from Wayne's World says he has many name tags and hair nets. So like you don't want someone who's like that. You want somebody who's able to show that they can like hang in there, tough it out, grow in a role and be there through the hard times and the good times. Again, you wanna show that they're able to like tough it out through difficult times. So this could be shown in a previous career like whatever that is. I don't care if they were like an attorney or if they were working as a line cook. There are difficult things in every job and there's potential to demonstrate that they're gritty and tough and can handle things in any position they've had before. Or in school, right? So like if they were able to deal with a difficult program or just get through school in a way that is successful. There are many ways that they could show this to you. And essentially what you're just looking for is that they're able to make steady and consistent forward progress when they set their minds to doing something. And then another thing to think about is just how do they like really pay attention to how they're answering questions. Again, like the jazz handsers, they're gonna be trying to like target what they think you wanna hear and they're gonna tell you that. But really, are they, but if you pay attention to them and if they're thinking about how they take your question and they apply it to their own experiences, that's important. So be mindful if you think that they're just telling you what you wanna hear or if they're actually taking your question and answering it truthfully. And to help you see if this is what they're doing, you can set up a situation where you're asking leading questions where you might say like, what would you do in an example situation? Like if a client calls you and they're really upset about something, what do you do? How do you handle it? They might answer, they might tell you like what they might do hypothetically. And then you say, like you listen to it, you hear them out and you say, cool, like great, that's awesome. Can you give me an example when you did that in a real situation? Like tell me when you actually did that. And someone who actually has done that will tell you about it or that's how they would answer the question initially and someone who never has and is just sort of like playing to your question might not have that answer for you. It's also useful. So something that I've seen especially with apprenticeships is that oftentimes that like the actual code challenge gets passed over because people just assume that this person's gonna learn on the job. I don't really need to do a code challenge with them. That's not something that's super important. But it actually is, right? And it's less about should I hire this person or not because you understand that they don't know everything and they may be pretty soft in certain areas but it's more around just so on day one when they come in you know where they're coming from and you know where their skills are. So this is just to kind of help you understand what your starting point is. So, yeah, just it gives you an idea of like do they understand the language? What's their handle on syntax? Do they understand what normal workflow looks like? Do they understand version controller? Like how to pair with people? Just basic stuff around just experience with the industry. And then again, keep your end goals in mind. So have a plan like just keep your eye on the prize of like where do you want this person to end up at the end of your program? Do you want them to be a part of your team for a long time? Or do you want them to come through the program? Be really successful and then like spread their wings and go somewhere else. Like who knows? Just be mindful of that and then hire appropriately and gauge appropriately. All right, so you have done all your planning before you started an apprenticeship. You have hired the right person. You have a plan. Your whole team is on board. So now what do you do? Great. How do you get it all together? So when you are hiring someone who's never worked in the industry before onboarding is a little bit different than someone who understands your routine and knows what to do with everything. So it's a great idea to just get some things in place to have one central location where all of this information is available again to the apprentice and the rest of your team so everyone's on the same page about things. A very sort of simple low effort way to do this is to just have like you can make a document. You can just like open, you can do something in Google Docs, have some sort of a calendar or something where you have all the relevant and important links in one place so your apprentice can just bookmark one thing and then they have access to everything so they don't have to chase it all around. And things that they might need could include what repos they need access to and then who's gonna be taking care of that for them? Who's gonna actually give them access to all these things? Any specific systems set up that they need to have before you get started? So they have access to all, again, so they have access to this. They know where to go. They know where to look for it. Any communication channels that they should have access to before you get started? You wanna, that means like, if it's Slack, HipChat, whatever, make sure that they're in the main channels that your team communicates with so they're able to hit the ground running and they're not sort of out in the cold and feeling a little bit ignored. Any important calendars? Calendars are great. That's always important again so you can track timelines. This is also a place where you can put all of those details around like goals for where they need to be every week. That's also great. And then just directions for how to contribute to a code base. Like how does your team follow specific rules? You can assume that this person has done this before so it's important to make sure that it might seem a little bit silly or a little bit obvious, but this is someone who hasn't worked in this industry before so silly and obvious is okay. It's not silly. It's good. So just any sort of directives around how to contribute to code bases and giving them enough information that they can kind of dive right in and start taking a crack at contributing. And then also just if there are meetings like stand-ups, team meetings, staff meetings, whatever, make sure that they understand when that is so they're able to go to that when they need to. It's also important to have a syllabus and a schedule. So again, calendars and then some sort of a structure for your curriculum. Again, this is all about communication and your calendar's gonna map out expectations and timelines that are going to allow your apprentice to have a clear upwards trajectory of skills and progression that you expect them to be hitting. And this is something that is going to just allow them so they can keep track every week as they're working. So for your syllabus, again, it's your learning goals for every week. And it gives the apprentice a place to see where they're headed and what they need to be focusing on. That could include like a list of useful resources. So if there are tutorials, documentation, things like that that would help them get hit those goals for that week, that's a great place to put it, assignments. So we'll talk about what that might look like in a minute, but you could potentially have like assignments that they could be working on. So outside of just like teamwork or like billable work, they could have things that they're actually working on to like just keep improving. And then checks for understanding. So ways that they can actually confirm that they're learning what they need to be learning. And this just takes some of the mystery out of the learning process, because again, it's very explicit and it's very clear and it's giving them a clear path forward with a clear like upward trajectory of steps and that they should be taking. Okay, so again, during when we are evaluating progress, this kind of comes back to that idea of that rubric that we talked about a little bit from like novice to exceptional or one to four, those kinds of ideas. It's important to understand that you have a way to track that they actually are making the progress that you need them to be making. So if we consider our evaluation rubric again, this gives us clear actionable documentation of like what understanding and progress looks like and it allows them to keep up a steady upward trajectory of progress as they keep working through the program. And then again, like for the actual sort of like assignments or things that they can be working on as they're growing and learning, this idea of a breakable toy is really useful. So this is essentially like a little project that's owned by the apprentice. It's a code base that's just fully owned by the apprentice and it has a lifespan that's the length of the apprenticeship. And this is an interesting idea because it allows you to, it's non-billable code. It's owned by the apprentice and it allows them to have a thing they can break without worry that they're gonna like break an actual production code base. And it's also something that you can strategically just match learning goals with like features that you're having to build on this breakable toy. It gives them space to kind of get goofy and weird and have fun with it. So it allows them to have the freedom to sort of play with their code. It allows them to like kind of pick a topic or something about the project that they're really excited about and want to like play with. And that can be something that like trickles upwards into the rest of the team. Having fun and just building things because it's a fun project is really great. Another thing about this is it's really fun. Like you can just get weird with it and have fun. So one of the ways that again learning happens the most when you're in a place of just goofing around and having fun with things. So this is a great place to like fight through the hard problems because it's a project that's like a little bit of, it's just, it's near to their heart and they just really care about it. So something silly where they don't have the pressure of the actual client work is important. Something to keep in mind. An apprenticeship should be a safe place to fail. Failing is part of learning. It's like when you're learning to ride a bike and you first take the training wheels off and you realize that you have to think really hard about riding the bike and staying on the bike and then you're gonna fall off the bike a lot with that point. The more you're thinking about it, the more you're gonna fall off of it and that's okay. And then gradually you realize that you have to think about the bike less and then eventually you realize that you're not thinking about the bike at all and you're just getting on the bike and riding away. And that's okay. If they fall off the bike, if they break things, that's okay. It's the same deal with software is riding a bicycle. You have to just encourage them to keep getting back on the bike and you have to let them break things. Don't make a huge deal out of it but let them know that they did it and then make them fix it. Don't fix it for them, don't follow them around. They're not delicate flowers, they can fix it themselves. But be supportive and then help them when they need it. And again, as you move forward, they should be able to do that with less and less and less hand holding. And then what do you do if the worst happens? Let's say you get started. The team was really into it. You found someone you thought was gonna be a really great fit and then things start going sideways. Maybe you realized that this person you thought was gonna be a great fit. Maybe isn't meshing well with your team. Maybe they're not learning at the rate that they needed that you needed them to. There could be many things that are happening that mean that this isn't gonna work out. Just be honest and upfront about it. Things that I've seen happen sometimes is that apprenticeship programs can get dragged out well beyond their useful lifespan and that doesn't do the team any favors, it doesn't do the apprentice any favors. They probably know that they're struggling at that point and keeping them around in that way isn't really doing them any favors, it's not kind. So it's better to just call a spade a spade. If it's not working out, it doesn't mean that they can't do this, it probably just means that this isn't the right fit for them. Or maybe they're okay but you ran out of money. Like that could happen too, maybe you lost a big account, maybe you lost a client, maybe just the business, just something happened to the business and you lost users or something, that's okay, that happens but never put someone, especially an apprentice, don't put someone in a position where you can't pay them and you want them to work for experience. So if you get to a point where there is not money for them, again, cut them loose. Like let them know what's happening, keep them in the loop and then cut them loose. And the thing is that bad things happen, it's okay, just be fair and be honest about it and really do your best to set them up for success and try to help them land on their feet, right? So the way that an apprenticeship ends, whether it's the happy path where you now have a new junior dev on your team who's just crushing it and just kicking ass and doing everything perfectly or you have someone who just didn't work out for whatever reason, the way that that ends says a lot about your team. And if worst case scenario happens and it's not working out, the way that you handle that and if you're able to end on good terms with this person and support them and really still try to help them land on their feet, speaks very highly about you and your team. So again, just make sure that you are being respectful and kind for everything. And then I just have thanks to people who have helped me and then yeah, some resources for self mentorship. Okay, so the question is how would you adapt this advice for self mentorship? There are actually several, there are some great apprenticeships that have sort of like open source curriculum that they set up. There are also some schools that have like their curriculum that's online. Sparkbox has a really great, they have a really, like if you go on GitHub and just like Google Sparkbox you can find them. They have a very like clear, direct just like curriculum path for their apprenticeships that has lots of like tutorials, lots of like documentation, lots of things like that around there and then there's also various schools and things. So a lot of it's the same thing. Like you figure out it's like that backwards planning is super valuable. So if you think about where you wanna land and just start like working, like figuring out like from where you wanna be and then taking small steps forward. Does that answer your question? Yeah, okay, so the question is what is sort of like thoughts on taking an apprentice cohort rather than having them working together rather than having individual apprentices sort of like divide and conquer solo on side projects and things. I think that there's a lot of value in having like your battle buddies, right? So it's the same thing like in school. Like you have a group of people, you have a cohort that they're there to support you. They're there to bounce questions off of. They're people who are at a similar level to you. So maybe you don't feel quite as self-conscious if you get stuck on something that you think might be a little bit silly. I think that there's a lot of value in that. I think there's also value in kind of just if you're in a program that only has one apprentice kind of being like the only person there, like the lone wolf. There's also value in that and having to sort of get in there and just force yourself to talk to the senior people who might be intimidating. But I think they're absolutely, if you are in a position where you can have a cohort of people who can like support each other, I think there's a lot of value in that. Sure, sure. Okay, so sort of question is like how do you sort of keep your bias, your sort of like internal biases from impacting the way you're hiring decisions even if like some of the things that you're sort of hiring for tend to maybe be a little bit more generally considered like masculine side, okay. So I think something to consider with that is and part of that is just like the interview process and setting this person up to feel like comfortable in that and you'll find that it's interesting because like we see this also when we're interviewing students as well. You'll have people who come from these not like non-white guy backgrounds and they'll come into the interview and they'll sort of start out with the normal like maybe I'm a little bit more quiet, a little more reserved and then you start talking to them and you ask them the right questions and you realize that like they're crushing it and they're amazing and that they're super smart and they're really good and they have opinions and they're able to do these things and I think a lot of it is just setting up the interview process in a way that allows people to have room and space to tell their stories really effectively and to be safe. So some of that is just forcing yourself to make sure that your interview process is structured in a way that you're not intimidating people, you're not making people uncomfortable. It's also about outreach as well, right. So making sure that you are getting word of your apprenticeship out there so people who are maybe from these different, more diverse backgrounds know about it and they're able to talk to speak to it or to see it and apply for it. Does that answer your question? Yeah, so I think absolutely the expectation should be set that in the beginning of the, oh sorry, so the question was just like the balance of like billable work versus non-billable work during the course of the apprenticeship, is that correct? Okay, so, sure, yeah. So if we're talking about, so billable work, so first just what I mean when I say billable work, like when you're on the job, when you're going to like your time sheet and you're putting in what I did today, billable work would be the things that are actually, the tasks that you've done that are allowing the company to make money. So that could be like actually pushing production code, like doing things like that, things like meetings or like internal meetings or like reading documentation or doing tutorials or something like that, that's non-billable. But like actually like writing production code and like pushing that up and getting that live, that's all part of your billable hours. And as an apprentice, part of this role and part of this job is that you are learning. So what it should be that in the beginning, your hours are skewed more heavily on the non-billable side. So you're working on like your breakable toy project, you're working on something that isn't necessarily contributing to the inflow of cash to the company, but you are still growing and you're still learning really well. And so, but the idea is that in the beginning, you're gonna be learning, you're gonna be ramping up and figuring all this stuff out. And then during the course of the apprenticeship, you should be that ratio of billable to non-billable should flip and you're gonna be having almost basically by the end of it, you should be at sort of like normal billable hours for a junior dev. So whatever that breaks down to for that company. So I'm not sure like what percentage that would might be per company, but like there are certain sort of like acceptable, acceptable amounts of hours that should be billable. So you would want to by the end of it, the idea would be that you'd be at that point and then you'd have less time dedicated to like learning and that sort of thing. And then in the beginning, it'd be much more heavily skewed towards learning. Did that answer your question? Cool, any other questions? All right, thank you so much.