Refactoring

Share this post
Mixing Seniority in Engineering Teams 👩‍👦
refactoring.fm

Mixing Seniority in Engineering Teams 👩‍👦

And why you should hire mostly Junior developers.

Luca Rossi
May 14, 2021
15
7
Share this post
Mixing Seniority in Engineering Teams 👩‍👦
refactoring.fm

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

🔨 Skills

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.

🏃 Processes

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.

🤝 Hiring

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.

📈 Growth

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.

📚 Resources

  • 📑 Reasons to Hire Inexperienced Engineers — by Benji Weber. Benji does a great job at listing all the reasons why it is great to hire Junior devs. It includes many I didn't mention, like their bias for action and the growth opportunity for others mentoring them.

  • 📑 Why Do Companies Hire Junior Devs, as Opposed to Senior Devs? — on Quora. This question got a lot of responses, mostly from personal experiences. Useful to get multiple points of view (good and bad!).

  • 📑 The Resilience of Mixed Seniority Teams – by Tito Sarrionandia. This is a great take that focuses on processes and communication, two of the areas that benefit the most from mixing seniority.

That's it for this week! What is your team composition? Do you feel you have the right mix of seniority? What's your experience with Junior devs? Let me know in the comments 👇 or via email!


Hey, I am Luca 👋 thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Friday and put your own growth on autopilot!

7
Share this post
Mixing Seniority in Engineering Teams 👩‍👦
refactoring.fm
7 Comments

Create your profile

0 subscriptions will be displayed on your profile (edit)

Skip for now

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.

Vaibhav Sharma
May 14, 2021Liked by Luca Rossi

Thank you so much for penning this blog post. I like the way you have made the case of hiring Junior Developers vs Senior Developers across four dimensions. I think there is one more aspect that we should consider and that is Mentoring/Training. What I have experienced is that if you are having too many Junior Developers then a lot of time of Seniors goes into mentoring as well as training the Juniors. This comes at the cost of their commitment to ongoing projects and customer commitments.

The other thing is the amount of time it takes for a Junior Developer to be productive. A lot depends on the channel from where we are hiring the developer from. In my experience, it takes anywhere between 3 to 6 months for a Junior Developer to be truly contributing. Again this comes at the cost of the productivity of the Senior Developer.

One more thing and this is regarding turnover. I have seen Junior Developers sticking with the company for as little as a year. Once they have the necessary knowledge, and some real-life experience, they look for their next pay hike. In this case, if the current company doesn't match the offer in hand the junior developer decides to move on. For Senior Developers, this situation is like back to square one.

Just my thoughts. And I know this is one of those problems where there is no black and white answer.

Expand full comment
ReplyCollapse
1 reply by Luca Rossi
Gilles
May 18, 2021Liked by Luca Rossi

Excellent article Luca. All your points are well aligned with what I experience(d). I can't agree more about the importance of having a mixed combination of senior and junior developers (with a higher number for the latter). I guess it is (as always) a question of finding the right balance to benefit from the advantages without having too much of the drawbacks. What would you say is a "correct ratio"? I also have the feeling that it depends on the maturity and size of the company. What do you think?

Expand full comment
ReplyCollapse
2 replies by Luca Rossi and others
5 more comments…
TopNewCommunity

No posts

Ready for more?

© 2022 Luca Rossi
Privacy ∙ Terms ∙ Collection notice
Publish on Substack Get the app
Substack is the home for great writing