The geometry of software teams

To get your team in shape, you need to think about what the right shape should be.

There’s a myth that software engineering is a solo effort. Popular culture pushes the image of the lone hacker, hammering at their keyboard in darkness, barely interacting with others. That’s rarely the reality. The creation of software is a team sport: strong results coming from many people collaborating and communicating well.

As a manager or technical leader, it can be useful to have some heuristics to reason with the shape of the team to make sure you have the highest chance of success. Here are some of the things I keep in mind to balance my teams.

The atomic unit of engineering: the team

Before getting into describing the parameters of a software team, let me spend a moment explaining how I think about that phrase. I’m using the word ‘team’, but your organization might say ‘pods’, ‘squads’, or ‘groups’. A software team is a group of people working to build and maintain software that accomplishes a shared goal.

An important distinction to remember when considering your software teams is that they do not necessarily have to be tightly correlated to the managerial structure. For example, one manager may oversee engineers on multiple teams, or members of the same team could report to different managers.

Similarly, a person can be on multiple teams at a time. For example, a staff engineer or architect may have oversight responsibilities for a variety of teams’ work. In these cases, ensure there is agreement and alignment on their level of participation in team meetings and ceremonies. If this isn’t clearly established, it can result in a slow-down of progress when the necessary people aren’t ‘in the room’ to make decisions.

The balance of experience

Balancing the experience of your team members can be crucial to creating a high-performing, engaged, and empowered group. You need experienced engineers to ensure correct technical decisions are being made, but if you only have senior folks, there’s a risk they’ll spend more time arguing with each other than building!

It’s also tough to staff a team purely with experienced engineers since they can be harder to hire and retain. It’s far better to balance their expertise with people who are excited to learn from them and grow, and who can execute against the approach that the architects are defining. Over time, they can then step up to the leadership roles on the team.

Try to shape your team so that there is a tree of knowledge sharing and mentorship. For each engineer at a more senior level, try to have one or two engineers at the next level down. Finally, it’s important to taper that in at the entry-level, as the hands-on coaching that a recent college graduate, intern, or apprentice requires to be productive will be considerably higher.

By way of illustration, if I was staffing an eight-person team, I would probably try to structure it like this:

• A staff engineer or architect dedicating 25% of their time to the project;
• One senior engineer;
• Two mid-level engineers;
• Three-to-four software engineers;
• One-to-two new graduate engineers.

This model gives everyone the ability to get the mentorship and guidance they need to be successful, and it provides a career path for engineers to follow as the team evolves and new opportunities arise.

A warning sign: the team of one

One of the easiest traps to fall into is implicitly creating ‘teams of one’ within your team. This is where a single person has taken sole responsibility for a piece of the system and handles all its new development or maintenance without spreading the load.

This is often initially-appealing to the engineer. The ownership can be a source of pride, and it certainly feels more productive to just do all the work yourself – you spend less time discussing or teaching and more time building – but sadly, this is a false economy! The three major risks of solo work are:

1. All the knowledge of the system dissipates quickly should the owner get hit by a metaphorical bus. The rest of the team might be forced to suddenly take over a codebase they don’t have much understanding of.
2. The owner can get stuck in a rut over time. If the backlog of work on their system piles up, the owner will struggle to find new challenges to keep them growing and engaged. (And a disengaged engineer is more likely to explore new opportunities and be hit by that bus.)
3. The system design can be limited by the expertise of the owning engineer, meaning that it lacks the diversity of perspectives multiple engineers can bring to the table.

So keep an eye out for an engineer who isn’t sharing their knowledge, and partner them up to get the knowledge circulating.

The different forms of ownership

Finally, there are two high-impact roles that should be defined on any software team.

1. Technical Owner. Commonly referred to as a Tech Lead, this is the team member who is ultimately accountable for the technical quality of the team’s work. They make sure that technical questions are investigated and answered, and that the correct trade-offs are made for the team to hit its goals. They can be the technical point of contact for discussions with other teams.
2. Process Owner. This is the person who is in charge of making sure the team’s processes & rhythms are effective. They own the agendas of team meetings and ceremonies, and they gather feedback on processes to make sure we work to improve efficiency. They treat the process like the product: identifying lessons and potential improvements, and driving iteration of processes with the team.

While I think it is essential to have people explicitly in these roles, I am thoroughly flexible about who they are. One person could take on both roles, or they can be split amongst the team. Either can be the responsibility of an individual contributor or a manager. What is vital is making sure the expectations are clearly communicated to these owners and the team to ensure the decision-making is frictionless and effective.

Conclusion

Pulling these together can hopefully give you a perspective and set of tools to look at your current teams and start to see ways you can tweak structures to increase effectiveness, productivity, and happiness for their members. As you experiment, I hope you uncover new ways to evaluate the shapes of your teams in order to make forming and growing them in the future faster and easier.