Software engineering team structures

This post outlines a useful structure for product-based software engineering teams. I believe it is a fairly standard structure in a modern software company. I’ve adapted this post from a contribution from a colleague.

The main principles are:

1. to keep communication flowing;
2. accountability is defined and understood;
3. the ability to scale horizontally

People

A team size should be 7 +/- 3, or as Jeff Bezos calls it “The two-pizza size rule”: If you can’t feed the team on two pizzas, the team is too big.

The composition of the team should involve these people.

• Technical Lead
• Senior Engineers
• Engineers
• Junior Engineers (or Graduates/Apprentices)

A trend in the industry is to move towards the general term of “Engineer” rather than distinguishing between Developers and Testers. However, if there’s a lack of Automated Testing, then more Manual Testing is required which then has a stronger requirement to make this distinction between the roles. Having a distinction can lead to the “us and them” culture as code is “thrown over the fence” to be tested. The team can feel more fragmented – this isn’t always the case though.

Technical Leads do not necessarily need to be the most technical on the team, but they need leadership and management skills. They need to know who can solve an issue in their team and be the facilitator.

Juniors (or graduates/apprentices) are an important part of growing your business. When many job adverts ask for the standard “2 years experience”, how do you get it? Recruit juniors into your team and teach/mentor them, shaping them into the engineers you need.

A team needs to be a blend of skills, strengths, personalities. A junior engineer is a part of that blend. It keeps the senior members in the team on their toes, as they need to coach, mentor, and explain concepts to receptive minds. This can ground the team, and make them more productive.

Earlier we defined people, not roles. These are the roles that augment the team:

• Product owner
• Architect
• Scrum master

These roles could be people in the team, but not every organisation will be at the scale to require a Full Time position for each team. If you don’t have a dedicated full time position, the team will need to decide who will pick up the duties of these roles.

Accountability

Responsibility – Who feels guilty when the team doesn’t deliver, or something goes wrong.

Accountability – Who takes the blame when the team doesn’t deliver, or something goes wrong.

When a team is formed, they are all responsible for everything the team needs to do. As a member of the team, you do whatever is needed to “get over the line”. Your process should not create single points of failure, or knowledge silos. Your process should provide mentoring to junior team members, and be supportive of learning.

The Technical Lead is accountable for making sure everything is complete and to the desired standard.

So what is everything? A non-exhaustive list would include:

• Technical/Solution design.
• Backlog management.
• Both product and technical.
• Development and testing.
• Deploy and release management.
• Support and documentation.
• Monitoring and telemetry.
• Reporting to managers
• Sprint reports.
• Roadmaps.
• Quality metrics.
• Quality control.

Line management can be with the Technical Lead, split between Technical Lead and another Senior within the team, or even people outside the team. If it is the latter, then the accountability needs to be clear.

Scaling

Scaling needs to be “horizontal” when a team unit becomes saturated: You do not make teams incrementally larger to scale your output. You add more teams and give accountability to these new teams. This goes back to the 7 +/- 3 idea.

you need to add another team:

• If the average velocity of the team is not delivering the quantity you require.
• If you are asking the Technical Lead if they need more people to deliver, and they are already at the top end of the 7 +/- 3 bracket.

If you are scaling, you are likely to come across engineering teams that need to work across product teams. Examples potentially could be: security; authentication; UI Libraries; or overall platform stability/accountability. Whilst these are individual products in their own right, they are servicing other development teams. They need to be more collaborative, open, and aware of the business needs of other teams. Their decisions will impact more people than decisions made in a single focus team. They will need to be honest and clearly communicate priorities.