Mixing Seniority in Engineering Teams 👩👦
And why you should hire mostly Junior developers.
Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
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:
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.