The resilience of mixed seniority engineering teams

A couple of weeks ago I wrote this line in some lessons learned from building a new digital service for the UK Government:

I’m extremely proud of how we managed to do that with an unremarkable budget and a team with multiple junior members.

It seemed to resonate. A few people reached out to me on Twitter asking me about their own organisation and whether they too could incorporate more junior roles into their engineering teams.

It’s true that you need to do a fair bit of work to responsibly support people earlier in their career — but this isn’t a question of learning what you have to do to build performant teams despite the presence of junior members, it’s about recognising that you can build performant teams precisely because you have a mixed seniority team.

There are two big reasons why:

1. Your internal communications will bloom

Dr. J is a consultant at ThoughtWorks, and a good friend of mine. When we worked together, they were always pointing out how being inclusive to one person often makes things better for whole teams. For example: you might start captioning your all-hands events to better include a deaf team member, and then learn that your team members who don’t speak English as a first language are also loving the captions because it helps with unfamiliar accents.

If you mix up your teams seniority levels, you will see this exact multiplier effect over and over again in your internal communications. As an engineering director, this is literally the closest thing to a productivity magic wand that I could hope for.

Here’s how I’ve seen it work:

The team knows someone junior is about to join. You assign someone more senior to make a bit of a plan for when they join. That person looks at the onboarding file in your git repository and finds it woefully out of date: it is missing important things, the commands dont run, it’s talking about team practices that you don’t do anymore. They panic because they know this next person can’t just use their experience to struggle their way out of the problem like the last 3 joiners did. They fix the document, and now you’re more resilient to hiring new people.

The new engineer joins. They go through the onboarding. The team knows they are more junior, so rather than assuming they figured it out somehow, they ask how it went. Now you’ve got a team actually getting user feedback about your onboarding process.

The new engineer asks what a “sprint planning meeting” is for. It turns out nobody knows what it is for. The team replaces it with a weekly Slack thread and you get an hour per fornight back.

An architectural change is made. The very senior person who drove the change knows that it relates to a feature that the new engineer is working on, so they call an all hands to explain how it works. They can’t put it into words, so the day before the all hands they ask for advice from somebody who is good at explaining it. The team gets a good explanation of the change, and the senior engineer has had an experience that will make them consider prioritising investing in their own communication skills.

In short, a cultural pressure to improve communications was created: by adjusting to the needs of one person, your team ended up doing things that worked better for everybody.

2. Seniority is not a safety strategy

The risk of letting less experienced people near your codebase is not as high as the risk you are already running by allowing all-senior teams to exist in your organisation.

Saying your quality strategy depends on everybody being an accomplished expert with years of experience is like saying your fire safety strategy depends on you always renting your spare room to a firefighter.

What defects in your processes are being hidden by the fact that everybody just knows better? Your all star team are going to slip up at some point, no matter how brilliant they individually are. They might ssh into the wrong box and drop a production db, spend 3 months building something that it turns out is pointless, or not appreciate the nuance of a data privacy law and get you sued. Your processes won’t be there to guard against these mistakes, because you wanted to avoid the early pain of figuring out what processes make it safe for everybody to contribute.

Put another way, if it’s painful do it more often.

Quality is made unstable in exactly the same way. “We’ll just always hire the most experienced people” is not a predictable way to do good work. You might be able to rely on this if you can consistently and substantially outbid your competitors for salaries and you have a reputation as one of the best places in the world to work. But realistically, you don’t have that. If you think you do, you probably haven’t done enough user research on your applicant pool.

If I had to bet on the team that would produce the best product, it wouldn’t be the team that refuses to hire anybody without a decade of experience, it would be the team that:

• Recognises a vast array of different strengths when hiring, and makes plans to reorganise itself to utilise those strengths.
• Invests regularly in training.
• Uses systems thinking to iterate on its own processes, driven by data about outcomes.

Doing it right

All that said, this isn’t free. You’ve got to do it right. If you try to introduce mixed seniority teams but you don’t have a plan, a support structure, a good cultural foundation that rejects blame and values learning, and some realistic expectations you’re going to be burned. If you’re interested in this, drop me a message on Twitter, I might write up what I’m doing on this front over the next few weeks.