Software engineering team structures

Apr 20, 2019 · 8 min read
#people #teams #structure #management

This post aims to outline a useful structure for software engineering teams. This feels like a fairly standard structure, or at least with the teams I’ve had exposure to. The main principles here are: to keep communication flowing; accountability is defined and understood; and the ability to scale horizontally when your teams become saturated (and for this to be easily quantified).

For the purpose of this article, a team is going to be a product based software engineering team. This article does not delve too deeply with the structure above the team, only that the principles are still applicable. They will be fully accountable for delivering and supporting a couple of products. They use the scrum methodology (although this doesn’t really matter).

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.

I’ve provided links in the footer that provide some more context as to why this works.

The composition of the team should involve these people. There are other roles in the team that may or may not be distinct individuals. Or, depending on the org and team size, these roles may in fact be tasks picked up by folks in the team (more on that later).

There is no desire to break this down into “dev” and/or “test” engineers, because at this stage in our industry, it’s starting to become the norm for this distinction to be removed. These boundaries cause a “you/me” or “over the fence” culture that can ruin teams, and the quality of the product. I also believe it can harm an individuals career progression, as they are labelled one or the other.

Earlier we defined people, not roles, here come the roles that augment the team:

Now, these roles could be people in the team, but not every organisation will have enough people to fulfil a Full Time Equivalent (FTE) in each role, and for each team. When this occurs, the team will naturally need to pick up the duties of these roles. Who and how this is allocated in the team, should be a team discussion, and a team decision.

A quick note on Technical Leads. They do not necessarily need to be the most technical on the team, in my opinion, but they need leadership and management skills. They need to know who can solve an issue in their team (or org) if they are not the most technical. This thinking is only going to work if that’s the culture of your org. If your organisation naturally sees the Technical Lead position as a promotion from Senior Engineer, then your mileage may vary.

Accountability

So at this point, we know the people, we know the roles, but what are they responsible and accountable for. What’s the difference?

In new age parlance:

In my opinion, 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 siloes. 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 none exhaustive list would include:

There are some notable absences in there. A couple that I would call out specifically are:

I’ve worked in teams where line management was with the Technical Lead; where it was split between the Technical Lead and other people; and where it was solely other people outside of the team. I personally don’t see a reason why line management has to be the Technical Lead, but something I would call out is ambiguity. If you have other people line managing members of the team, you need to have clear accountability defined. There should be no second guessing of either party. It creates a stifled, and toxic environment that will stop the team delivering their best. Inertia will kick in.

Context and stakeholder management is potentially something outside of this team dynamic, but needs to feed into it. This is potentially where a Product Owner and Engineering Manager/Director can support the team. If you don’t have a Product Owner in the team, you are going to need some direction from product management. And likewise the context of what you’re doing, and what other teams are doing, is likely to come from Engineering Managers/Directors (depending on the size of your org).

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.

You give accountability to new teams.

I say a team unit, because this works across the org. If you have (for example) 5 teams reporting to an Engineering Manager, when that engineering manager becomes saturated, you add an entirely new unit to scale horizontally.

This is common thinking across our industry. Be it 7 +/- 3, or pizza sizing, or the scrum of scrums layering.

When do you know if you need to add a new 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, you need to add another team.

If you are scaling, you are likely to come across engineering teams that need to work across product teams. Examples potentially could be: security; auth; UI pattern libraries; or overall platform stability/accountability. Whilst these are individual products in their own right, they are servicing other development teams. This is a nuanced difference, but a difference that needs to be understood. The engineers/designers on these teams 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.

If you have senior Individual Contributors who want to progress their careers, then these teams may be a good fit. It will provide them an overarching view of key products, it will require them to collaborate more, think of others, and provide pragmatic solutions. Their mindset will need to shift from a singular product focus to a broader org way of thinking - i.e. strategic. This may also be a good fit for a Technical Lead who wants a wider technical accountability either before, or instead of, the Engineering Manager role, which would focus more on the strategic aspects of the business and people side. If there is a need to name these roles differently from Senior and Technical Lead then potentially Staff Engineer and Principal would be fitting. These are roles that would not only generate work for the team, but drive the implementation across a business unit or division.

That’s not to say these teams should only be formed with senior people, on the contrary (see below) but not all engineers are potentially going to want to be in this kind of team.

A quick note on junior team members

Juniors (or graduate schemes) are an important part of growing your business. We have all been there, the standard “2 years experience” being asked of you in job adverts. Recruit juniors into your team and teach them, mentor then, shape 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.

This is an interesting view point:

I had a quick 2 year stint at a startup where there were only 2 engineers (and I was one of them). I relied on books to get me through (felt like university life). We didn’t really have many customers or a live platform. My learning was academic. My next job was at an ISP where I had a plethora of mentors to support me. The platform was huge, and sprawling. I was certainly junior and the learning was much faster paced and based in the real world, not just theory. That job pretty much defined the engineer I am today. And it’s thanks to certain individuals. Pay it forward. Mentor the next generation.

See also

Content

Social

Recent