Empowering Early-Career Developers

by Mercedes Bernard

In the talk "Empowering Early-Career Developers" at RubyConf 2018, Mercedes Bernard emphasizes the importance of investing in less experienced developers to foster their growth into future senior developers. She leads a team where each member takes ownership of core features, allowing them to gain essential skills in client management and team leadership that are often reserved for senior roles.

Key points discussed include:
- Industry Challenges: Companies often prioritize hiring senior developers over mentoring juniors, which limits opportunities for growth and can lead to a lack of retention among talent.
- Reframing Terminology: Bernard advocates for using "early-career developers" rather than "junior developers" to avoid negative connotations that can lead to impostor syndrome.
- Qualities of Senior Developers: Essential traits include strong technical skills, effective communication, decision-making experience, and team leadership capabilities.
- Empowerment Definition: Empowering developers involves building their confidence and supporting their abilities, enabling them to take ownership of their growth.
- Implementation Process: Bernard outlines a three-phase framework: prepare, propose, and practice, which allows developers to gain new skills through defined roles and responsibilities.
- Delegation and Mentoring: She shares her own challenges with delegation and emphasizes the need for senior developers to mentor early-career developers. Regular feedback and supportive check-ins are essential for fostering an environment conducive to growth.

Overall, the central message urges the tech industry to invest in their early-career talent by providing them with ownership opportunities, mentoring, and a supportive environment, ultimately cultivating the next generation of senior engineers and team leaders.

00:00:15.770 Hello, great. My mic’s on! So, I’m here today to talk to you about empowering early-career developers. We’re going to discuss 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 developers. Like Megan said, my name is Mercedes Bernard, and I’m a senior software engineer with Tandem, formerly known as Dev Mine. You all get to be the first ones to hear that we’re changing our name and rebranding. So, let’s get started.

00:00:51.260 There has to be a better way. On my current team, I lead a group 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 with varying experience levels while sharing the responsibility for their professional growth. Like Megan mentioned, I’ve also started a community in Chicago called Dev Together, which 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.

00:03:10.560 This brings me to a significant issue in our current technology market: companies are scared to invest in junior talent. If you look at any job boards right now, everyone is trying to hire teams of rockstar senior developers. I don't mean to call out anyone here at the conference or any of our sponsors, but I took a look at those job boards and saw many listings for senior, principal, and lead positions. In my opinion, this is a losing strategy. Hiring a team of all seniors is incredibly costly, factoring in recruiting costs, their salaries, and the cost of attrition that comes from a lack of career growth opportunities. When everyone is a senior, how can anyone grow and improve? Furthermore, not every task on a project requires senior experience; companies are overpaying for work that early-career developers could be challenged by and learn from. I believe it costs less to mentor early-career developers than to hire a team of all seniors.

00:04:37.919 Some might argue that the senior developers you do have don't have time for mentorship, but that's not a valid excuse. Your mid-level and senior engineers need to practice 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, which makes some companies hesitant to invest in early-career talent. They fear that after spending time, money, and energy, their early-career developers will leave to get a mid or senior title. But where do senior developers come from? I recently heard someone jokingly refer to a senior developer stork, but we all know it doesn’t exist.

00:06:01.979 People who feel valued, are challenged, and have the support of their leads and management are more likely to stay and grow with your company than those who are only given busywork or basic tasks, leading them to seek variety elsewhere. I’ve been reflecting on how to enhance the mentorship and coaching that our industry desperately needs, focusing on empowering early-career talent. We want to retain and develop them into the senior developers that we all seek.

00:06:29.040 Now, I want to revisit the title of this talk for a second: empowering early-career developers. Let’s unpack what I mean by that. This is a definition of empowerment that I particularly like: to make someone stronger and more confident through encouragement and support of their ability. I want to emphasize two key points from this definition: first, being more confident. We aim to develop strong developers and solid skills, but we also want our developers to take ownership of their growth and become confident, independent developers. The last phrase in this definition is crucial—support of their ability. Everyone has innate strengths, and by encouraging the talents that your team members already possess, you can cultivate the skills necessary to make excellent team leads.

00:07:12.840 I’ve been careful to refer to early-career developers instead of using the term ‘junior'. Let me clarify what I mean by early-career: it refers to individuals beginning their development career. Why is this reframing from 'junior' to 'early career' so vital? Frankly, 'junior' has a negative connotation, one that I don’t believe is deserved or warranted. There are many in our industry who view 'junior' as probationary or inferior, rather than as someone who is learning. This negative perception often exacerbates impostor syndrome, making that individual feel lesser than when that label is used.

00:08:02.970 Just because someone has their first development job doesn’t mean they’re necessarily 'junior.' Career switchers bring a lot of transferable skills, and it’s often the communication and soft skills that are the hardest to learn on the job. Early-career developers offer fresh perspectives and don’t come with bad habits to unlearn. In my experience, they bring enthusiasm without the arrogance that sometimes accompanies seasoned technologists. Therefore, when discussing this group, shouldn't we strive to use positive language?

00:09:06.730 Now, let’s switch gears and talk about senior developers. What defines a senior developer? Everyone in this room probably has their ideas about the key characteristics. For me, I’ve categorized the traits of a senior developer mainly into skills and experience. A senior developer possesses strong technical skills, communication abilities, time management, facilitation of meetings, consulting expertise, and client engagement.

00:09:31.490 Moreover, they have substantial experience in decision-making, accountability for those decisions, an understanding of the big picture, and the ability to lead a team. Now you might observe that my list leans more toward consulting experiences, which reflects my background. If you focus on product development or other forms of development, your list might differ, and that’s entirely acceptable. How do we cultivate growth in someone who is early in their career into a senior developer who embodies these traits? We need to provide our early-career developers opportunities to practice these skills and gain this experience before they step into a lead role.

00:10:06.840 We want to avoid giving them their first chance in front of a team if it feels like a trial by fire. On my project, we’ve implemented processes to facilitate these opportunities. I’ll share what we’ve learned and specific strategies that you can apply to your teams to empower your early-career developers.

00:10:40.650 Looking back on what my team has accomplished over the past few months, it follows a framework consisting of three phases. In the first phase—prepare—my manager and I had numerous conversations about ways we could coach and mentor our team to help with their professional growth. We sought ways in which they could practice skills they were missing and aimed for the whole team to have more ownership over our project. I began by reflecting on how I, as a lead, was maintaining responsibilities and not allowing my team the insights or experiences needed to level up.

00:11:24.960 For our team, it became evident that I was responsible for almost all client communication, which left my team with scarce opportunities to practice those essential skills and grow. I was also leading most of our meetings and making several decisions. My team was eager to share that responsibility with me. After that reflection, I wanted all members of our team to gain consulting, client engagement, and leadership experience. Ultimately, we decided that every team member should take ownership of a feature in our application. The last step in the prepare phase was preparing myself to delegate.

00:12:16.610 This proved to be the most significant challenge for me personally, and I suspect many in leadership roles feel the same. However, it is crucial to share that responsibility and accountability with your team. To reframe my thoughts on delegation, I liken it to the ground crew at an airport. When a pilot needs to connect the airplane to the jetway, it’s vital that they align correctly with a white guide line painted on the tarmac. The FAA requires three crew members to direct the pilot because the cockpit is positioned behind the plane and the pilot cannot see everything necessary to achieve that.

00:13:00.960 The role of a lead in this scenario should be to pay attention to what your team might not see or be aware of, ultimately guiding them towards success without taking over the cockpit. In the first phase, it was primarily my manager and I discussing and planning, but I knew it was essential to introduce our plan to the team, ensure shared understanding, and solicit their feedback.

00:14:02.500 We focused on our purpose, which was client communication, engagement, consulting, and leadership. I presented our team with these responsibilities, explaining that the feature owner would be the point of contact for everything related to their feature. They would own all client communication and accountability to deliverables while also documenting conversation notes and learnings. They were responsible for writing user stories and tracking system architecture requirements. Although documentation may not be the flashiest part of consulting, written communication skills are often undervalued and challenging to master.

00:15:09.350 An extension of documentation is knowledge sharing, preventing a situation where one person hoards all the information. The feature owner is tasked with disseminating everything they learn to the rest of the team. They practice their decision-making skills, being accountable to both their decisions and for advocating those when presenting them to the team. Additionally, the feature owner leads all meetings related to their feature to bolster expertise in that area while also learning when a meeting is necessary versus when an email suffices.

00:15:59.920 When we were discussing the new process, it was essential to clarify that the feature owner wouldn’t be the sole decision-maker; they still had the support of me, my manager, and the other seniors. They are responsible for making decisions collaboratively with the design lead and product owner. In the same way that a team lead doesn’t write all the code for their project, the feature owner wouldn't be writing all the code for their feature. They would still rely on their entire team to ensure that all tickets were picked up and completed in each sprint.

00:16:53.500 Now it was time to practice our new process. We implemented an ongoing rotation of epic ownership, where several sprints before we began working on a feature, we assigned it to a team member. It was their duty to initiate communication with the client to gather technical requirements and understand workflows, as well as to raise any potential issues before we began the work. For example, one of my team members, Shania, had closely related features in two consecutive sprints, cascading from one to the next.

00:17:52.410 The feature owner was responsible for all documentation regarding their feature. My team created a dedicated Google Drive folder for each feature where they compiled any relevant information, like legacy code requirements, results from data modeling exercises, or a list of questions and answers from the client. For instance, Chris, one of my team members, maintains a Google document where he records the questions he’s raised with our client and the responses he receives. This utterly enhances our team's transparency, especially since clients don’t always respond to emails and sometimes prefer other communication methods.

00:18:54.350 We also documented all decisions made on our projects. For example, Sasha took a picture of a whiteboard with architecture discussion outcomes and emailed everyone to inform them of the decisions made during our conversation. Furthermore, when meetings were required to review classes and usage, Sasha shared invitations with the team to hold everyone accountable to their code responsibilities. Throughout implementations, the feature owner continues the dialogue with the client about any questions or concerns that arise.

00:19:51.160 So what have we learned from this process? I’ve discovered that delegating is considerably challenging. It's often difficult to provide clear explanations of what you expect while resisting the urge to just do it yourself, believing it would be faster. However, as a lead, it’s essential to step back and allow your team the space needed to hone their skills. Feedback is another crucial element; providing your team with positive reinforcement for their development efforts can counteract impostor syndrome.

00:20:27.150 It’s important to normalize both giving and receiving feedback so that constructive criticism doesn’t seem intimidating. For example, you might suggest strategies for handling a situation when a client goes off-topic during discussions. You also want to equip your team members with the tools they need to thrive and solicit constructive feedback on your performance, too. For instance, I received earlier feedback that I needed to spend more time with my team before they led meetings. That insight raised my awareness and helped me make proactive scheduling efforts.

00:21:43.240 It’s crucial to learn when to offer support. Simple acts like asking, "How much support do you need with this?" encourages everyone on the team to help each other. Regular check-ins are also essential. It’s easy to make assumptions about what challenges team members face, which might not reflect their actual feelings. Make a point to check in and ask about their feelings and what skills they’re interested in working on, allowing you to enhance the ongoing process.

00:22:39.730 So, how can you implement a framework like this within your team? Let’s revisit the three phases: prepare, propose, and practice. In the preparation phase, identify the skills that you, your team, and your company value in a senior engineer. Initial ideas could include technical abilities (such as proficiency in React or Kotlin), improving database design skills, enhancing object-oriented skills, communication (both written and verbal), time management, or mentorship.

00:23:52.600 Determine the gaps present in your team specifically—designing this process to match your current team structure is key. Ask questions that clarify your own weaknesses as a lead and which skills you believe your team needs to practice. It's equally vital to consider if your project's scope supports shared accountability without causing confusion. For example, if your project spans a significant duration with multiple application areas, distributing responsibilities can reduce overhead and lighten individual workloads.

00:25:06.350 Now that you’ve pinpointed the essential skills and identified opportunities, it's time to create clearly defined roles that align with the purpose you want to achieve. A purpose should be narrow enough to set clear expectations but inclusive enough to allow a variety of opportunities for growth that your team can experience. In our case, our purpose was for everyone to gain experience with client engagement, consulting, and leadership.

00:26:20.890 I consciously avoided listing every skill I valued in senior engineers, particularly as my purpose wasn’t simply to improve meeting leading skills—a goal too narrow and exclusive for many to grow. Now, regarding how you achieve this purpose, identify responsibilities that would help you meet these objectives. I recommend keeping the list manageable, ideally three to seven responsibilities, as fewer can be ignored, and more than that becomes too overwhelming to monitor effectively.

00:27:42.160 Making those responsibilities visible or recorded allows for better tracking and promotes discussions in one-on-ones and performance reviews. For instance, one of my team members was recently promoted after leveraging this process, and being able to articulate all the skills and experiences he's acquired during performance evaluations truly helped him showcase his capabilities.

00:29:00.980 Above all, prepare yourself to delegate. While it’s difficult, it’s essential for the lives of this process. Schedule one-on-one meetings with your team to thoroughly introduce this plan. Using a structure like prepare, propose, and practice does not need to feel overly formal—tailor the approach to your team. When I rolled out our new framework, I utilized a Wizard of Oz-themed presentation that likened responsibilities and each feature to stepping along a yellow brick road until we reached our ultimate destination: project completion.

00:30:18.620 Utilize this opportunity to gather feedback from your team, seeking their input on any skills they wish to develop that you may have missed, and gauge their comfort level with the outlined responsibilities. Ensure that the process doesn’t feel either overwhelming or so minor that it can be disregarded, which can lead to burnout without yielding growth opportunities.

00:31:53.470 Lastly, implement your plan and genuinely delegate. Allow your team to execute their responsibilities and be there to support them through that journey. Support may involve regular check-ins to address specific challenges, reviewing written communications to ensure clarity, or prepping them for pivotal meetings and discussions. Each member of your team possesses varying strengths and challenges, making individualized support critical.

00:32:09.780 Our industry is missing out on immense talent because we aren’t doing enough to support individuals early in their careers. It is vital for us to take proactive measures so that we can empower these early-career developers, nurturing them into the remarkable senior engineers and team leads that we know they are capable of becoming. Thank you.