Skip to main content

Organizing teams

Summary: your org chart determines your software architecture — that is Conway's Law, and it is a remarkably robust empirical observation. This lesson explains the law, the reverse maneuver that consists of using it deliberately, the four team types of the Team Topologies model, and the five most widespread DevOps organization anti-patterns.

1. Conway's Law​

Why this law is so robust: software components are designed by people who have to talk to each other. Where communication is easy — within a team — components are tightly coupled and cohesive. Where it is difficult — between two distant departments — components develop more explicit and more rigid interfaces.

The corollary that interests executives: you cannot decree an architecture that contradicts your organization. Many companies have tried to adopt microservices while keeping an organization in functional silos. They got what is sometimes called a distributed monolith: all the drawbacks of microservices, none of their benefits.

2. The reverse Conway maneuver​

What this reasoning changes in how a transformation is led: the first architecture decision is an organizational decision. That is why DevOps transformations that start with tool selection fail, while those that start by redefining team boundaries succeed.

Point W is the deep mechanism: an autonomous team naturally seeks to reduce its dependencies, because every dependency makes it wait. Decoupling stops being a requirement imposed by an architect and becomes the team's own self-interest.

3. Team Topologies — the four team types​

The Team Topologies model, published by Matthew Skelton and Manuel Pais in 2019, has become the reference for organizing technical teams.

Type 4 is the most misunderstood, and that is a pity because it is often the right answer. An enabling team does not execute the work of others: it makes them capable of doing it. It accompanies a team for a few weeks on observability, for example, then steps back.

That is exactly what most of the "DevOps teams" created in companies should have been. Instead, they became permanent and took over the work — thereby recreating the silo they were meant to remove.

Type 2 deserves an essential clarification: the word self-service is decisive. If teams have to open a ticket and wait three days, it is not a platform, it is a renamed operations department. A platform is consumed on demand, without human intervention.

4. Cognitive load — the central notion​

This is the most useful contribution of Team Topologies, and it corrects a naivety of early DevOps. The idea that every team must master everything end to end is appealing but runs into a real human limit. You cannot be excellent at insurance, Kubernetes, cloud security and observability simultaneously.

The organizational consequence: end-to-end responsibility remains the goal, but it becomes tenable because the platform makes the technical part simple to consume. The product team remains responsible for its service in production — it simply does not have to become an expert in the underlying infrastructure.

5. The five anti-patterns to avoid​

Anti-pattern 1 is the one affecting the most organizations, and it comes from a laudable intention: creating a team to "do DevOps". But placing a team between the other two adds a handoff instead of removing one. If that team must exist, it should be enabling (it transfers the skill then steps back) or a platform (it provides self-service), never an intermediary.

Anti-pattern 5 is the hardest to address because it looks like a success. The person involved is effective, appreciated, and solves every problem. But they constitute a single point of failure: their departure or absence paralyzes the organization. The solution goes through documentation, shared on-call duty and task rotation — not through blaming that person.

6. Team size​

The calculation in point W speaks louder than an abstract principle. With five people, there are ten bilateral relationships to maintain. With fifteen, there are one hundred and five. Coordination becomes a full-time job, and it is mechanical — it has nothing to do with the quality of the people.

7. The "you build it, you run it" principle​

The two conditions are essential and often forgotten. Making a team responsible for production without giving it the autonomy to deploy or the means to act amounts to transferring the stress without the power. It is one of the most effective ways to make a DevOps transformation fail and to drive away the best people.

On condition 2: on-call duty is sustainable if you are rarely woken up. If alerts are numerous, the problem is not the person on call, it is the design of the alerts — a topic covered in our observability course.

Remember in 30 seconds​

  • Conway's Law: your software ends up looking like your org chart, whether you want it to or not.
  • Wanting microservices with a siloed organization produces a distributed monolith: all the drawbacks, none of the benefits.
  • Reverse Conway maneuver: organize the teams according to the desired architecture, and let it emerge.
  • The first architecture decision is an organizational decision.
  • Team Topologies, four types: stream-aligned (the main one), platform, complicated subsystem, enabling (temporary).
  • A platform must be self-service. If you open a ticket and wait, it is a renamed operations department.
  • Cognitive load: a team cannot master everything. The platform exists to absorb technical complexity.
  • Five anti-patterns: intermediary DevOps team (the most widespread), renamed operations, developer alone without support, disconnected tooling team, indispensable hero.
  • Team size: 5 to 9 people. The number of relationships grows quadratically.
  • "You build it, you run it" works under two conditions: real autonomy and sustainable on-call duty.

Next: Becoming a DevOps engineer: skills, salaries and certifications →