Empowering Early-Career Developers
Bernard, Mercedes
How can teams invest in and grow their less experienced developers into team-leading senior devs? I believe the first step is empowering them. On my team, we’ve created a process for each team member to lead and own one of our core features. Our early-career developers are learning client management and team leadership skills that they wouldn’t usually get to practice until they stepped into a senior role. In this talk, I’ll share our process and what we’ve learned so you can give your early-career developers valuable experience they need to become successful, senior team members.
 Hello, great my mic's on. So I'm here today to talk to you about empowering early career developers. We're going to talk about why it's important, what we've been doing on my team, and some strategies that you can bring to your team to empower your early career devs. Like Megan said, my name is Mercedes Bernard and I'm a senior software engineer with Tandem, formerly known as DevMind, so you guys all get to be the first ones to hear that we're changing our name and rebranding. So yeah, let's get started. Oh, there we go. Okay. I want you all to just take a second and reflect back on your career progression. How did you get to where you are today? How did you grow from an intern or an apprentice or an entry level to your current role? Did it feel a little bit like trial by fire? Or what about like drinking from a waterfall? My experience definitely did and I can think of a few instances in particular, like at my first job while I was still in school and I had to explain to a very angry client at 1 a.m. why deploying untested code to production was a bad idea. Or another time at my first job out of school when a large payment transaction project fell in my lap that had been poorly estimated by someone else and then I was on my own to manage unrealistic client expectations. In both of these scenarios, I did not have the support of someone in a senior or lead role. And unfortunately, I don't think my experience is uncommon. There has to be a better way. On my current team, I lead a team of eight developers. This isn't my first time leading a project, but it is the first time I've led such a large team of varying experience levels and that I've shared responsibility for their professional growth. And like Megan said, I've also started a community in Chicago called DevTogether that connects people starting their development careers with technical mentors. Both of these experiences have opened my eyes to the tremendous need in our industry for mentorship and coaching for those early in their career, which brings me to the problem with our current technology market. Companies are scared to invest in junior talent. If you look at any of the job boards right now, everybody is trying to hire teams of rock star senior devs. And I don't mean to call out anybody here at the conference or any of our sponsors, but I took a look at that job board, senior, principal, lead, senior-ish. That was my favorite. And in my opinion, this is just a losing strategy. It costs so much money to hire a team of all seniors. There's the recruiting costs, their salaries, and the cost of attrition that comes from lack of career growth opportunity. Because when everybody's a senior, how do you grow and improve? Also, not every task on a project requires a senior's experience. Companies are overpaying for work that people early in their career could be challenged by and learn from. In my opinion, it costs less to mentor early career devs than it does to hire a team of all seniors. And the argument that the seniors that you do have don't have time to do this mentorship isn't valid. Your mid-level and senior-level engineers need to practice these mentorship and coaching skills if you want to grow managers and leads who teams want to work with. It's an unfortunate reality in our industry that job hopping is often the quickest and easiest way to level up. So I can understand why that would make some companies hesitant to invest in their early career talent. They fear that after they spend all of this time, money, and energy, their early career devs are just going to go leave to get that mid- or senior title. But where do you think senior developers come from? I was talking to somebody recently who made the joke of the senior developer stork. It just doesn't exist. People who feel valued, who are challenged, and who have the support of their leads and management are more likely to stay and grow with your company than those who are just given the intern work or the busy work, and they'll just leave to find variety or something different. So I've been reflecting on how to improve this mentorship and coaching that our industry so desperately needs. And we need to empower our early career talent if we want to retain them and grow them into the senior devs that we're all looking for. So I want to go back to the title of this talk for just a second. Empowering early career devs. And I want to unpack what I mean for just a minute. This is the definition of empower that I particularly like and use. To make someone stronger and more confident through encouragement and support of their ability. I want to highlight just two pieces of this definition. The first is more confident. Of course, we want to grow strong developers and strong development skills, but we should also want our developers to own their growth. We should want confident independent devs. And the last four words of this definition are my favorite. Support of their ability. Everyone has innate strengths and everyone is capable. By encouraging the talents that the members of your team already have, you can grow them into the skills needed to make amazing team leads. So you may have noticed by now that I'm trying really hard to avoid using the word junior. And I'm replacing it instead with early career devs. So let me just make explicit what I mean when I say early career. All I mean is somebody who's beginning their development career. So why is this reframing from junior to early career so important? Let's just be blunt. Junior has a negative connotation. I don't think it's warranted and I don't think it's earned, but unfortunately there's a lot of people in our industry who view junior as probationary and other forms of less than rather than just as somebody who's learning. And because of that negative connotation, it causes imposter syndrome to abound. If the person you're talking to thinks you mean junior as less than, they're going to feel less than when you use it. And just because this is somebody's first development job does not mean that they're junior. Career switchers have so many transferable skills and often it's the communication and soft skills that are the hardest to learn on the job. Early career devs bring fresh perspectives and no bad habits to unlearn. And in my experience, they bring all of the enthusiasm and none of the arrogance that comes from a lot of senior technologists. So when we're talking about this group of people, shouldn't we want to use positive language when we're talking about them instead of labeling them as junior? So I want to switch gears for just a second and talk about the opposite end of the spectrum and talk about the senior developers. So what makes a senior developer? I'm sure everyone in this room has some ideas about the defining characteristics. But for me, I've broken the traits into two main categories of skills and experience. So in my opinion, a senior dev is somebody who has really strong technical communication, time management, meeting facilitation, consulting, and client engagement. But they also have experience, making decisions, being held accountable to those decisions, looking at the big picture and leading a team. Now you might look at my list and go, well, that skews really heavy towards the consulting side and it's totally true it does. That's where all my experience is. So if you focus on product dev or other forms of dev, your list might look different and that's totally cool. So how do we foster growth in someone who's early in their career into a team leading senior dev who has all of these traits? We need to give our early career devs the opportunity to practice these skills and to gain this experience before they step into a lead role. Remember the first time that they're in front of a team, we don't want it to feel like a trial by fire experience. On my project, we've been putting some processes in place to facilitate these kinds of opportunities. So I'm going to talk about what we've done, what we've learned, and then specific strategies that you can bring to your teams to empower your early career devs. So looking back on what my team's done over the last few months, it kind of follows this framework. So this is what I'm going to be using for this talk. There's three phases to what we did. So in the first phase, prepare, my manager and I had a lot of conversations about ways that we could coach and mentor our team to help their professional growth. We wanted to find ways in which they could practice skills that they weren't getting a chance to practice. We also wanted the whole team to share more ownership over our project. So I started by thinking, how am I a silo? How am I as a lead kind of hoarding all of these responsibilities and not letting my team get insight into them and not letting them get the experience that they need to level up? For our project and my team, the answer was client communication. I owned almost all of the technical communication with the client, which left my team with almost no space in which to practice those skills and grow. I was also responsible for leading a lot of our meetings and for making a lot of our decisions and quite frankly, my team was ready to share that responsibility with me. So after reflecting on that, I tried to come up with a purpose of what I wanted to do. So for me, I wanted all members of our team to gain consulting, client engagement and leadership experience. Ultimately, what we ended up doing is having every member of our team own a feature area of our application. And then the last step in prepare is I had to prepare myself to delegate. This was the biggest challenge for me personally and I'm seeing some head nods in the room, so I think it's a really common challenge for anyone in a leadership role. But it's really important to share that responsibility and that accountability with your team. The way that I've been trying to reframe how I think about it is like the grounds crew at an airport. So I'm sure a lot of you flew in over the last couple days and when the pilot needs to connect the airplane to the jetway bridge, it's vital that they perfectly center themselves on a white J-line that's painted on the tarmac. And the FAA actually requires three grounds crew members to direct the pilot because the door is behind the cockpit and that J-line needs to be under the plane, so there's no way that the pilot can see everything they need to in order to make that happen. And so as a lead, that should be your role on a project. Is paying attention to the things that your team might not see or might not be aware of and ultimately directing them towards their success. You're not jumping in the cockpit and doing it for them. So in the first phase, it was mostly my manager and I just talking and trying to come up with ways to put this plan into place. But I wanted to make sure that I introduced the plan to the team, that we created a shared understanding and that they were able to give me feedback on what they wanted out of it. So if we go back to the purpose, ours was client engagement, consulting and leadership and so these were the responsibilities that I presented to my team. So for us, our feature owner is the point of contact for everything related to their feature. They own all of the client communication, all of the questions, answers, everything related to their feature. They get to practice asking questions of the client, holding the client accountable to communication deliverables, but they also get to practice answering questions from the client like feature requests, priority and timeline. The feature owner is also responsible for documenting all the conversations they had with the client and everything they learned, plus things like system architecture, user stories, access control requirements and pretty much everything. Documentation is not a flashy part of consulting and we all know this, but I think that written communication skills are vastly undervalued and really, really difficult to learn. A natural extension of documentation is knowledge sharing. So we don't want all of this consulting work to happen in a vacuum and we don't want there to just be instead of one silo on the project, me, now eight silos. So it's up to the feature owner to make sure that everything that they've learned from the client and that they've documented gets disseminated out to the rest of the team. The feature owner also gets to practice their decision-making skills. So they're responsible and they're a key stakeholder in all decisions related to their feature. They get to practice both making the decision and then being held accountable to it later. They also have to advocate for whatever implementation decisions they make when they present them to the team. And finally, meetings. The feature owner is responsible for leading all of the meetings related to their feature. This builds domain expertise, meeting facilitation skills, and confidence. And on our team, it had the added benefit of having everyone learn when a meeting is valuable and when they could have just sent an email. So when my team and I were talking about what our new process would look like, I wanted to make sure that we all understood what it was not. The feature owner was not going to be the sole owner and decision maker. They'd still have the support of me, my manager, and the other seniors on the project, and they would be responsible for making decisions collaboratively with me, the design lead, and the product owner. And in the same way that a team lead doesn't write all the code for their project, the feature owner was not going to be writing all the code for their feature. They'd still have the support of their entire team members to make sure that all the tickets got picked up and worked on in a sprint. So now it was time for us to put our new process into practice. We have an ongoing rotation of Epic ownership where a few sprints before we're scheduled to start working on a feature, I assign it to one of our team members. It's up to them to go initiate the communication with the client and gather technical requirements, and their current workflow, and to raise or identify any risks that may happen before we start working. So you can see here that Shemile, one of my team members, had two really closely related features in the first sprint, and then his next one was in sprint four, where Sasha had a feature that spans sprints one and two, and so then her next feature was in sprint five. And like I mentioned before, the feature owner was responsible for all of the documentation for their feature. So what my team has done is created a folder in our Google Drive for each feature where they put any and all documentation that they come across. So you can see here it might be legacy whistles, the results of data modeling exercises, or just an ongoing list of questions and answers that we receive from the client. Chris, one of my team members, has actually started just keeping a Google doc where he labels every time he initiates questions with our client and then the answers that we get back. This has been really helpful in increasing transparency on the team because our client doesn't always respond to emails. Sometimes they slack us, sometimes they just pop into the office to answer something, and it can be really challenging for us to know which questions are still outstanding and which ones we have answers for. We also need to document decisions that we make. So Sasha, another one of my team members, had a conversation where we made some architecture decisions about what legacy infrastructure we would need to keep around for backwards compatibility and what we could sunset because we didn't require it anymore. So for her, all she had to do is take a picture of the whiteboard, add a few bullets about the decisions that were made, and then send an email to the team that's like, hey, if you have any questions, let me know, but just take a look. And sometimes documentation is not enough. So in this case, Sasha sent a meeting request to the entire team to say, hey, I want to review these two classes and how we're supposed to be using them, not like what we're actually using them for, which is really great to hold the whole team accountable to the responsibilities of our code. The feature owner also has to write the user stories for their feature. In the last few months of doing this, I have seen incredible growth. Our user stories have way more detail. The estimates are way better because we actually know what work we're going to be doing, and anyone on the team can pick them up and just hit the ground running. Rather than before, it was almost always the feature owner had to do all the work. So here you can see that Shamile wrote a user story where he gave us like a high-level description, some implementation notes, and he also attached a sample request file. So the person who was ready to work on it wouldn't have any questions. And throughout the feature implementation, our feature owner is also responsible for continuing that dialogue with the client as questions come up. So like I said before, it can be as simple as just, hey, these are the questions that are still outstanding or like this one came up. But sometimes it can be a little bit more challenging, like reminding the client that they promised us some deliverables and that they need to get those to us on time. So what are we learning from using a process like this? Well, I'm learning that delegating is really hard. It can be really challenging to clearly explain what it is that you're looking for and to fight that feeling of, well, just let me do it. It'll be faster. But it's really important as a lead and as a senior engineer on your team that you're taking a step back and giving your team the space they need to practice these skills. We're also learning how important feedback is. So it's super important that you as the senior engineer are giving positive feedback to the team about the things that they're doing amazing. Point out the ways in which you're seeing them grow. You want to fight that imposter syndrome. But it's also really important that you make the cycle of giving and receiving feedback so normal that constructive feedback isn't scary. It can be as simple as, hey, don't be afraid to redirect the client when they go on a tangent. Some strategies that I like to use are XYZ. You want to make sure that you're giving your team members the tools that they need to succeed. And similarly, make sure that you are asking them for constructive feedback on how you're doing. I got some feedback really early in this process that I needed to spend more time with my team prepping with them before they let a meeting. That was super valuable feedback, and it raised my awareness so now I can try to make more of an effort to put some time on the calendar so that they feel prepared to succeed in these meetings. We're also learning when to offer support. This can be as simple as explicitly asking, hey, how much support do you need on this? And anyone on the team can do it. We're going to be coming back to this idea of support in a minute, but it's really important that you're there for your team members. And finally, remember to check in with your team. It can be really easy to make assumptions about what challenges you think they are or are not ready for, but they know themselves best. So make sure you just check in, ask them how they're feeling and what skills they want to work on so that you can incorporate that as you continue to iterate and improve this process. So how can you bring a framework like this into your team? If we think about the three phases, I'm going to use those again while we talk about this. So in the first phase, prepare. Identify the skills that you, your team, and your company value in a senior engineer. Some ideas to get you started might include technical ability. Maybe it's learning React or Kotlin or whatever the new hot new framework might be. Or maybe it's getting better at database design or knowing when to do unit testing or integration testing. Or maybe it's just, hey, we're doing really well, but like our object-oriented skills aren't so great, so let's like have some fun and learn algorithms. Technical communication, both written and verbal. Time management. I don't think this one gets talked about enough, and I don't think people think of it as a skill that can be practiced and learned. But I hope that any of my senior engineers have really good time management skills since they're going to be juggling a lot of responsibilities. Maybe you want your senior engineers to be able to look at the big picture and be able to make decisions based on the product and not just the short-term feature timeline. Mentorship. This is especially important if you have a lot of mids on your team who are going to be stepping into the senior role soon. Consulting and client engagement. I know my list skews very consulting focused. This is just meant to get you started. So once you've identified the skills that you and your company value in your senior engineers, narrow it down and identify what are the gaps on my team specifically. The whole goal of this process is to create something that's tailored to your current team as it stands today. So some questions to ask to narrow this down might be, how are you as a lead a silo on the team? What skills do you wish your team got to practice? And what skills are needed for individuals to level up? And while you're going through these thought exercises, make sure you're considering the scope of your project. You want to make sure that your project is big enough to accommodate all of this new shared responsibility. You want to avoid the too many cooks in the kitchen problem. So on my project, it's 18 months long, there's lots of distinct application areas. By spreading this responsibility around, it actually decreased overhead and lightened everybody's load so that they could focus on their personal career goals. So now you have the skills you value, the ones you specifically want to encourage on your team. Make a clearly defined purpose that you want to achieve with that. You want your purpose to be narrow enough that it sets crystal clear expectations, but broad enough that there's a variety of ways that you can achieve it and that it gives your team a variety of opportunities to practice these skills. So as a reminder, my team's purpose for this new process was for everybody to gain consulting, client engagement, and leadership experience. You'll notice that I didn't list every skill that I value in a senior engineer. And I specifically stayed away from the hard technical skills because that just wasn't important for my team. But you'll also notice that my purpose isn't for people to get better at leading meetings because that's just too narrow and that doesn't give everyone enough space they need to grow. So how do you achieve this purpose? It's time to identify the responsibilities that would help you do that. Again, some questions that I asked that helped me identify them were what responsibilities satisfy one or more of the skill areas you chose? What types of tasks serve the purpose you identified? What responsibilities do you have as a lead that everyone on your team can share? And what responsibilities do you as an individual find challenging to keep up with? So these were the responsibilities that we outlined on my team. And I find it super helpful to identify three to seven responsibilities. Anything less than that and it becomes really easy to ignore and anything more than that is just unmanageable and you can't track it. I've also found it helps to write it down or visualize it in some way because if you can find responsibilities that satisfy more than one of your skill areas, that's a really good indicator that it's a good candidate for you to focus on. And by making them as clear as you can, it also makes it easier to track and talk about in one-on-ones or other types of reviews that you may do on your team. We've actually had one team member get a promotion in the last few months since we've done this and it was super helpful for him to have the vocabulary of all of the things that he's been working on and all of the experience he's gained during his yearly review. And I know I've said it a million times, but really, really you have to prepare yourself to delegate. It is so challenging but it is vital to making this process work. So in the proposed step, schedule some time with your team to introduce this plan. I know that having a framework like prepare, propose, and practice can feel really formal but the only goal is to tailor it to your team. So make it as formal or as informal as you want. When I introduced it to my team, I used a Wizard of Oz themed deck where every responsibility and every feature was a step on the yellow brick road until we hit Oz, which was the projects over, we've all grown, and we're done. And make sure that you're using this opportunity to solicit feedback. You should be asking your team or trying to understand if there's skills that they would like to practice that you may be missed. Do they feel comfortable but challenged by the responsibilities that you've outlined? Is there anything they want to add or clarify? And do they feel that this implementation will be sustainable? This last piece is really important. You don't want the responsibilities to be so overwhelming that your team is going to get burned out but you also don't want it to feel so easy that they can be ignored and put on the back burner. So now it's time to put your plan into practice. Again, follow through and delegate. Don't jump into that cockpit. Take the time to explain what you need your team to do and to support them while they do it. So there's lots of different ways that you can offer support. Some can be really formal. Some can have regularly scheduled one-on-ones with all the individuals on your team. That way they have a time and a place to talk about their specific challenges and their specific questions. But it might be as simple as reading an email before they send it just to make sure that their ask is clear or that their request is actionable. One of the challenges we've had on our team is getting responses from the client. So it can be really helpful to have another set of eyes on that email. Or maybe like me, you need to spend some time prepping with them before they lead a meeting. And for those who haven't had the responsibility of writing stories for their team, pairing can be really helpful. We all know it's hard to know how big to write the story or how small to write it or what details to include. And so having somebody there with you can make it a lot easier. And related to that, if somebody doesn't have a lot of experience doing data model or other architecture exercises, it can be helpful to pair with them on those as well. You can be there to ask questions that help guide their thinking so that ultimately it is them that's doing it. But you're just kind of there as training wheels until they get used to those types of decisions. And related to the story writing, data modeling, and architecture decisions, I found that it can be really helpful early on to send calendar invites just to set expectations for how long activities like that should take. You want to make sure that you don't have people on your team who are spending three days on something that should have just taken an afternoon or that they spent more than a cursory 15 minutes on something that they should have given their full day to. And just be kind and give them reminders about deadlines. They're taking on a lot of new responsibility and things can get lost in the shuffle. So it's as simple as saying, hey, I know you promised that documentation to the client by Friday. It's Wednesday. I'm just checking in to see how it's going. But above all, you want to make sure that the support that you're giving to your team is individualized. Every member of your team is going to have different strengths and challenges, and you want to make sure that you're giving them the support that works for them. Our industry is missing out on so much talent because we're not doing enough to support those early in our career. We all need to do our part to empower early career devs to grow them into the amazing seniors and team leads that we all know they can be. Thank you. Thank you.
 Hello, great my mic's on.  So I'm here today to talk to you about empowering early career developers.  We're going to talk about why it's important, what we've been doing on my team, and some  strategies that you can bring to your team to empower your early career devs.  Like Megan said, my name is Mercedes Bernard and I'm a senior software engineer with Tandem,  formerly known as DevMind, so you guys all get to be the first ones to hear that we're  changing our name and rebranding.  So yeah, let's get started.  Oh, there we go.  Okay.  I want you all to just take a second and reflect back on your career progression.  How did you get to where you are today?  How did you grow from an intern or an apprentice or an entry level to your current role?  Did it feel a little bit like trial by fire?  Or what about like drinking from a waterfall?  My experience definitely did and I can think of a few instances in particular, like at  my first job while I was still in school and I had to explain to a very angry client  at 1 a.m. why deploying untested code to production was a bad idea.  Or another time at my first job out of school when a large payment transaction project fell  in my lap that had been poorly estimated by someone else and then I was on my own to  manage unrealistic client expectations.  In both of these scenarios, I did not have the support of someone in a senior or lead  role.  And unfortunately, I don't think my experience is uncommon.  There has to be a better way.  On my current team, I lead a team of eight developers.  This isn't my first time leading a project, but it is the first time I've led such a  large team of varying experience levels and that I've shared responsibility for their  professional growth.  And like Megan said, I've also started a community in Chicago called DevTogether that connects  people starting their development careers with technical mentors.  Both of these experiences have opened my eyes to the tremendous need in our industry for  mentorship and coaching for those early in their career, which brings me to the problem  with our current technology market.  Companies are scared to invest in junior talent.  If you look at any of the job boards right now, everybody is trying to hire teams of  rock star senior devs.  And I don't mean to call out anybody here at the conference or any of our sponsors,  but I took a look at that job board, senior, principal, lead, senior-ish.  That was my favorite.  And in my opinion, this is just a losing strategy.  It costs so much money to hire a team of all seniors.  There's the recruiting costs, their salaries, and the cost of attrition that comes from  lack of career growth opportunity.  Because when everybody's a senior, how do you grow and improve?  Also, not every task on a project requires a senior's experience.  Companies are overpaying for work that people early in their career could be challenged  by and learn from.  In my opinion, it costs less to mentor early career devs than it does to hire a team of  all seniors.  And the argument that the seniors that you do have don't have time to do this mentorship  isn't valid.  Your mid-level and senior-level engineers need to practice these mentorship and coaching  skills if you want to grow managers and leads who teams want to work with.  It's an unfortunate reality in our industry that job hopping is often the quickest and  easiest way to level up.  So I can understand why that would make some companies hesitant to invest in their early  career talent.  They fear that after they spend all of this time, money, and energy, their early career  devs are just going to go leave to get that mid- or senior title.  But where do you think senior developers come from?  I was talking to somebody recently who made the joke of the senior developer stork.  It just doesn't exist.  People who feel valued, who are challenged, and who have the support of their leads and  management are more likely to stay and grow with your company than those who are just  given the intern work or the busy work, and they'll just leave to find variety or something  different.  So I've been reflecting on how to improve this mentorship and coaching that our industry  so desperately needs.  And we need to empower our early career talent if we want to retain them and grow them into  the senior devs that we're all looking for.  So I want to go back to the title of this talk for just a second.  Empowering early career devs.  And I want to unpack what I mean for just a minute.  This is the definition of empower that I particularly like and use.  To make someone stronger and more confident through encouragement and support of their  ability.  I want to highlight just two pieces of this definition.  The first is more confident.  Of course, we want to grow strong developers and strong development skills, but we should  also want our developers to own their growth.  We should want confident independent devs.  And the last four words of this definition are my favorite.  Support of their ability.  Everyone has innate strengths and everyone is capable.  By encouraging the talents that the members of your team already have, you can grow them  into the skills needed to make amazing team leads.  So you may have noticed by now that I'm trying really hard to avoid using the word junior.  And I'm replacing it instead with early career devs.  So let me just make explicit what I mean when I say early career.  All I mean is somebody who's beginning their development career.  So why is this reframing from junior to early career so important?  Let's just be blunt.  Junior has a negative connotation.  I don't think it's warranted and I don't think it's earned, but unfortunately there's  a lot of people in our industry who view junior as probationary and other forms of less than  rather than just as somebody who's learning.  And because of that negative connotation, it causes imposter syndrome to abound.  If the person you're talking to thinks you mean junior as less than, they're going to  feel less than when you use it.  And just because this is somebody's first development job does not mean that they're  junior.  Career switchers have so many transferable skills and often it's the communication and  soft skills that are the hardest to learn on the job.  Early career devs bring fresh perspectives and no bad habits to unlearn.  And in my experience, they bring all of the enthusiasm and none of the arrogance that  comes from a lot of senior technologists.  So when we're talking about this group of people, shouldn't we want to use positive  language when we're talking about them instead of labeling them as junior?  So I want to switch gears for just a second and talk about the opposite end of the spectrum  and talk about the senior developers.  So what makes a senior developer?  I'm sure everyone in this room has some ideas about the defining characteristics.  But for me, I've broken the traits into two main categories of skills and experience.  So in my opinion, a senior dev is somebody who has really strong technical communication,  time management, meeting facilitation, consulting, and client engagement.  But they also have experience, making decisions, being held accountable to those decisions,  looking at the big picture and leading a team.  Now you might look at my list and go, well, that skews really heavy towards the consulting  side and it's totally true it does.  That's where all my experience is.  So if you focus on product dev or other forms of dev, your list might look different and  that's totally cool.  So how do we foster growth in someone who's early in their career into a team leading  senior dev who has all of these traits?  We need to give our early career devs the opportunity to practice these skills and to  gain this experience before they step into a lead role.  Remember the first time that they're in front of a team, we don't want it to feel like a  trial by fire experience.  On my project, we've been putting some processes in place to facilitate these kinds of opportunities.  So I'm going to talk about what we've done, what we've learned, and then specific strategies  that you can bring to your teams to empower your early career devs.  So looking back on what my team's done over the last few months, it kind of follows this  framework.  So this is what I'm going to be using for this talk.  There's three phases to what we did.  So in the first phase, prepare, my manager and I had a lot of conversations about ways  that we could coach and mentor our team to help their professional growth.  We wanted to find ways in which they could practice skills that they weren't getting  a chance to practice.  We also wanted the whole team to share more ownership over our project.  So I started by thinking, how am I a silo?  How am I as a lead kind of hoarding all of these responsibilities and not letting my  team get insight into them and not letting them get the experience that they need to  level up?  For our project and my team, the answer was client communication.  I owned almost all of the technical communication with the client, which left my team with almost  no space in which to practice those skills and grow.  I was also responsible for leading a lot of our meetings and for making a lot of our  decisions and quite frankly, my team was ready to share that responsibility with me.  So after reflecting on that, I tried to come up with a purpose of what I wanted to do.  So for me, I wanted all members of our team to gain consulting, client engagement and  leadership experience.  Ultimately, what we ended up doing is having every member of our team own a feature area  of our application.  And then the last step in prepare is I had to prepare myself to delegate.  This was the biggest challenge for me personally and I'm seeing some head nods in the room,  so I think it's a really common challenge for anyone in a leadership role.  But it's really important to share that responsibility and that accountability with your team.  The way that I've been trying to reframe how I think about it is like the grounds crew  at an airport.  So I'm sure a lot of you flew in over the last couple days and when the pilot needs  to connect the airplane to the jetway bridge, it's vital that they perfectly center themselves  on a white J-line that's painted on the tarmac.  And the FAA actually requires three grounds crew members to direct the pilot because the  door is behind the cockpit and that J-line needs to be under the plane, so there's no  way that the pilot can see everything they need to in order to make that happen.  And so as a lead, that should be your role on a project.  Is paying attention to the things that your team might not see or might not be aware of  and ultimately directing them towards their success.  You're not jumping in the cockpit and doing it for them.  So in the first phase, it was mostly my manager and I just talking and trying to come up with  ways to put this plan into place.  But I wanted to make sure that I introduced the plan to the team, that we created a shared  understanding and that they were able to give me feedback on what they wanted out of it.  So if we go back to the purpose, ours was client engagement, consulting and leadership  and so these were the responsibilities that I presented to my team.  So for us, our feature owner is the point of contact for everything related to their  feature.  They own all of the client communication, all of the questions, answers, everything  related to their feature.  They get to practice asking questions of the client, holding the client accountable to  communication deliverables, but they also get to practice answering questions from the  client like feature requests, priority and timeline.  The feature owner is also responsible for documenting all the conversations they had  with the client and everything they learned, plus things like system architecture, user  stories, access control requirements and pretty much everything.  Documentation is not a flashy part of consulting and we all know this, but I think that written  communication skills are vastly undervalued and really, really difficult to learn.  A natural extension of documentation is knowledge sharing.  So we don't want all of this consulting work to happen in a vacuum and we don't want there  to just be instead of one silo on the project, me, now eight silos.  So it's up to the feature owner to make sure that everything that they've learned from  the client and that they've documented gets disseminated out to the rest of the team.  The feature owner also gets to practice their decision-making skills.  So they're responsible and they're a key stakeholder in all decisions related to their  feature.  They get to practice both making the decision and then being held accountable to it later.  They also have to advocate for whatever implementation decisions they make when they present them  to the team.  And finally, meetings.  The feature owner is responsible for leading all of the meetings related to their feature.  This builds domain expertise, meeting facilitation skills, and confidence.  And on our team, it had the added benefit of having everyone learn when a meeting is  valuable and when they could have just sent an email.  So when my team and I were talking about what our new process would look like, I wanted  to make sure that we all understood what it was not.  The feature owner was not going to be the sole owner and decision maker.  They'd still have the support of me, my manager, and the other seniors on the project, and  they would be responsible for making decisions collaboratively with me, the design lead,  and the product owner.  And in the same way that a team lead doesn't write all the code for their project, the  feature owner was not going to be writing all the code for their feature.  They'd still have the support of their entire team members to make sure that all the tickets  got picked up and worked on in a sprint.  So now it was time for us to put our new process into practice.  We have an ongoing rotation of Epic ownership where a few sprints before we're scheduled  to start working on a feature, I assign it to one of our team members.  It's up to them to go initiate the communication with the client and gather technical requirements,  and their current workflow, and to raise or identify any risks that may happen before  we start working.  So you can see here that Shemile, one of my team members, had two really closely related  features in the first sprint, and then his next one was in sprint four, where Sasha had  a feature that spans sprints one and two, and so then her next feature was in sprint  five.  And like I mentioned before, the feature owner was responsible for all of the documentation  for their feature.  So what my team has done is created a folder in our Google Drive for each feature where  they put any and all documentation that they come across.  So you can see here it might be legacy whistles, the results of data modeling exercises, or  just an ongoing list of questions and answers that we receive from the client.  Chris, one of my team members, has actually started just keeping a Google doc where he  labels every time he initiates questions with our client and then the answers that we get  back.  This has been really helpful in increasing transparency on the team because our client  doesn't always respond to emails.  Sometimes they slack us, sometimes they just pop into the office to answer something, and  it can be really challenging for us to know which questions are still outstanding and  which ones we have answers for.  We also need to document decisions that we make.  So Sasha, another one of my team members, had a conversation where we made some architecture  decisions about what legacy infrastructure we would need to keep around for backwards  compatibility and what we could sunset because we didn't require it anymore.  So for her, all she had to do is take a picture of the whiteboard, add a few bullets about  the decisions that were made, and then send an email to the team that's like, hey, if  you have any questions, let me know, but just take a look.  And sometimes documentation is not enough.  So in this case, Sasha sent a meeting request to the entire team to say, hey, I want to  review these two classes and how we're supposed to be using them, not like what we're actually  using them for, which is really great to hold the whole team accountable to the responsibilities  of our code.  The feature owner also has to write the user stories for their feature.  In the last few months of doing this, I have seen incredible growth.  Our user stories have way more detail.  The estimates are way better because we actually know what work we're going to be doing, and  anyone on the team can pick them up and just hit the ground running.  Rather than before, it was almost always the feature owner had to do all the work.  So here you can see that Shamile wrote a user story where he gave us like a high-level description,  some implementation notes, and he also attached a sample request file.  So the person who was ready to work on it wouldn't have any questions.  And throughout the feature implementation, our feature owner is also responsible for  continuing that dialogue with the client as questions come up.  So like I said before, it can be as simple as just, hey, these are the questions that  are still outstanding or like this one came up.  But sometimes it can be a little bit more challenging, like reminding the client that  they promised us some deliverables and that they need to get those to us on time.  So what are we learning from using a process like this?  Well, I'm learning that delegating is really hard.  It can be really challenging to clearly explain what it is that you're looking for and to  fight that feeling of, well, just let me do it.  It'll be faster.  But it's really important as a lead and as a senior engineer on your team that you're  taking a step back and giving your team the space they need to practice these skills.  We're also learning how important feedback is.  So it's super important that you as the senior engineer are giving positive feedback to the  team about the things that they're doing amazing.  Point out the ways in which you're seeing them grow.  You want to fight that imposter syndrome.  But it's also really important that you make the cycle of giving and receiving feedback  so normal that constructive feedback isn't scary.  It can be as simple as, hey, don't be afraid to redirect the client when they go on a tangent.  Some strategies that I like to use are XYZ.  You want to make sure that you're giving your team members the tools that they need to succeed.  And similarly, make sure that you are asking them for constructive feedback on how you're  doing.  I got some feedback really early in this process that I needed to spend more time with  my team prepping with them before they let a meeting.  That was super valuable feedback, and it raised my awareness so now I can try to make more  of an effort to put some time on the calendar so that they feel prepared to succeed in these  meetings.  We're also learning when to offer support.  This can be as simple as explicitly asking, hey, how much support do you need on this?  And anyone on the team can do it.  We're going to be coming back to this idea of support in a minute, but it's really important  that you're there for your team members.  And finally, remember to check in with your team.  It can be really easy to make assumptions about what challenges you think they are or  are not ready for, but they know themselves best.  So make sure you just check in, ask them how they're feeling and what skills they want  to work on so that you can incorporate that as you continue to iterate and improve this  process.  So how can you bring a framework like this into your team?  If we think about the three phases, I'm going to use those again while we talk about this.  So in the first phase, prepare.  Identify the skills that you, your team, and your company value in a senior engineer.  Some ideas to get you started might include technical ability.  Maybe it's learning React or Kotlin or whatever the new hot new framework might be.  Or maybe it's getting better at database design or knowing when to do unit testing or integration  testing.  Or maybe it's just, hey, we're doing really well, but like our object-oriented skills  aren't so great, so let's like have some fun and learn algorithms.  Technical communication, both written and verbal.  Time management.  I don't think this one gets talked about enough, and I don't think people think of it as a  skill that can be practiced and learned.  But I hope that any of my senior engineers have really good time management skills since  they're going to be juggling a lot of responsibilities.  Maybe you want your senior engineers to be able to look at the big picture and be able  to make decisions based on the product and not just the short-term feature timeline.  Mentorship.  This is especially important if you have a lot of mids on your team who are going to  be stepping into the senior role soon.  Consulting and client engagement.  I know my list skews very consulting focused.  This is just meant to get you started.  So once you've identified the skills that you and your company value in your senior  engineers, narrow it down and identify what are the gaps on my team specifically.  The whole goal of this process is to create something that's tailored to your current  team as it stands today.  So some questions to ask to narrow this down might be, how are you as a lead a silo on  the team?  What skills do you wish your team got to practice?  And what skills are needed for individuals to level up?  And while you're going through these thought exercises, make sure you're considering the  scope of your project.  You want to make sure that your project is big enough to accommodate all of this new  shared responsibility.  You want to avoid the too many cooks in the kitchen problem.  So on my project, it's 18 months long, there's lots of distinct application areas.  By spreading this responsibility around, it actually decreased overhead and lightened  everybody's load so that they could focus on their personal career goals.  So now you have the skills you value, the ones you specifically want to encourage on  your team.  Make a clearly defined purpose that you want to achieve with that.  You want your purpose to be narrow enough that it sets crystal clear expectations, but  broad enough that there's a variety of ways that you can achieve it and that it gives  your team a variety of opportunities to practice these skills.  So as a reminder, my team's purpose for this new process was for everybody to gain consulting,  client engagement, and leadership experience.  You'll notice that I didn't list every skill that I value in a senior engineer.  And I specifically stayed away from the hard technical skills because that just wasn't  important for my team.  But you'll also notice that my purpose isn't for people to get better at leading meetings  because that's just too narrow and that doesn't give everyone enough space they need to grow.  So how do you achieve this purpose?  It's time to identify the responsibilities that would help you do that.  Again, some questions that I asked that helped me identify them were what responsibilities  satisfy one or more of the skill areas you chose?  What types of tasks serve the purpose you identified?  What responsibilities do you have as a lead that everyone on your team can share?  And what responsibilities do you as an individual find challenging to keep up with?  So these were the responsibilities that we outlined on my team.  And I find it super helpful to identify three to seven responsibilities.  Anything less than that and it becomes really easy to ignore and anything more than that  is just unmanageable and you can't track it.  I've also found it helps to write it down or visualize it in some way because if you  can find responsibilities that satisfy more than one of your skill areas, that's a really  good indicator that it's a good candidate for you to focus on.  And by making them as clear as you can, it also makes it easier to track and talk about  in one-on-ones or other types of reviews that you may do on your team.  We've actually had one team member get a promotion in the last few months since we've done this  and it was super helpful for him to have the vocabulary of all of the things that he's  been working on and all of the experience he's gained during his yearly review.  And I know I've said it a million times, but really, really you have to prepare yourself  to delegate.  It is so challenging but it is vital to making this process work.  So in the proposed step, schedule some time with your team to introduce this plan.  I know that having a framework like prepare, propose, and practice can feel really formal  but the only goal is to tailor it to your team.  So make it as formal or as informal as you want.  When I introduced it to my team, I used a Wizard of Oz themed deck where every responsibility  and every feature was a step on the yellow brick road until we hit Oz, which was the  projects over, we've all grown, and we're done.  And make sure that you're using this opportunity to solicit feedback.  You should be asking your team or trying to understand if there's skills that they would  like to practice that you may be missed.  Do they feel comfortable but challenged by the responsibilities that you've outlined?  Is there anything they want to add or clarify?  And do they feel that this implementation will be sustainable?  This last piece is really important.  You don't want the responsibilities to be so overwhelming that your team is going to  get burned out but you also don't want it to feel so easy that they can be ignored and  put on the back burner.  So now it's time to put your plan into practice.  Again, follow through and delegate.  Don't jump into that cockpit.  Take the time to explain what you need your team to do and to support them while they  do it.  So there's lots of different ways that you can offer support.  Some can be really formal.  Some can have regularly scheduled one-on-ones with all the individuals on your team.  That way they have a time and a place to talk about their specific challenges and their  specific questions.  But it might be as simple as reading an email before they send it just to make sure that  their ask is clear or that their request is actionable.  One of the challenges we've had on our team is getting responses from the client.  So it can be really helpful to have another set of eyes on that email.  Or maybe like me, you need to spend some time prepping with them before they lead a meeting.  And for those who haven't had the responsibility of writing stories for their team, pairing  can be really helpful.  We all know it's hard to know how big to write the story or how small to write it or what  details to include.  And so having somebody there with you can make it a lot easier.  And related to that, if somebody doesn't have a lot of experience doing data model or other  architecture exercises, it can be helpful to pair with them on those as well.  You can be there to ask questions that help guide their thinking so that ultimately it  is them that's doing it.  But you're just kind of there as training wheels until they get used to those types  of decisions.  And related to the story writing, data modeling, and architecture decisions, I found that it  can be really helpful early on to send calendar invites just to set expectations for how long  activities like that should take.  You want to make sure that you don't have people on your team who are spending three  days on something that should have just taken an afternoon or that they spent more than a  cursory 15 minutes on something that they should have given their full day to.  And just be kind and give them reminders about deadlines.  They're taking on a lot of new responsibility and things can get lost in the shuffle.  So it's as simple as saying, hey, I know you promised that documentation to the client  by Friday.  It's Wednesday.  I'm just checking in to see how it's going.  But above all, you want to make sure that the support that you're giving to your team  is individualized.  Every member of your team is going to have different strengths and challenges, and you  want to make sure that you're giving them the support that works for them.  Our industry is missing out on so much talent because we're not doing enough to support  those early in our career.  We all need to do our part to empower early career devs to grow them into the amazing  seniors and team leads that we all know they can be.  Thank you.  Thank you.
RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_0_59.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_60_1739.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_1740_1871.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_1872_2855.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_2856_3035.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_3036_3887.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_3888_4007.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_4008_4139.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_4140_5735.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_5736_6227.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_6228_6851.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_6852_8327.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_8328_8711.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_8712_9683.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_9684_12251.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_12252_12431.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_12432_14339.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_14340_14507.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_14508_15791.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_15792_16763.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_16764_17339.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_17340_19115.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_19116_21539.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_21540_22151.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_22152_35855.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_35856_36287.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_36288_36683.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_36684_37595.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_37596_39071.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_39072_39299.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_39300_41747.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_41748_41831.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_41832_43715.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_43716_43979.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_43980_47279.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_47280_48179.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_48180_48359.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_48360_48527.png RubyConf_2018_-_Empowering_Early-Career_Developers_Qspf0SX_oPs_48528_48678.png
Hello, great my mic's on. So I'm here today to talk to you about empowering early career developers. We're going to talk about why it's important, what we've been doing on my team, and some strategies that you can bring to your team to empower your early career devs. Like Megan said, my name is Mercedes Bernard and I'm a senior software engineer with Tandem, formerly known as DevMind, so you guys all get to be the first ones to hear that we're changing our name and rebranding. So yeah, let's get started. Oh, there we go. Okay. I want you all to just take a second and reflect back on your career progression. How did you get to where you are today? How did you grow from an intern or an apprentice or an entry level to your current role? Did it feel a little bit like trial by fire? Or what about like drinking from a waterfall? My experience definitely did and I can think of a few instances in particular, like at my first job while I was still in school and I had to explain to a very angry client at 1 a.m. why deploying untested code to production was a bad idea. Or another time at my first job out of school when a large payment transaction project fell in my lap that had been poorly estimated by someone else and then I was on my own to manage unrealistic client expectations. In both of these scenarios, I did not have the support of someone in a senior or lead role. And unfortunately, I don't think my experience is uncommon. There has to be a better way. On my current team, I lead a team of eight developers. This isn't my first time leading a project, but it is the first time I've led such a large team of varying experience levels and that I've shared responsibility for their professional growth. And like Megan said, I've also started a community in Chicago called DevTogether that connects people starting their development careers with technical mentors. Both of these experiences have opened my eyes to the tremendous need in our industry for mentorship and coaching for those early in their career, which brings me to the problem with our current technology market. Companies are scared to invest in junior talent. If you look at any of the job boards right now, everybody is trying to hire teams of rock star senior devs. And I don't mean to call out anybody here at the conference or any of our sponsors, but I took a look at that job board, senior, principal, lead, senior-ish. That was my favorite. And in my opinion, this is just a losing strategy. It costs so much money to hire a team of all seniors. There's the recruiting costs, their salaries, and the cost of attrition that comes from lack of career growth opportunity. Because when everybody's a senior, how do you grow and improve? Also, not every task on a project requires a senior's experience. Companies are overpaying for work that people early in their career could be challenged by and learn from. In my opinion, it costs less to mentor early career devs than it does to hire a team of all seniors. And the argument that the seniors that you do have don't have time to do this mentorship isn't valid. Your mid-level and senior-level engineers need to practice these mentorship and coaching skills if you want to grow managers and leads who teams want to work with. It's an unfortunate reality in our industry that job hopping is often the quickest and easiest way to level up. So I can understand why that would make some companies hesitant to invest in their early career talent. They fear that after they spend all of this time, money, and energy, their early career devs are just going to go leave to get that mid- or senior title. But where do you think senior developers come from? I was talking to somebody recently who made the joke of the senior developer stork. It just doesn't exist. People who feel valued, who are challenged, and who have the support of their leads and management are more likely to stay and grow with your company than those who are just given the intern work or the busy work, and they'll just leave to find variety or something different. So I've been reflecting on how to improve this mentorship and coaching that our industry so desperately needs. And we need to empower our early career talent if we want to retain them and grow them into the senior devs that we're all looking for. So I want to go back to the title of this talk for just a second. Empowering early career devs. And I want to unpack what I mean for just a minute. This is the definition of empower that I particularly like and use. To make someone stronger and more confident through encouragement and support of their ability. I want to highlight just two pieces of this definition. The first is more confident. Of course, we want to grow strong developers and strong development skills, but we should also want our developers to own their growth. We should want confident independent devs. And the last four words of this definition are my favorite. Support of their ability. Everyone has innate strengths and everyone is capable. By encouraging the talents that the members of your team already have, you can grow them into the skills needed to make amazing team leads. So you may have noticed by now that I'm trying really hard to avoid using the word junior. And I'm replacing it instead with early career devs. So let me just make explicit what I mean when I say early career. All I mean is somebody who's beginning their development career. So why is this reframing from junior to early career so important? Let's just be blunt. Junior has a negative connotation. I don't think it's warranted and I don't think it's earned, but unfortunately there's a lot of people in our industry who view junior as probationary and other forms of less than rather than just as somebody who's learning. And because of that negative connotation, it causes imposter syndrome to abound. If the person you're talking to thinks you mean junior as less than, they're going to feel less than when you use it. And just because this is somebody's first development job does not mean that they're junior. Career switchers have so many transferable skills and often it's the communication and soft skills that are the hardest to learn on the job. Early career devs bring fresh perspectives and no bad habits to unlearn. And in my experience, they bring all of the enthusiasm and none of the arrogance that comes from a lot of senior technologists. So when we're talking about this group of people, shouldn't we want to use positive language when we're talking about them instead of labeling them as junior? So I want to switch gears for just a second and talk about the opposite end of the spectrum and talk about the senior developers. So what makes a senior developer? I'm sure everyone in this room has some ideas about the defining characteristics. But for me, I've broken the traits into two main categories of skills and experience. So in my opinion, a senior dev is somebody who has really strong technical communication, time management, meeting facilitation, consulting, and client engagement. But they also have experience, making decisions, being held accountable to those decisions, looking at the big picture and leading a team. Now you might look at my list and go, well, that skews really heavy towards the consulting side and it's totally true it does. That's where all my experience is. So if you focus on product dev or other forms of dev, your list might look different and that's totally cool. So how do we foster growth in someone who's early in their career into a team leading senior dev who has all of these traits? We need to give our early career devs the opportunity to practice these skills and to gain this experience before they step into a lead role. Remember the first time that they're in front of a team, we don't want it to feel like a trial by fire experience. On my project, we've been putting some processes in place to facilitate these kinds of opportunities. So I'm going to talk about what we've done, what we've learned, and then specific strategies that you can bring to your teams to empower your early career devs. So looking back on what my team's done over the last few months, it kind of follows this framework. So this is what I'm going to be using for this talk. There's three phases to what we did. So in the first phase, prepare, my manager and I had a lot of conversations about ways that we could coach and mentor our team to help their professional growth. We wanted to find ways in which they could practice skills that they weren't getting a chance to practice. We also wanted the whole team to share more ownership over our project. So I started by thinking, how am I a silo? How am I as a lead kind of hoarding all of these responsibilities and not letting my team get insight into them and not letting them get the experience that they need to level up? For our project and my team, the answer was client communication. I owned almost all of the technical communication with the client, which left my team with almost no space in which to practice those skills and grow. I was also responsible for leading a lot of our meetings and for making a lot of our decisions and quite frankly, my team was ready to share that responsibility with me. So after reflecting on that, I tried to come up with a purpose of what I wanted to do. So for me, I wanted all members of our team to gain consulting, client engagement and leadership experience. Ultimately, what we ended up doing is having every member of our team own a feature area of our application. And then the last step in prepare is I had to prepare myself to delegate. This was the biggest challenge for me personally and I'm seeing some head nods in the room, so I think it's a really common challenge for anyone in a leadership role. But it's really important to share that responsibility and that accountability with your team. The way that I've been trying to reframe how I think about it is like the grounds crew at an airport. So I'm sure a lot of you flew in over the last couple days and when the pilot needs to connect the airplane to the jetway bridge, it's vital that they perfectly center themselves on a white J-line that's painted on the tarmac. And the FAA actually requires three grounds crew members to direct the pilot because the door is behind the cockpit and that J-line needs to be under the plane, so there's no way that the pilot can see everything they need to in order to make that happen. And so as a lead, that should be your role on a project. Is paying attention to the things that your team might not see or might not be aware of and ultimately directing them towards their success. You're not jumping in the cockpit and doing it for them. So in the first phase, it was mostly my manager and I just talking and trying to come up with ways to put this plan into place. But I wanted to make sure that I introduced the plan to the team, that we created a shared understanding and that they were able to give me feedback on what they wanted out of it. So if we go back to the purpose, ours was client engagement, consulting and leadership and so these were the responsibilities that I presented to my team. So for us, our feature owner is the point of contact for everything related to their feature. They own all of the client communication, all of the questions, answers, everything related to their feature. They get to practice asking questions of the client, holding the client accountable to communication deliverables, but they also get to practice answering questions from the client like feature requests, priority and timeline. The feature owner is also responsible for documenting all the conversations they had with the client and everything they learned, plus things like system architecture, user stories, access control requirements and pretty much everything. Documentation is not a flashy part of consulting and we all know this, but I think that written communication skills are vastly undervalued and really, really difficult to learn. A natural extension of documentation is knowledge sharing. So we don't want all of this consulting work to happen in a vacuum and we don't want there to just be instead of one silo on the project, me, now eight silos. So it's up to the feature owner to make sure that everything that they've learned from the client and that they've documented gets disseminated out to the rest of the team. The feature owner also gets to practice their decision-making skills. So they're responsible and they're a key stakeholder in all decisions related to their feature. They get to practice both making the decision and then being held accountable to it later. They also have to advocate for whatever implementation decisions they make when they present them to the team. And finally, meetings. The feature owner is responsible for leading all of the meetings related to their feature. This builds domain expertise, meeting facilitation skills, and confidence. And on our team, it had the added benefit of having everyone learn when a meeting is valuable and when they could have just sent an email. So when my team and I were talking about what our new process would look like, I wanted to make sure that we all understood what it was not. The feature owner was not going to be the sole owner and decision maker. They'd still have the support of me, my manager, and the other seniors on the project, and they would be responsible for making decisions collaboratively with me, the design lead, and the product owner. And in the same way that a team lead doesn't write all the code for their project, the feature owner was not going to be writing all the code for their feature. They'd still have the support of their entire team members to make sure that all the tickets got picked up and worked on in a sprint. So now it was time for us to put our new process into practice. We have an ongoing rotation of Epic ownership where a few sprints before we're scheduled to start working on a feature, I assign it to one of our team members. It's up to them to go initiate the communication with the client and gather technical requirements, and their current workflow, and to raise or identify any risks that may happen before we start working. So you can see here that Shemile, one of my team members, had two really closely related features in the first sprint, and then his next one was in sprint four, where Sasha had a feature that spans sprints one and two, and so then her next feature was in sprint five. And like I mentioned before, the feature owner was responsible for all of the documentation for their feature. So what my team has done is created a folder in our Google Drive for each feature where they put any and all documentation that they come across. So you can see here it might be legacy whistles, the results of data modeling exercises, or just an ongoing list of questions and answers that we receive from the client. Chris, one of my team members, has actually started just keeping a Google doc where he labels every time he initiates questions with our client and then the answers that we get back. This has been really helpful in increasing transparency on the team because our client doesn't always respond to emails. Sometimes they slack us, sometimes they just pop into the office to answer something, and it can be really challenging for us to know which questions are still outstanding and which ones we have answers for. We also need to document decisions that we make. So Sasha, another one of my team members, had a conversation where we made some architecture decisions about what legacy infrastructure we would need to keep around for backwards compatibility and what we could sunset because we didn't require it anymore. So for her, all she had to do is take a picture of the whiteboard, add a few bullets about the decisions that were made, and then send an email to the team that's like, hey, if you have any questions, let me know, but just take a look. And sometimes documentation is not enough. So in this case, Sasha sent a meeting request to the entire team to say, hey, I want to review these two classes and how we're supposed to be using them, not like what we're actually using them for, which is really great to hold the whole team accountable to the responsibilities of our code. The feature owner also has to write the user stories for their feature. In the last few months of doing this, I have seen incredible growth. Our user stories have way more detail. The estimates are way better because we actually know what work we're going to be doing, and anyone on the team can pick them up and just hit the ground running. Rather than before, it was almost always the feature owner had to do all the work. So here you can see that Shamile wrote a user story where he gave us like a high-level description, some implementation notes, and he also attached a sample request file. So the person who was ready to work on it wouldn't have any questions. And throughout the feature implementation, our feature owner is also responsible for continuing that dialogue with the client as questions come up. So like I said before, it can be as simple as just, hey, these are the questions that are still outstanding or like this one came up. But sometimes it can be a little bit more challenging, like reminding the client that they promised us some deliverables and that they need to get those to us on time. So what are we learning from using a process like this? Well, I'm learning that delegating is really hard. It can be really challenging to clearly explain what it is that you're looking for and to fight that feeling of, well, just let me do it. It'll be faster. But it's really important as a lead and as a senior engineer on your team that you're taking a step back and giving your team the space they need to practice these skills. We're also learning how important feedback is. So it's super important that you as the senior engineer are giving positive feedback to the team about the things that they're doing amazing. Point out the ways in which you're seeing them grow. You want to fight that imposter syndrome. But it's also really important that you make the cycle of giving and receiving feedback so normal that constructive feedback isn't scary. It can be as simple as, hey, don't be afraid to redirect the client when they go on a tangent. Some strategies that I like to use are XYZ. You want to make sure that you're giving your team members the tools that they need to succeed. And similarly, make sure that you are asking them for constructive feedback on how you're doing. I got some feedback really early in this process that I needed to spend more time with my team prepping with them before they let a meeting. That was super valuable feedback, and it raised my awareness so now I can try to make more of an effort to put some time on the calendar so that they feel prepared to succeed in these meetings. We're also learning when to offer support. This can be as simple as explicitly asking, hey, how much support do you need on this? And anyone on the team can do it. We're going to be coming back to this idea of support in a minute, but it's really important that you're there for your team members. And finally, remember to check in with your team. It can be really easy to make assumptions about what challenges you think they are or are not ready for, but they know themselves best. So make sure you just check in, ask them how they're feeling and what skills they want to work on so that you can incorporate that as you continue to iterate and improve this process. So how can you bring a framework like this into your team? If we think about the three phases, I'm going to use those again while we talk about this. So in the first phase, prepare. Identify the skills that you, your team, and your company value in a senior engineer. Some ideas to get you started might include technical ability. Maybe it's learning React or Kotlin or whatever the new hot new framework might be. Or maybe it's getting better at database design or knowing when to do unit testing or integration testing. Or maybe it's just, hey, we're doing really well, but like our object-oriented skills aren't so great, so let's like have some fun and learn algorithms. Technical communication, both written and verbal. Time management. I don't think this one gets talked about enough, and I don't think people think of it as a skill that can be practiced and learned. But I hope that any of my senior engineers have really good time management skills since they're going to be juggling a lot of responsibilities. Maybe you want your senior engineers to be able to look at the big picture and be able to make decisions based on the product and not just the short-term feature timeline. Mentorship. This is especially important if you have a lot of mids on your team who are going to be stepping into the senior role soon. Consulting and client engagement. I know my list skews very consulting focused. This is just meant to get you started. So once you've identified the skills that you and your company value in your senior engineers, narrow it down and identify what are the gaps on my team specifically. The whole goal of this process is to create something that's tailored to your current team as it stands today. So some questions to ask to narrow this down might be, how are you as a lead a silo on the team? What skills do you wish your team got to practice? And what skills are needed for individuals to level up? And while you're going through these thought exercises, make sure you're considering the scope of your project. You want to make sure that your project is big enough to accommodate all of this new shared responsibility. You want to avoid the too many cooks in the kitchen problem. So on my project, it's 18 months long, there's lots of distinct application areas. By spreading this responsibility around, it actually decreased overhead and lightened everybody's load so that they could focus on their personal career goals. So now you have the skills you value, the ones you specifically want to encourage on your team. Make a clearly defined purpose that you want to achieve with that. You want your purpose to be narrow enough that it sets crystal clear expectations, but broad enough that there's a variety of ways that you can achieve it and that it gives your team a variety of opportunities to practice these skills. So as a reminder, my team's purpose for this new process was for everybody to gain consulting, client engagement, and leadership experience. You'll notice that I didn't list every skill that I value in a senior engineer. And I specifically stayed away from the hard technical skills because that just wasn't important for my team. But you'll also notice that my purpose isn't for people to get better at leading meetings because that's just too narrow and that doesn't give everyone enough space they need to grow. So how do you achieve this purpose? It's time to identify the responsibilities that would help you do that. Again, some questions that I asked that helped me identify them were what responsibilities satisfy one or more of the skill areas you chose? What types of tasks serve the purpose you identified? What responsibilities do you have as a lead that everyone on your team can share? And what responsibilities do you as an individual find challenging to keep up with? So these were the responsibilities that we outlined on my team. And I find it super helpful to identify three to seven responsibilities. Anything less than that and it becomes really easy to ignore and anything more than that is just unmanageable and you can't track it. I've also found it helps to write it down or visualize it in some way because if you can find responsibilities that satisfy more than one of your skill areas, that's a really good indicator that it's a good candidate for you to focus on. And by making them as clear as you can, it also makes it easier to track and talk about in one-on-ones or other types of reviews that you may do on your team. We've actually had one team member get a promotion in the last few months since we've done this and it was super helpful for him to have the vocabulary of all of the things that he's been working on and all of the experience he's gained during his yearly review. And I know I've said it a million times, but really, really you have to prepare yourself to delegate. It is so challenging but it is vital to making this process work. So in the proposed step, schedule some time with your team to introduce this plan. I know that having a framework like prepare, propose, and practice can feel really formal but the only goal is to tailor it to your team. So make it as formal or as informal as you want. When I introduced it to my team, I used a Wizard of Oz themed deck where every responsibility and every feature was a step on the yellow brick road until we hit Oz, which was the projects over, we've all grown, and we're done. And make sure that you're using this opportunity to solicit feedback. You should be asking your team or trying to understand if there's skills that they would like to practice that you may be missed. Do they feel comfortable but challenged by the responsibilities that you've outlined? Is there anything they want to add or clarify? And do they feel that this implementation will be sustainable? This last piece is really important. You don't want the responsibilities to be so overwhelming that your team is going to get burned out but you also don't want it to feel so easy that they can be ignored and put on the back burner. So now it's time to put your plan into practice. Again, follow through and delegate. Don't jump into that cockpit. Take the time to explain what you need your team to do and to support them while they do it. So there's lots of different ways that you can offer support. Some can be really formal. Some can have regularly scheduled one-on-ones with all the individuals on your team. That way they have a time and a place to talk about their specific challenges and their specific questions. But it might be as simple as reading an email before they send it just to make sure that their ask is clear or that their request is actionable. One of the challenges we've had on our team is getting responses from the client. So it can be really helpful to have another set of eyes on that email. Or maybe like me, you need to spend some time prepping with them before they lead a meeting. And for those who haven't had the responsibility of writing stories for their team, pairing can be really helpful. We all know it's hard to know how big to write the story or how small to write it or what details to include. And so having somebody there with you can make it a lot easier. And related to that, if somebody doesn't have a lot of experience doing data model or other architecture exercises, it can be helpful to pair with them on those as well. You can be there to ask questions that help guide their thinking so that ultimately it is them that's doing it. But you're just kind of there as training wheels until they get used to those types of decisions. And related to the story writing, data modeling, and architecture decisions, I found that it can be really helpful early on to send calendar invites just to set expectations for how long activities like that should take. You want to make sure that you don't have people on your team who are spending three days on something that should have just taken an afternoon or that they spent more than a cursory 15 minutes on something that they should have given their full day to. And just be kind and give them reminders about deadlines. They're taking on a lot of new responsibility and things can get lost in the shuffle. So it's as simple as saying, hey, I know you promised that documentation to the client by Friday. It's Wednesday. I'm just checking in to see how it's going. But above all, you want to make sure that the support that you're giving to your team is individualized. Every member of your team is going to have different strengths and challenges, and you want to make sure that you're giving them the support that works for them. Our industry is missing out on so much talent because we're not doing enough to support those early in our career. We all need to do our part to empower early career devs to grow them into the amazing seniors and team leads that we all know they can be. Thank you. Thank you.
progression. How did you get to where you are in a senior or lead role. And unfortunately, I retain them and grow them into the senior devs should also want our developers to own their to gain this experience before they step into a going to talk about what we've done, what we've created a shared understanding and that they were for each feature where they put any and all from the client. Chris, one of my team members, learning from using a process like this? Well, they need to practice these skills. We're also want to work on so that you can incorporate that individualized. Every member of your team is