Turn the senior around: an alternative way to lead engineering teams

As engineering managers, we carry many responsibilities. Two critical responsibilities I have come across  throughout my career are:

• delivering high-quality features on time.

• supporting your team members' professional growth and development.

Senior engineers are a key enabler to both responsibilities. They are the main players the team lead can rely on to achieve these goals.

Most of the engineering managers I have met have assigned their senior engineers to lead all the critical features, but I would like to “turn the senior engineer around” and suggest the opposite: the more senior you are, the less you lead engineering efforts in the team. The more senior you are the more you promote other engineers by giving constant feedback on the features they lead.

Needless to say, this only reflects my opinion :)

The common team structure—senior-first delivery

The usual team structure I see is senior engineers leading features while trying to improve and grow the non-senior members along the way.

How does this work?

Senior engineers are the ones responsible to deliver features, they are the ones with all the context, and they are the active leaders of those feature squads, as primary communicators with stakeholders.

In my view, the team lead's job is to make sure the senior engineers are on track and help them if needed.

The advantages are obvious—there is maximal certainty that the features will be delivered on time, the non-senior members learn by watching the seniors in action, and by (hopefully) active mentoring.

Disadvantages of senior-first delivery

Team stagnationWorking in this structure preserves the current hierarchy of the team. The seniors are the leaders, the non-seniors are there to be led. This by definition means that the squad members will always only be as good as their senior squad leads—all they see is what the senior engineer shows them. In the best-case scenario, by active mentoring, in the worst-case solely by watching them.

Limited growth rateThis is the key part. In my opinion, all team members have a limited amount of potential growth in this scenario.

• From the senior engineer's perspective: they do more of the same—they became seniors because they know how to design, do decompositions, update stakeholders, code well. But is that their main purpose? This structure misses the point where senior engineers are measured by their impact on the group and making others better. Instead, senior engineers are measured here by their ability to deliver the feature on time. So, the senior engineers improve certain skills which they are already good at but do not maximize their most important muscle—to make others better.

• From the non-senior engineer's perspective: they are expected to grow by watching and not to grow by doing. So yes, they will grow by watching the senior engineer leading the feature and by active mentoring, but they will improve less than doing that themselves and being exposed to all of the different aspects of leading a feature, having all the context, communication with stakeholders, etc.

Turn the senior around

Mid-level engineers are the ones responsible to ensure a feature is delivered, they are the ones with all the context of the feature, and they are the active leaders of those feature squads.

The senior engineer's role is first and foremost to constantly give feedback to the non-senior engineer who leads the feature, thereby help them to learn by providing them a solid foundation for them to grow.

The team lead's job then takes on a different purpose:

• to communicate with the non-seniors as feature leads, help if needed, and make sure everything is on track.

• to communicate with the senior engineers and give them all the help needed to make sure they have all they need to grow the non-senior members. The team lead constantly gives feedback to the senior engineers on how they improve others.

Advantages of turning the senior around

Dynamic team hierarchyThe non-seniors feel that the limit to their performance is only themselves and not the senior who leads them (as we saw in the first scenario). The fact that the non-seniors lead the feature provides them the needed experience and confidence to later become seniors themselves.

Maximal growth rate

• From the senior engineer's perspective: they are focused on making others better. They constantly get feedback from the team lead on their ability to do so while, of course, being an active part of the feature implementation. The senior engineers still use and maintain their strong muscles (design, coding, etc) by mentoring the non-seniors—pairing, feedback, etc.

• From the non-senior engineer's perspective: they grow by trying their best to lead a feature while getting constant feedback from the senior team members. They are exposed to all of the "senior qualities" first-hand and improve on a daily basis.

Long-term team building

• When you zoom out and see what happens to a team that uses this method for a long time, you see strong teams where all the team members maximize their growth in their respective areas of learning.

• You see a stronger team where seniors constantly grow the non-seniors, leading to a robust team.

• You see a team that promotes more people to seniors.

• You see a team where senior engineers can break through the senior limits and get promoted themselves.

• You see a team with satisfied team members :)

The risk

Regardless of all the benefits, there is a short-term risk here—you put all your faith and trust on the non-senior members to lead critical features and rely mostly on the seniors to help them. This requires a huge trust in the team and the ability of the team lead to maximize the empowerment of the team members.

Personally, I really enjoy this step, when you trust your team this way the team feels it. This ability to rely on the team while having a long-term team-building vision is exactly where we grow as engineering managers, but this might be a topic for another blog post :)

To summarize

Turning the senior around means to flip the team structure—let the non-seniors lead features and make sure the senior members grow them by constant feedback.

This allows strong team building, provides the opportunity to maximize everyone's growth, and eventually fulfills the two objectives stated at the beginning: delivering on time and supporting our team's professional growth.