One of the most important parts of the job of an engineering leader is assembling a team of developers that can work together in the most efficient way possible.
The selection of your team members might be influenced by capabilities, personality, and seniority. When thinking about seniority, natural questions arise on how many senior members is too many, how effectively a junior engineer would be able to address complex technical challenges, or if hiring graduates would boost creativity.
One might assume that if you have a completely free hand in picking your crew, then you just go for the best and most senior engineers you can get. This is a tempting approach, but it can also turn into a grave mistake, as too many chefs in the kitchen may lead to frequent clashes.
A software engineering team is ever-evolving and those who aren’t senior or principal today, might become one very soon in an appropriate learning environment. On the other hand, someone who is senior today might also soon become obsolete.
To find a good middle ground between the two, here are some specific considerations that you can use.
Team structures are not static
Take a moment to imagine your team as a river that is constantly flowing and adapting, a concept introduced by I.M. Wright. The metaphor compares the continuous inflow of new water needed to keep a river in motion as similar to the required inflow of new members on an engineering team.
Wright suggests that the majority of a team should consist of junior members who have the potential to become senior engineers leading the team. Current senior leaders should therefore only form a smaller part of your team.
This theory also introduces the notion of elders. These are individuals that formerly led a team but are now ready for new challenges outside of that team.
This career life cycle is important to keep the stream of opportunities across your business flowing, so that people can continuously develop and thrive. It is important to note that the entire life cycle of team members moving from being new joiners to elders does not happen overnight and can take several years.
Early phase and business critical products have different needs
Having junior engineers make up the majority of your team is not always a possibility. Consider a product team where business criticality, the underlying technology, or business logic constrain the flow.
For example, if your product is subject to strict service level agreements (SLAs), you might want to take a closer look at how to mix the seniority on your team. For instance, a very short resolution time requirement might link to having a team of more senior engineers that can utilize their experience and act fast. In contrast, junior team members usually need more time to learn and may have more difficulties withstanding the pressure of such requirements.
If legacy technology forms a substantial part of your system, it may be worth asking if it’s possible to have junior engineers make up a majority of your team. If you were to advocate for moving from legacy technology to a modern alternative, it might be in your interest to garner fresh perspectives from new members.
It’s also important to recognize the high entry barrier for new members. Frequently enough, in more complex systems that have been developed for several years, you might need to have historic knowledge of how your system was developed, as well as being familiar with the legacy technology stack. This would make things more time consuming for new joiners to become productive. Additionally, if the system is critical, with tight SLAs like strict uptime requirements, it can be an even more tedious process onboarding new engineers.
Alternatively, fresh eyes and new perspectives might come in handy when the product is in an exploration phase. You need a solid inflow of ideas, alternative approaches, and innovative problem-solving. All this frequently comes with people that are new to the problem area. Junior profiles might even be more suitable to this ilk of exploratory work, as they bring a fresh perspective and don’t carry biases from previous projects.
Experience isn’t always the most important
This is all another way of saying that experience is a double-edged sword. We tend to believe that the more experience we have, the better. This is true, but experience can also turn into a blocker.
If you’re forming a team of only very senior engineers, there is a chance that their vast experiences have strongly anchored their ways of working and problem solving. This could make them highly opinionated, leading to conflict in the team.
On the contrary, when a solitary, highly experienced software engineer constantly advocates for their solutions without facing any opposition in a team of junior engineers, it can create an unhealthy situation. It is recommended to have a small group of leading individuals who serve as a counterbalance to each other, while the rest of the team comprises fresh minds who can contribute to discussions and gain insights from various viewpoints.
Additionally, experienced engineers often bring with them a track record of proven solutions. These solutions have been employed in previous cases, addressing the same or similar problems with successful outcomes. While it is advantageous to have experienced engineers who can swiftly implement these solutions, there is also the risk of overlooking novel approaches to the problem, which may impede innovation. This is where someone less experienced may be able to spot a shortcoming on an ostensibly “proven” solution.
Creating a learning environment for junior engineers
With your more junior engineers, nurturing their development and success should be central to your ethos as a leader. This can be achieved with the right learning environment within the team.
In essence, the quality of the learning environment is shaped by two central factors – the nature of the tasks at hand and the potential for leadership development. In the case of junior and new members, it is important to take into account the knowledge barrier they encounter upon joining the team. You can remedy this by implementing mentorship pairings among team members with different experience levels.
Failure to actively develop their knowledge-base, a lack of real challenge in tasks, or limited guidance can have negative effects, such as decreased morale and possibly attrition.
The verdict
A team needs to be continuously adapting by bringing in fresh perspectives who eventually develop into leaders. Ideally, this means redressing the balance towards more junior members of your team, supplemented by more experienced eyes over things.
Finally, stay vigilant to the need for more experienced personas to counterbalance each other, and remember that the product requirements should guide the appropriate balance of junior to senior members on your team.
