Conway's Law in reverse

Day 25: Conway's Law in Reverse — When the Team Changes and the System Doesn't

Your org chart can change in a week. Your architecture won't notice for years. Every hire, resignation, transfer or 'we can do this with three people now' changes who can safely touch which part of the system. If you treat those as HR events only, the system and the team slowly drift apart. Most leaders find out during an incident.

The week two of four engineers resigned

When I was a startup CTO, two of our four engineers resigned in the same week. After the hard conversations, I opened our service map to plan the handover. Four services. In my head, each one had a single name next to it. Two of those names were leaving.

We never designed it that way. Nobody ever said 'one service per person' in a meeting. That's still what we had built. The architecture diagram was an org chart wearing a costume.

How it happened

It came from normal early-startup logic. Four engineers, too much work, so you give each person something to own. People like ownership, it means less coordination, and everyone moves fast in their own space. I thought I was being a good CTO.

The mistake was where I drew the lines. I drew each boundary around a person instead of a domain. One service existed because one engineer liked working on the data pipeline. Another got split off because two people kept stepping on each other in the same repo. The boundaries matched the people we had, not what the business needed.

• ▹Boundary around a person: 'This is Engineer B's thing.' It exists because of who built it.
• ▹Boundary around a domain: 'This is billing.' Billing changes for its own reasons, at its own speed, under its own rules, and that's why it stands alone.
• ▹The test is simple. If that person left tomorrow, would you still split the system this way? If not, the boundary belongs to a person.

The law, in one paragraph

In 1968, Melvin Conway wrote in 'How Do Committees Invent?' that any organisation that designs a system will produce a design whose structure copies the organisation's communication structure. Put plainly: two groups that rarely talk will build parts that meet through a narrow, formal interface. One person building something alone produces a separate box. I didn't need the paper to prove it. Our four-person team had produced a four-service system.

The part the slogan skips

Everyone quotes the headline: systems copy the shape of the org. The slogan leaves out what follows from it, and that's the part that hurts leaders. When the org changes, the system stays the same. The org chart can change in a week. The architecture carries the old team's shape for years.

Here's what those two resignations left behind:

• ▹Orphaned services. Two of them, running in production, and nobody left who had written them or could change them with confidence.
• ▹Lost tribal knowledge: why a retry was set to that value, which cron job actually mattered, which env var was a leftover. None of it was written down, because the owner never needed to write it down.
• ▹Accidental contracts, meaning APIs and message formats between services that existed only because two people sat at different desks. Now one person looked after both sides of a boundary that served no purpose for them.
• ▹Seams in the wrong places. Any feature that crossed two orphaned services meant changing unfamiliar code twice, then carefully ordering the deploys between them.

What the orphan cost looked like

Nothing broke the day they left. The cost showed up a few weeks later, in three ways.

• ▹The first incident. One orphaned service failed in a way nobody had seen before. The remaining engineers were smart, but they were reading the code for the first time while customers waited. Recovery time depended on how fast someone could learn the code. The bug itself wasn't the hard part.
• ▹The 'who even knows this?' Slack thread. Someone posts a question about the service, three people react with the eyes emoji, and someone suggests messaging the person who left. When you see that thread, the boundary has lost its owner.
• ▹Everything got slower. Any feature crossing a dead boundary paid a tax: two PRs instead of one, versioning between services that no longer needed to be separate, and reviewers approving code they didn't fully understand.

There was no technical failure here. Each service was fine on its own. What failed was the fit between the shape of the system and the shape of the team now responsible for it.

Why this matters more in 2026

Earlier in this series we covered team design and clear ownership. Here's the new piece: AI is changing team shape faster than any re-architecture can keep up with. Teams are shrinking. Engineers are moving from writing code to directing and reviewing agents. And leaders keep hearing 'with coding agents, three people can do what eight did.'

Maybe that's true for producing code. It isn't automatically true for understanding the system. The codebase still reflects last year's headcount, with services, repos, queues and contracts drawn for eight people. Now three people own boundaries they didn't draw and may never have touched.

• ▹Agents write code faster. You still need a human who knows why a boundary exists and what breaks if it moves.
• ▹Agents working on a boundary nobody clearly owns tend to grow the system along the seams it already has. They copy the old shape, accidental parts included.
• ▹Smaller teams mean more boundaries per person. Each boundary needs context, on-call knowledge and judgment in review, so the load per person goes up even when the typing goes down.
• ▹Agent fleets have their own Conway effect. Give each agent or pipeline a narrow slice and the system will grow interfaces that match how you split your agents, not how your domain works.

The lesson: every org change is an architecture change

Every org change also changes who understands which part of the system. There's no way to do one without the other. So headcount moves, reorgs, role changes and 'AI lets us do this with 3 people' decisions deserve the same scrutiny as an architecture review. A conversation with HR and finance isn't enough.

• ▹Before a reorg, ask what happens to each boundary, not just each person.
• ▹Before a reduction, find the services that will end up with zero or one person who understands them.
• ▹Before 'AI lets us shrink', ask whether the architecture needs to shrink too. Fewer services, fewer contracts and fewer seams might be the only way a smaller team can actually hold it.

A check you can run this week

• ▹1. List your services or modules next to the people who really understand them. Skip the CODEOWNERS file and the wiki. Ask who could debug it at 2am with no help.
• ▹2. Circle every boundary that exists because of a person rather than a domain. If the only reason it's separate is 'that's how X built it', circle it.
• ▹3. For each planned org change (a departure, a transfer, a role shift, a smaller team), ask which boundaries it orphans. Anything that drops to zero or one person who understands it is a risk.
• ▹4. Merge or re-own before people leave. Afterwards is too late. Pair the new owner with the departing one, merge services that were only ever a split between people, and write down what only one person knows while that person is still around.

# boundary-map.yaml: review whenever headcount or roles change
- service: notifications
  domain: customer-messaging       # or 'none: split by person'
  change_rate: weekly
  understood_by: [engineer_c]       # who could debug it at 2am
  bus_factor: 1                     # < 2 is a flag
  affected_by_planned_change: yes   # engineer_c moving teams in Q1
  action: pair engineer_a now; consider merging into messaging

- service: reporting
  domain: none (split by person)
  change_rate: rarely
  understood_by: [engineer_b]
  bus_factor: 1
  affected_by_planned_change: yes
  action: merge into ingestion before handover

What I'd do differently as that CTO

• ▹Draw boundaries around domains. Billing, ingestion and messaging each get their own space because the business runs different rules there. Giving someone a thing to own isn't a reason.
• ▹Draw boundaries around change rates too. Keep code that changes together in one place, and split only where the speeds clearly differ. That way one departure doesn't freeze a seam you touch every week.
• ▹At least two people should understand every boundary. One person can own it, but the understanding has to be shared through rotation, paired reviews and on-call time in each service.
• ▹A small team needs fewer boundaries. Four engineers didn't need four services. One well-structured modular codebase would have survived two resignations far better.

When NOT to over-apply this

• ▹Don't reshuffle code every time someone goes on holiday. Act on lasting changes like departures, reorgs and role shifts.
• ▹This isn't a case for one giant shared blob. Domain boundaries are still good. The problem is boundaries drawn around people.
• ▹Be careful with the 'inverse Conway' move, where you reshape teams to get the architecture you want. Don't use it to justify a reorg you were going to do anyway. If you use it, say clearly which architecture you're aiming for.

Close

The service map I opened that week wasn't really a map of our system. It showed a four-person team that no longer existed, still running in production. Tomorrow, on Day 26, we turn it around. Instead of letting the old org shape the system by accident, we'll look at how leaders design the next version of the org on purpose, so the team and the architecture change together.

Extend your knowledge

• ▹Melvin Conway's original 1968 paper, 'How Do Committees Invent?' (Datamation). It's short, and the argument is more careful than the slogan.
• ▹'Team Topologies' by Matthew Skelton and Manuel Pais. Start with the chapters on cognitive load and the inverse Conway maneuver.
• ▹Martin Fowler's bliki entry on Conway's Law, a clear explanation of the law and the inverse Conway maneuver.
• ▹Exercise: build the boundary-map.yaml above for your own system this week, and bring every bus-factor-1 row to your next planning meeting.