Mixing Seniority in Engineering Teams 👩👦
And why you should hire mostly Junior developers.
In my company we have opened two Junior developer positions, even though we would have plenty of budget to hire Senior ones.
This is somewhat counterintuitive. If I can afford them, why shouldn't I just hire the best engineers I can?
I believe mixing seniority is key to make people grow and create healthy team dynamics. In the long run it leads to a better outcome than an all-senior team, while also being cheaper.
And I would go as far as to say that, in normal conditions, your Junior new hires should always outnumber the Senior ones.
Why is that? Let's have a look at Senior and Junior devs, what they bring to the table and how they differ on a few key aspects:
- 🔨 Skills
- 🏃 Processes
- 🤝 Hiring
- 📈 Growth
Expertise vs Flexibility
Senior members bring profound expertise in one or more domains, which makes them faster and more reliable than our inexperienced pals.
This expertise may come at the expense of some flexibility. After some time, we all tend to stick with what we know best.
Junior developers often bring new tech and methods to the table. They challenge the way things are done. This creates a healthy discussion that makes the whole team grow.
I know this is controversial, as you may say that being an expert makes you more flexible (and not viceversa), and a faster learner too. In my experience, however, the more you are expert in something the more you risk being biased towards defending your way of doing things, because of all the sunken cost you have accumulated over the years.
Having an outsider showing us a fresh perspective helps us to overcome this bias and can be a great catalyst for innovation.
Implicit vs Explicit
A team of Senior devs may rely on their own skills to fill the gaps that exist in areas such as:
- Tech Documentation
- Safety / Security Procedures
- Dev Practices
These areas may become neglected down the line as people take them for granted. Everyone knows how things work so there is less pressure to document processes, which in turn makes them degrade over time.
Onboarding Junior members, instead, requires documenting and explaining everything in a way that is simple and safe.
Existing team members are able to see things from new hires' perspective and feel the drive to work on areas that need improvement.
Cheaper and Faster
Junior devs are cheaper and faster to hire, because there are simply more of them.
They also come from predictable channels you can control, like new graduates from universities and bootcamps. You can plug into these channels and get a steady deal flow of candidates.
Moreover, these hires can grow into the roles that you actually need to fill. Most companies, especially those in the business for some years, have some weird corners that are hard to hire for. Training people about them is often more effective than looking for someone that exactly matches those requirements.
The Cycle of Growth
It's been proved over and over that the #1 aspect engineers care the most about their work is personal growth. This comes before money, perks, and any other topic.
Creating growth avenues that are aligned with engineers' aspirations increases engagement and decreases turnover.
Naturally, this is more challenging for Senior devs as—let's be honest—not all companies are Facebook or Google, where growth can be almost indefinite. In most companies there is a ceiling to what you can learn.
For this reason, Senior devs have a higher turnover than Junior ones — they simply have a shorter growth path ahead.
In a healthy organization, Junior devs rise the ranks and compensate for Senior departures, in a cycle that keeps the team renovating itself at the right pace.
Junior devs turned Senior also have a higher chance of success than Senior people hired from outside, because the former already got the trust of their peers and proved to be a good fit over time.
📌 Closing Notes
Reading this article, you might be reflecting on how your company fares against this.
I propose a simple thought experiment: what would happen if you could hire only Junior devs from now on?
Think about it for a couple of minutes.
Imagine how your team would evolve in a few years if you do this. Are you confident that junior members get mentored, grow and eventually get their senior spot in the circle of life, lion king style? Would this be sustainable with respect to the turnover you expect from your Senior engineers?
Of course this is an extreme picture — sometimes you need someone who is really good at something and you need them right now.
But as a rule of thumb, your Junior new hires should significantly outnumber the Senior ones.