Software organizations usually find that they become less efficient as their product grows more complex and they add more engineers to their teams. This is largely predictable, as more complex systems are generally less efficient. But the structure of the engineering organization absolutely has an effect on its ability to perform.
I’ve worked with and within a number of team structures, each with its own strengths and weaknesses. The most common approaches I’ve seen over the past couple of decades are Horizontal Teams, Vertical Teams, Developer Pools, and Outcome-Driven (aka Mission-Oriented) Teams. I’ll discuss the benefits and disadvantages of each of these structures.
Team Performance Considerations
Before digging into the team organization structures, it is useful to describe how software engineering team performance can be judged. Performance of teams depends on many factors, starting with the skills, experience, training, mix, and motivation of the engineers. For a given set of engineers, how they are organized into teams can emphasize certain characteristics and facilitate (or hinder) how they perform. Some of the key aspects that organization can affect include:
- Software delivery: How much useful software your engineering teams consistently deliver, sometimes measured in product points or customer value, is a key consideration when evaluating teams.
- Software quality: The overall quality of designs, code, and bug fixes produced by a team reflects their expertise, domain knowledge, and discipline.
- Team reliability and resiliency: Good teams make commitments and meet them. Great teams are resilient in the face of obstacles, meeting their commitments even when it is difficult.
- Innovation: The ability for teams to come up with novel, useful solutions to difficult problems tends to be a reflection of their skill, domain knowledge, and ownership over their work.
- Technical expertise: The skill with which engineers and teams can effectively learn and leverage relevant technologies is closely related to their ability to solve complex technical challenges.
- Product expertise: Product domains often require specialized knowledge to fully understand deeper implications. Software is usually customized for each domain. Teams that develop product and related software expertise are able to make more informed decisions, produce more useful code, and make more accurate changes.
- Team synergy: Team synergy is the ability for a team to deliver more together than they could as individuals. This is based upon their skill, motivation, comfort working together, and ownership of their work.
Developer Pools
In developer pools, most software engineers (particularly UI and backend) are generalists, able to work on any issue that comes up. This is typically what you find at small, early stage startups where things move fast and it doesn’t make sense to create a complex organizational structure.
Pools are flexible, as engineers can easily be moved to important work (almost like outcome-driven teams). When quality and reliability issues arise, engineers from a pool can be switched over to these concerns to address them.
Small pools can resemble vertical teams, in that they tend to be aligned with parts of the product. This can foster good product expertise and innovation (again, assuming a small pool size).
In general, developer pools are efficient at small sizes and code complexity, but scale poorly. In an organization of any real size, something like 20-plus people, the flexible approach to moving engineers around does not foster real product or technical expertise, quality, or synergy. Pools are rarely used as a company gets larger, as other organizational structures add more value.
Horizontal Teams
Horizontal teams group engineers by domain expertise. They are called horizontal because the domain groups are often represented as a series of horizontal blocks, with the top block for UI developers, the next level down for backend engineers, the next for QA engineers, etc.
This structure emphasizes the creation and leveraging of deep technical expertise, as related experts work closely together. Innovation can be great within the technical domain, as the experts can feed off each other. The engineers on horizontal teams can develop strong feelings of ownership for their ‘layers’.
Quality, reliability, and resiliency also tend to be good, as long as the work the team performs fits within their area of expertise. With all of these benefits, it should be clear why vertical teams were the preferred structure for larger, more traditional software companies in the past.
However, horizontal teams tend to suffer some key deficiencies. Customer value, innovation, and product expertise are all deemphasized. The engineers in each horizontal band focus on the challenges in their particular layer, not necessarily on the bigger picture. They can get siloed into their domains, losing the customer perspective. Engaging the various horizontal layers in the delivery of full solutions can take quite a bit of coordination.
Vertical Teams
In vertical teams, all required expertise to build products or services in related areas are grouped into one team. They can be like a mini startup for their particular product area. Vertical teams should have true ownership over reasonable, well-defined areas of a product. (Otherwise, they more closely resemble developer pools.)
Vertical teams are sometimes called ‘full stack’ teams (look at the diagram—each team is a full stack of people), with the presumption that experts on all parts of the technical stack are represented on the team. But that is a bit of a misnomer, as only the required experts will be on a given team. For instance, a team creating a service that communicates only through APIs would not require UI experts. When a product naturally breaks into limited technical domains vertical teams can take on the appearance horizontal teams.
Actually it’s rare that a vertical team has all of the areas of expertise permanently assigned to them. Some specialties, such as Operations, Security, and Performance, are usually shared between teams, because full-time membership is not needed or available. I’ll discuss this allocation of scarce expert in a following section.
Vertical teams are particularly strong in customer value, innovation, and product expertise, as they are often working on end-to-end features designed to meet specific specific customer needs, and develop a deep understanding of their product areas. Within their product area they can focus and produce high-quality code and fixes. They usually develop strong feelings of ownership for the product areas and code that they work with and can deliver software quite reliably.
Because vertical teams are aligned with (usually) long-lived products or services, the teams can build strong bonds and deep expertise. If the teams are instead aligned with specific features, or only temporarily aligned with products, they are really outcome-driven teams, as described in the next section.
Large initiatives that cross product domains require clear priorities and strong coordination to ensure that the vertical teams pull together. This is a common knock against vertical teams, as they tend to focus on their product priorities, which are not always aligned with the larger initiatives.
Outcome-Driven (or Mission-Oriented) Teams
Outcome-driven teams comprise all the engineers required to produce a desired outcome (a complete software solution). As such, they are a type of vertical team, so no additional diagram is provided. The key difference is that outcome-driven teams are not permanently aligned with any one particular product area, as are traditional vertical teams. Instead, they consist of a collection of engineers with the domain and technical expertise required to implement an overall solution.
These teams are created to meet specific emergencies or key opportunities. The team’s focus is on the solution they need to deliver, rather than on a technical or product domain. They are designed to deliver customer value as rapidly as possible. They promote innovation, as long as the team is granted true ownership. It can be exciting to be on one of these teams—while they last.
Outcome-driven teams can produce targeted results, but have long-term costs. Because teams exist only as long as they are required to meet a certain mission, the engineers are not as likely to develop deep product knowledge, perform with long-term reliability, and develop team synergy. Quality is particularly challenging for these teams as they often do not see the long term implications of their mistakes. The team that wrote the code is not necessarily the team that fixes the problems.
Outcome-driven teams are a specialized solution that should be used sparingly, when the benefits outweigh the costs.
Blended Approaches
It can be useful and practical to blend some of these approaches to fit the types of people you have and the type of work they need to accomplish.
For instance, if you were looking closely at the diagram for vertical teams you might have noticed that I cheated a little: I show Security Engineers and Database Engineers on both the Full Stack Team and the Backend Team, even though I have only one of each of these engineers shown in the Horizontal Teams and Developer Pools diagrams. This is because it is quite common to group certain scarce types of domain experts onto what are basically horizontal teams, then allocate them across multiple vertical or outcome teams, as needed. The challenge here is to avoid oversubscribing your experts.
A common technique for fostering strong bonds among engineers with shared specialties, useful when they are working in developer pools, vertical teams or outcome-driven teams, is to create technical ‘guilds’. Engineers in guilds, such as UI, DB, or QA guilds, meet regularly to learn, evaluate technical choices, and set standards. This simulates some of the positive effects found with horizontal teams, such as driving technical expertise and innovation, without removing the product focus from the teams themselves.
For projects that span product or technical domains, you might consider building a ‘virtual outcome-driven’ team, with stakeholders from all of the relevant teams involved, but without pulling the original teams completely apart, as you would do with true outcome-driven teams. The key to having this succeed is to ensure that the representatives will effectively represent their product or technical domain on the virtual team, and vice versa.
Spotify has a famously intricate system of squads, chapters, tribes, and guilds that takes these blending concepts to great lengths. It’s worth reading up on their system, even if you don’t try to implement it all at once.
Which Organizational Structure Should You Adopt?
So, which team organization structure (or structures) should you use? Pools of developers work well when the organization is quite small, but do not scale. If you are at an early stage startup, don’t overthink it. Just use a pool.
For typical product development, I find that the most flexible and useful team organization is based upon vertical teams, which are aligned with product functionality. These types of teams can grow and branch as products grow.
Blend in horizontal teams of technical experts if you need to, but don’t try to make everyone into a specialist. Instead, allocate the technical experts across teams as needed, and create guilds for the other areas of technical expertise that you want to emphasize. Engineers on the vertical teams can join one or more guilds to improve their skills.
If you need to generate the best possible technical solutions, rather than entire products, gather your experts into horizontal teams.
When using either horizontal or vertical structures, you can benefit from virtual teams for projects that span across physical teams. With good leadership and strong involvement, virtual teams can guide the success of these longer, more complex projects.
Consider outcome-driven teams only when they are truly necessary. Because these teams initially appear to generate great results, it is easy to over-use them. Non-technical stakeholders particularly like these types of teams, as the negative consequences are less apparent to them.
However, if your work is primarily of a consulting or professional services nature, where new projects and products appear and disappear over time, you may find outcome-driven teams the best possible structure.
Software organizations usually find that they become less efficient as their product grows more complex and they add more engineers to their teams. Give a little thought to the way you arrange your teams to provide them with the structure and organization they need to succeed.