Effectively onboarding new team members and helping them ‘level up’ is one of the most critical parts of leading a team.
It is unlikely that any other activity will have nearly the same amount of leverage as bringing a junior engineer up to speed so that they can successfully contribute. This is often more easily said than done. While team leads should be accountable for ensuring that this happens, many inexperienced leads often feel that this remit falls solely on them.
Leaders with great time management can make this direct mentoring work for a while, but the risks are high, and the results aren’t always as good as they could be. Sooner or later, the lead will lack the adequate time required to dedicate to the new team member. The junior will often find themselves either with too much undirected time or blocked and unable to move forward. Like many problems in computing, this can be solved by distributing the workload across a group of people and ensuring it is appropriately managed.
Personally, I prefer a mix of formal and informal approaches. During the junior engineer’s first few days and weeks, they’re usually best served by having very structured content. Ideally, new engineers should be given everything that they need so that they can bootstrap their systems before they are onboarded. These early days should be somewhat standard for each engineer joining an established team and should mostly be on rails, as they are guided through the expectations of the team, coding styles, and official team culture. This phase can, and should, largely be accompanied by well-maintained documentation, and the lead in question should be available for questions and basic directions. It is after this initial phase that real mentorship begins, and when the mentorship mesh should be established.
The mentorship mesh gives the mentee a team of people that they can rely on; that can help them advance their careers in ways that a single mentor is unlikely to be able to do. Each team can be custom-built to give the junior engineer what they need. In my experience, there are usually a few key roles: the peer, the senior, the domain expert, and the lead. Sometimes, each of these roles is filled by a different person, and other times a single person can fill one or more of these positions.
The first role is the peer. This is who the mentee will spend a lot of their time working with. They’ll be on a similar level in terms of experience, though preferably just a little bit further along in their career. Ideally, they can work on the same, or similar, initiatives, allowing them to share the small successes and setbacks of everyday development as they advance their careers together. While the peer doesn’t provide the same depth of support as some of the other roles, their frequent presence does wonders for the mentee’s morale while they’re acclimating.
Next is the senior. This is the person who the mentee should be able to lean on most for guidance on technical details and system architecture. They should be ready and willing to spend time with the mentee – asking questions and guiding implementation plans, reviewing their pull requests, and pairing up to work through bugs. The senior in the mentorship mesh needs to have excellent communication skills, and they also need to be at a point in their career where they understand that their influence stretches beyond the realms of coding. With this in mind, not every senior engineer is a good match, so the lead must take care when appointing this role.
Then comes the domain expert. This is a role that is often ignored by developers as we tend to focus on the technology itself. For a junior engineer to grow into their role in an organization, however, they need to expand their understanding of the business. Whether it is the CPG space, FinTech, Information Security, or something else entirely, it should be somebody’s responsibility to fill the junior engineer in on the details. This gives the mentee valuable knowledge that will let them have more mobility within the business and specific industries, while also creating a more engaged team member for the company. Appointing a trusted domain expert helps the junior engineer to further understand ‘why’ they’re doing the work, and an engineer that knows the ‘why’ is often much better at coming up with ‘how’. This role could be filled by an internal customer, product manager, or the team lead themselves.
Last but not least is the lead themselves. They’re responsible for setting up and maintaining the mentorship mesh, as well as playing a significant role within it. The lead serves as a longer-term guide for the mentee, focusing on career advancement 6 to 18 months in the future. Leads line up opportunities for junior engineers to work on initiatives that will challenge them while building on their newly acquired skills and knowledge. They should do everything in their power to make sure that these are successful projects, of a suitable size and level for the junior’s capabilities. Leads also have to make sure that the other members of the mesh understand their roles and are performing effectively.
A mesh approach does require the lead to put in more time to fully understand the mentee’s near-term career goals, as well as having a thorough understanding of what their team needs in order to thrive. It is time well spent, however – giving junior engineers a dedicated team that they can rely on and turn to throughout their careers. It builds a resilient support system and creates a more effective, proactive environment. Thanks to mentorship meshes, many of the relationships required for larger initiatives now come ‘pre-wired’.
Fostering this culture of shared mentorship builds organizations that are reliant and resourceful, while giving junior engineers a clear understanding of how to grow within them.
