Home › Organization Design & Governance › Four Fundamental Team Types
Organization Design & Governance · Team Topologies

Four Fundamental Team Types

Most teams should own a flow of work end to end. A few exist to make those teams faster.

◷ 3 min read▤ 1 true storyWorks the same with AISee its neighbors on the map →

In 2016 Spotify was hiring as fast as it could, and by its own account the new people were slowing it down. The company tracked how long it took a new engineer to get a tenth pull request, a tenth piece of code, merged. The answer was more than 60 days. Pia Nilsson, an engineering director who had joined that year, later said seeing the number was “like a cold shower.”

Spotify’s small, autonomous teams each built what they needed, and by the company’s account there could be 15 versions of the same service. Newcomers learned how things worked by tapping a colleague on the shoulder. The obvious fix was to centralize. Nilsson’s team ruled it out: “No one would use it.” The case has the rest.

Four kinds of team

Most teams should own a flow of work end to end. A few exist to make those teams faster.

That is the core of Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais. It names four kinds of team:

  • A stream-aligned team is “aligned to a flow of work,” usually a slice of the business, and owns it from start to finish. The book’s site says there should be “no hand-offs to other teams for any purpose.”
  • A platform team provides “a compelling internal product to accelerate delivery by Stream-aligned teams.”
  • An enabling team “helps a Stream-aligned team to overcome obstacles,” teaching skills it lacks, and moves on.
  • A complicated-subsystem team owns a part “where significant mathematics/calculation/technical expertise is needed,” so the other teams don’t each have to master it.

The site is firm that four is enough: “Adding more types or creating hybrids just confuses everyone.” The software developer and author Martin Fowler, summarizing the book, calls the stream-aligned team “the primary kind of team.”

What the other three are for

Fowler points out that splitting business teams from technical support teams is “as old as enterprise software.” What he finds new is the reason given. A team that owns a whole stream, building it and running it, can drown in everything it has to know. In Fowler’s summary, “the primary benefit of a platform is to reduce the cognitive load on stream-aligned teams.” The same goes for the other two types: an enabling team grows skills so stream-aligned teams can stay independent, and a complicated-subsystem team takes one hard part off their plates. (The cognitive load page looks at that limit itself.)

That changes how a platform should be built. If the goal is lighter load, its users have to want it. Spotify’s Platform team treated the company’s developers as “customers” and asked them what was in the way: interruptions and things they couldn’t find. It built Backstage, one place to look up every service, who owned it and how to use it, and let teams keep owning their own parts. Spotify says the time to a tenth merged change later fell to 20 days. These are the company’s own figures, and it changed other parts of onboarding over the same years.

Spotify doesn’t use the Team Topologies labels. Its autonomous teams look like stream-aligned teams, and its Platform team does a platform team’s job, but that mapping is ours.

Imagine a chain of six cafés where each manager orders supplies, schedules staff and fixes the espresso machines alone. A small head-office team that negotiates suppliers and keeps a repair contact list would work like a platform. If the managers had to file a request and wait days for every order, they might go back to doing it themselves.

Splitting work among agents

Agent setups face a similar question about where to put specialist work. Claude Code’s subagents are “specialized AI assistants that handle specific types of tasks.” Each one runs “in its own context window” and “returns only the summary,” so the search results, logs and file contents it reads don’t flood the main conversation. That is close to the job of a complicated-subsystem team: the specialist carries the detail, and the team that relies on it gets a clean result.

The fit is loose. Subagents are usually short-lived helpers called by a single agent, while Team Topologies describes long-lived human teams. The question carries over all the same: which work should a team, or an agent, own end to end, and which should someone else carry for it?

At Spotify, by the company’s account, the Platform team couldn’t order anyone to use what it built. Backstage had to be the better solution, not the only one.

Stories behind it

Play it

Sources

  1. Spotify Engineering, A Product Story: The Lessons of Backstage and Spotify's Autonomous Culture, May 2021
  2. Spotify Engineering, How Backstage Made Our Developers More Effective, and How It Can Help Yours, Too, September 2021
  3. Team Topologies, Key concepts
  4. Martin Fowler, Team Topologies
  5. Claude Code documentation, Create custom subagents
  6. Thoughtworks Technology Podcast, Developer Effectiveness, with Pia Nilsson
  7. Spotify Engineering, How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem, August 2020