In the past couple of articles I have made two arguments relating to scaling software organizations:
- Have a longer-term plan for scaling your engineering teams, so that you can avoid a “Mythical Man Month” scenario,
- Favor small teams (and code bases) modeled after your organizational structure, as suggested by Conway’s Law.
In this article I will argue for product-centric teams, as I believe this organizational structure leads to the highest-performing teams.
Software development teams can be organized in many ways:
- On a per-project basis where teams pick up whichever project comes up next after they complete their current project
- As pools of engineers where teams or individuals are tasked as needed
- As constant teams, but with management regularly shifting engineers among them
- Horizontally, with the engineers working on layers of an application
- By expertise, with certain engineers (e.g. Security) on one team, focused on their speciality
- Vertically, with each team owning an area or product from top to bottom
- Broken down by product area, paralleling the product organization.
Systems which move engineers from one pool to another, or from one project to another may produce well-rounded engineers but will not benefit from the expertise gained by specialization. Software work is detailed oriented. Engineers need to build strong insight into both the code and domain to implement fixes and new features most effectively. Some flexibility is useful, but strongly favor stability and consistency in your teams.
Many companies, usually larger organizations, have horizontally segmented expert groups (Security, Build, Ops, Performance, etc.). Some software architectures are layered and align well with horizontal teams (UI, Core, DB, etc.). Management often likes these single-function organizations, as it gives them one group to hold accountable for one domain, such as Security.
Horizontal organizations foster engineering expertise by gathering similar skills in one place. But the expertise is specific to one technical area rather than focused on and supporting the company’s products and features; i.e. the artifacts that add value for the company. They can also add layers of bureaucracy, and lead to the rise of fiefdoms. Build them only when there is no alternative. Instead, consider something like Spotify’s Guilds and Chapters, from their classic article on team organization (still worth a read). If you must have expert groups, ensure that the members regularly embed on product teams to get a strong feel for the “real world”.
Certain circumstances call for particular organizations and their combinations. But whenever possible favor a close, lasting alignment between the product organization (or whichever organization specifies the engineering work) and small, vertically structured teams.
Conway’s Law underlies the preference for product-centric teams, because communication/planning/organization structures work most efficiently when the people who specify and build a product work together. The product and software folks all focus on the same domain, building relationships, rapport, and expertise in their area.
The relationship between the engineering team and the product area should be durable, allowing true domain expertise to develop. Teams should be able to identify with their product area, have a stable environment, and feel real pride of ownership. With this pride, a team will make their best effort and gain great satisfaction from their work.
This is not unique to software development organizations. The general idea of “Forming, Storming, Norming, and Performing”—a concept that has been around since the 1960s—is that teams go through a series of steps over time, from initial formation to high performance. This happens best with stable, longer lasting teams, who form a strong identity around their work.
Vertical teams are a great match for product-centric teams, as they can own an entire product, from design to release. These teams can work independently, make the best decisions on tools and techniques for their product, and execute as fast as they are able. DevOps teams are an example of strong vertical organization. How purely DevOps can be implemented will depend upon the engineering skill sets and seniority on the team. For example, many organizations lack enough Ops folks for each team, so must assign each Ops expert to multiple teams.
Small, Product-Centric Teams
Small teams, owning the entire software lifecycle, focused on a narrow product area, working closely with the product owners. This should remind you of the organization at an early stage startup. Anyone who has worked at one knows that these are fast moving, innovative, and highly productive engineering groups.
Marc Benioff, CEO of Salesforce, was well aware of the power of startups, and the challenges facing large organizations. While at Salesforce I heard Marc state a number of times that it would be startups, not existing large competitors, that might move rapidly and disrupt the company!
Salesforce seems to be doing just fine these days, but somewhere down the line Marc could be right. The best way to ensure that Salesforce, or your software company, can compete with startups is to perform at their level. Favor small, long-lasting, product-centric, vertically oriented engineering teams.