Read This Before Hiring Another Senior Software Engineer
This is Part 4 in a five part series on building diverse software engineering teams. Read Part 3, Recruiting More Underrepresented Candidates Won’t Magically Make Your Organisation Inclusive, here.
I’ve met with dozens of engineering managers who lead teams made up of exclusively senior software engineers, and who are looking to hire only senior engineers. You might lead a team like this, or have been on one in the past.
I noticed that these leaders disproportionately struggle with recruiting and retaining diverse talent. There are some other trends too — like needing more coaching on communication-based conflicts, generally speaking — but let’s focus on hiring for now.
Conversely, leaders who make space on their teams for mid-level and junior talent consistently report more momentum when hiring, and better diversity metrics. This is not just true for tech, but across most industries. Of the dozen engineering leaders I interviewed for this blog post series, just two reported that they felt satisfied with the gender and racial diversity on their team. These were the only two leaders who had invested in hiring folks a bit earlier in their careers and creating opportunities for them to level up.
Why is it so hard?
Let’s be clear that seniority and a diverse team are not mutually exclusive, and there are many very senior technologists that come from underrepresented communities in tech. But, it is harder to find them, as the overall number of senior engineers is smaller than the overall population of software engineers on the hiring market. If you do find them, they might not want to work for you.
Beyond addressable market, there are some “smells” when it comes to hiring senior engineers that have a negative impact on diversity and inclusion, and may work against you landing that amazing senior engineer from an underrepresented background. Senior is often times not defined, especially at earlier-stage companies, and it can often be used as a stand in to mean “hire more people who have the same background and experiences as the current engineers.” This opens the door for the hiring panel to define senior for themselves, and give preference to candidates who have similar backgrounds and experiences.
The best, most sustainable path to a diverse team with senior talent is by hiring that talent earlier in their career and giving them an opportunity to grow with your company. This helps people from all backgrounds, not just underrepresented ones, while also leading to lower attrition overall.
Benefits of a mixed-level team
Do you really need a senior engineer with 10+ years of Javascript experience to fix every UI bug?
A team consisting of a mix of great senior engineers and very solid mid-level engineers has some unique benefits. As mentioned above, these types of teams are generally indexing higher on diversity, which has quantifiable business advantages. Additionally, teams with more than one level have a build-in leadership pipeline, where early career employees are levelling up to become senior, but they’re taking all of the context of your company with them. They also execute more efficiently by allowing senior engineers to focus on the biggest problems that benefit most from their years of experience. Having mixed levelling is also a forcing factor to define what “senior” really means at your company, and lay out a path for people to get there.
Listen, we all want to believe we show up to work to solve the hardest problems. That’s unfortunately probably not the case for most of us, so teams often do overestimate the complexity of the problems they need to solve. A team full of senior engineers is great and appropriate in some situations where the tech is complex and the business problems are still being defined. But for an established software product with a finite amount of technical decisions to be made, bugs and maintenance might make up more work than greenfield projects. Each type of project requires different skills, and some of those projects are very well-suited for a confident and eager early career engineer.
Teams need to reflect the complexity of the problems they need to solve. In the same way a restaurant can’t function without a chef de cuisine, line cooks, and someone to pour the wine, the type of work an average engineering team needs to get done in a normal sprint doesn’t always require a team full of senior engineers.
Where did this obsession with senior-only talent come from anyway?
There are a lot of myths about building a high performing team, some that are so ingrained in the way engineering teams are built that we may not even recognize that we believe them, too.
First, every employee, even a seasoned senior engineer, needs and deserves good management. Teams often look to hire exclusively senior engineers in order to reduce management overhead. You may get away with less project management, or needing to spend time breaking down tickets. But even senior employees need feedback, coaching, and opportunities for growth. To think otherwise is a disservice to your team.
The same goes for onboarding. Onboarding takes time, and time is something that a lot of teams don’t have a lot of. That’s why they need to hire some more people in the first place. But don’t believe the myth that only a senior engineer can just hit the ground running on day 1, or that they can onboard themselves. It takes time to understand architecture and the dozens of business decisions and tradeoffs that are embedded in your code base. Everyone needs time to get up to speed. Leaving someone to self-onboard will most likely end up in that person feeling lost and unsupported until some pieces start coming into focus.
Teaching and mentoring are tools for growth for both the teacher and the learner. It takes a higher level of mastery to teach someone a skill, or just explain it clearly, than to practice it. In teams that I’ve lead, I see fewer bugs and incidents coming from code that’s been developed via pair programming, and especially if that pair has mixed levelling.
And while senior engineers undoubtedly have the experience to avoid mistakes and ship code faster, having mixed levels on your teams can actually help your seniors get more done, not less. You can protect the time of your senior folks by putting their brains to work on the problems that need it the most, while leaving more focused problems up to the rest of the team. Senior folks feel like their time is valued, they’ll spend less time context switching, and the mid-level engineers who are hungry to learn will have an abundance of stuff to work on.
Up next in this series:
Using the wrong reachout methods and messaging for the communities they want to see represented. How can you authentically let a candidate know that DEI is important to your team and company without it coming across as the only reason you’re approaching them?
🎉 I’ve just launched a course called High-Performing Software Teams. If you want to know how to define, measure, and reinforce high expectations, this course is for you.
