Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.
Software engineering teams can be complicated, and finding a solid approach to structure them for success is not easy. Probably, because there is no single way of doing it. My experience taught me that whilst there is no one-fix-all solution, some approaches have more pros and a higher success rate than others. I want to share and review some of the most common team structures and dig a little bit into a solution that worked well for me across different organisations of various sizes and specialisations. Whilst I don’t have the perfect answer, it could be good as a starting point for any high-performance team of skilled individuals who value contribution and meaning above politics and typical corporate BS, which creeps into organisations too often.
Traits of good software engineering teams
Before we move forward, I want to summarise what a “good software team” means, as this might not be obvious to everyone. Definitions are essential. If you disagree with mine, my conclusions might sound stupid later, so let’s eliminate the assumptions.
- Clearly defined roles — Each team member brings value and expertise to support projects and streamwork’s goals. It is clear why someone has been selected for the team and their role.
- Balanced seniority — There is enough work for different types of people. What seniors consider boring and demotivating, juniors will likely find challenging and exciting. Unbalanced teams lead to poor results and a lack of meaningful work, especially when everybody is senior.
- Responsibility and ownership — Every person is responsible for their work, and there is no room to stay under the radar. Good teams keep themselves accountable on personal and group levels.
- Reasonable size — Big team = complex communication. The more people need to be kept in the loop, the less work will be done and more confusion created. The perfect agile team is around 4–5 engineers + product and/or designer to keep things smooth and simple.
- Trust — People need to know each other better than just from plannings, standups and arguments through PRs. A good team is a group of people who trust each other and can have honest and constructive discussions, even if they disagree. This is ultra-important in the remote-first world.
- Transparency — It is clear what the team is working on. Usually, that means having an updated board and tasks connected with high-level company goals and workstreams (roadmap). A good team proactively share what they do without being chased for updates.
- Strong leadership — The leaders are the single and most important predictor of a teams’ success. It is much harder to understand their impact if some of the points I mentioned earlier are not in a place like transparency, lack of well-defined roles or too many managers involved.
In the end, a good software engineering team is the one that works well, but you would be surprised how often that’s not the case. Engineering leadership and developers rarely challenge the status quo regarding organisational structure, thinking the enemy they know is better than the one they don’t. That’s why so many organisations are stuck working inefficiently. The world has to develop stupid phrases like Great Resignation or recently trending Quiet Quitting to draw attention to poor leadership, which will likely change nothing.
Deep dive into the most common team structures
Let’s dig into the two most common and flawed approaches. Of course, there is more, but I’ve learnt that most of them are just slightly different variations from the two I will expand on.
Single-discipline teams with software managers
A structure like that can often be found in typical waterfall setups. However, I only recently stumbled upon a company with an engineering team built just like that and trying to be agile. My first goal was to move away from it as it generated enormous inefficiency across the product, and engineers were overworked yet delivering less than they could.
Pros
- It can bring each technology team together and build exemplary communication between members.
- Dev Managers are likely to be technology experts within their discipline.
- Easy to set up and feels intuitive when teams are tiny (2–3 persons each). Often it will be a preference to people who have no clue how engineering teams should be structured.
- Usually comes with pretty clear responsibilities across the team.
- Easy to expand into new technology areas.
- It’s easier to interview new hires as they talk to the same manager they will work with, which helps to create a better culture across teams.
Cons
- It will likely create tribalism in the tech organisation as each team member identifies only with one tight group. This leads to US vs THEM mentality.
- Sometimes this approach comes without an engineering manager, and a product or delivery person manages the team, which means zero career progression and poor technology focus. Teams become feature-driven, and engineers are turned into code monkeys.
- Creates silos across the organisation and never-ending dependency as products often require delivery across multiple platforms. Teams must rely on and wait for each other, often having different priorities.
- Too many streams and projects happening within the same team as each team member will likely work on something different.
- Occasionally team members have no clue what their colleagues work on despite sharing updates on each standup. They just don’t care.
- Harder to align cross-platform releases.
- Product, delivery, and scrum masters become a bottleneck as they shuffle many requestors and try to coordinate many projects across multiple engineers at the same time.
- Lack of understanding of what and how other teams are doing, with minimal chances to get help from outside.
- It is harder for people to get involved in any other business area than the one their team is dealing with. It is almost impossible for engineers to explore new technologies and areas where they are not experts yet.
- Less opportunity for people to share knowledge and try new things like leading a team, getting involved in different projects and taking on different roles.
- Harder to show any initiative, primarily when a team is dominated by strong-personality or egoistic seniors.
- Limited scalability if you need more engineers. Having more than 7 reports for a manager is problematic. It will clog the team, and if you create another one, for example two web teams, you will end up with two web managers, likely not aligned
Cross-functional teams with software managers
This setup is widespread in “agile environments” but brings many challenges and problems. I would argue that despite it looking modern, it is a step back from the Single-discipline teams with software managers structure I talked about earlier. It has the worst of all worlds but makes feel the higher management good, and probably that’s why it is popular. Way too popular.
Pros
- Easy to set up.
- Very easy to scale horizontally by adding more teams.
- Easy to find managers as they don’t need to be technology experts. They are just focused on people, not tech.
- Easy to bring contractors and allocate them to a particular group.
- Creates nice silos of responsibility and focus, easy to understand for people from outside the engineering team.
Cons
- Often too many different kinds of managers involved in an agile team create confusion about responsibility and team leadership. Especially when technical arguments arise and someone has to make an unpopular decision.
- Managers often become just “people managers”, and their technical expertiese becomes irrelevant and forgotten. Most engineering managers were coders once, so it might be particularly hard for them.
- Switching engineers between teams is like starting a new job — a new manager, processes, and sometimes applications. It might be a very different environment, and it’s often difficult for engineers and the company.
- The team’s skillset becomes rigid and predefined.
- Sometimes this approach comes without an engineering manager and a product or delivery person managing the team, which means zero career progression and poor technology focus.
- There is little to no incentive to align engineering practices between teams, especially if each is working on a different app. It can lead to different standards and unnecessary overhead or differences in the ways of working.
- It creates a group mentality where anybody outside the team is an enemy, and engineers are often less connected to their peers working on the same code base and tech in other groups.
- Fewer opportunities to talk to fellow engineers and challenge decisions that might hurt the company later.
- Managers are ex-coders who most likely have one specialisation, and their teams are often cross-functional. That limits their technical contribution and can create bias.
- Developers often have no idea what other teams are working on, nor their colleagues from the same specialisation. This can be solved, but usually, it’s left unchecked.
- This setup very often leads to an idea to hire full-stack engineers only to solve some of the problems (but introduce new ones).
- Hiring is awkward as a person might be interviewed by people they will never really work with closely. That’s very bad.
That’s a simplified version of the Spotify Model, which you probably should not consider unless you are a corporation that can afford it. Spotify admitted that it doesn’t work for them either, so that should be a good indication if you are considering it. Also, their naming convention of squads, alliances, tribes and chapters sounds weird to me.
The one that works — Self-managed cross-functional teams
A reasonable approach to building software engineer teams based on trust and the assumption that we are dealing with responsible adults. Teams can better organise themselves to deliver the work if they are led by context and understand the group’s and company’s goals and how their work contributes to them.
“Each manager should be able to feed his direct reports with 2 large pizzas.” — follow this rule, and the team will grow naturally and predictable.
This structure has been tested by a team of over 70 engineers and 15 streams of work (after minor tweaks). It has been tested with small groups like 6 engineers & 2 streams, and anything between. Of course, it will get complicated if we apply it to a technology organisation of 100+ employees. Still, it shouldn’t be hard to scale when you split it into smaller units based on products or applications, but it all depends on the circumstances.
Notes about the diagram to clarify a few things:
- The dark-yellow boxes in each stream = team lead.
- Engineering, Product & Design groups report to the same manager to create solid alignment between different disciplines, but in many cases that’s actually not possible.
- No QA in the diagram, so it might be worth adding them to each stream of work as any other members. I would add QA Manager too to oversee them.
Pros
- Engineering managers have an overview of multiple workstreams and can identify challenges and help in different projects.
- It’s easier to move people around teams where they are genuinely needed. Whether it’s permanent or temporary. No manager change is necessary whatsoever.
- People’s skills or aspirations can better match projects (streams) from the roadmap.
- Managers will likely be experts in the technology they were hired to lead, making them people managers and helpful in dealing with technology and steering critical decisions.
- Every engineer feels like a part of their agile team and a part of a technology group. Prevents silos of work and tribalism.
- Easier to interview new hires as they talk to the same hiring manager, which helps to create a better culture across engineering teams.
- It’s easy to segment disciplines into more granular teams like Design could become UI Team and Research Team, each with its own manager, reporting to the Head of UI/UX.
- Managers have an overview of what is happening in the whole engineering group, rather than focusing only on a small part, or one project.
- It’s easier to bring contractors as they are technology bound and will be part of the same platform group. Easie to move them around agile teams too.
- Managers can consider not only technology but also the human aspects of their team. That enables to creation solid career-progression path and more growth opportunities.
- Most managers are still passionate coders and want to share their knowledge, help with PRs and occasionally write something.
- Easier to replace or fill in for people when changes are happening.
- Encourages knowledge sharing, challenging decisions and helping each other across the technology stack. PRs are an example where devs can look into other teams’ work.
- Pros significantly overwhelm the cons in building independent and happy agile teams capable of responding fast to changes.
Cons
- It might create confusion as managers might get involved with multiple projects if engineers don’t have strong ownership skills.
- PRs from another agile team can create some headaches if they are not appropriately managed or accounted for.
- It requires proactiveness, ownership and responsibility from every team member as they are spokespersons on behalf of their respective technologies in their agile teams.
- It might be hard to get buy-in from the higher management as they have to give away control, and the approach requires trust that people are capable engineers and not just code monkeys.
- Extra planning on structuring teams once in a while (likely to happen twice a year).
- This setup ends up sometimes with too many engineers in each agile team. Watch out for it.
- Some people will jump between agile teams more often than others.
- Harder to enforce a top-down agile process if managements would like them to work in by-the-book Scrum, for example.
Other counter-productive things companies do and no fancy team structure will fix
- Dedicated and siloed teams to deal with things like design systems or “Core” teams are often helpful, but unless you hire 200+ developers, they work against the company goals and good engineering practices.
- Betting only on generalists, full-stack developers who can do everything, and there is no focus on hiring talented engineers with deep knowledge on topics to drive the technology, architecture and evolutions of the digital product.
- Force particular agile methodology and try to fit all teams into the same approach. For example, 2-weeks, by the book Scrum. Different groups have different needs, and if the leadership expects everybody to work exactly the same way, all teams will be as weak as the worst link in the chain.
- An engineering delivery team led by non-engineers, like products or designers, is an excellent sign that things won’t go well. People who don’t understand the life of an engineer can rarely balance development and priorities to bring the correct value to the company. In most cases, it leads to a feature obsession where all it matters is delivering the next thing and just ticking another box.
- Product-obsessed companies generate a vast amount of waste called “engineering backlog”, making everybody’s life miserable and never acknowledging the problem until it’s too late.
- Companies that rely too heavily on expensive contractors, potentially making them the majority of the engineering workforce, often suffer from short-sightedness. Things work here and now, but it will cost the company in the future. That’s poor leadership often seen in corporations where $$$ is all that matters.
- Too many cooks in the kitchen! How often have you seen a team with delivery, product, and engineering managers? On top of that, maybe a design manager and project managers who get involved? In the big corporate world, these kinds of teams are not unusual. It leads to too much fluff-talking and no work done. Scrum masters & delivery managers per each team bring zero value and often create bottleneck and communication problems between engineers and the product team.
Last word…
Different approaches might work better in different environments. You might end up with the wrong conclusion why a particular setup didn’t work for you. So the last section about counter-productive things companies do is just a reiteration of what will make any of these structures a guaranteed failure.
Go and try, and don’t be afraid to experiment. It won’t be easy, though.
A few more posts which are around teams and ways of working which you might find interesting…
