We reorganised for the org chart and shipped the org chart. The product paid for it.
This is not a theoretical argument about Conway's Law. It is a description of something I helped cause, then spent two years repairing, at a reinsurance technology company that had the best engineering team I had worked with in a decade — cohesive, high-output, technically excellent — and then, through a management restructuring that was rational on paper, broke it into something that could no longer do what had made it excellent.
Conway's Law is usually quoted as a clever observation: "Any organisation that designs a system will produce a design whose structure is the communication structure of that organisation." What it is actually telling you, if you take it seriously as an operator, is this: your organisation chart is your product architecture. The boundary you draw between teams is the boundary you will eventually find in your interfaces, your integration points, your deployment pipelines, and your incident patterns. The reorg is never just about people.
How We Got There
The company had scaled from a small embedded technology team into a standalone engineering organisation over three years. By the time I joined as interim CTO, there were 40 engineers across product, platform, and data. The team had built well: a core platform serving multiple business lines, a data layer that was genuinely differentiated, and a deployment practice that most companies twice the size would envy.
The organisational pressure came from the business side. The COO wanted clearer accountability. Each business line — underwriting, claims, analytics — wanted a technology team that reported, functionally, to them. The board wanted to see a technology structure that could scale to 120 engineers over 18 months. The case for restructuring was not invented — there were real communication problems at the leadership layer, and the existing structure had not kept pace with the growth of the organisation.
So we reorganised. We drew three new team boundaries: one around underwriting, one around claims, and one around data and analytics. We assigned engineers to each stream. We appointed team leads. We announced the change with a deck and an all-hands. Everyone nodded.
And then, slowly and then quickly, the product got worse.
What Conway's Law Actually Did to Us
The problem was not that the team structure was wrong in principle. The problem was that the team structure we drew did not match the system's actual seams.
The platform had been built around shared services that cut across all three business domains. The authentication layer, the document handling pipeline, the notification system, the core data model — these did not belong to underwriting or claims or analytics. They were genuinely shared. And the decision we had not made explicitly, because we had not thought it through carefully enough, was who owned them now.
When the underwriting team needed a change to the document handling pipeline, they had to coordinate with the claims team, who also used it, and with the platform engineers who were now distributed across two of the three new teams. A change that had previously taken three days — one engineer, one review, one deployment — now took three weeks. Not because anyone was slow. Because we had put coordination overhead in the critical path of every non-trivial piece of work.
The seam problem
The most expensive version of a misaligned reorg is when your team boundaries cut across a high-frequency integration point. Every feature that touches that seam now requires cross-team negotiation, alignment meetings, and sequenced deployments. Multiply that by the number of features in your roadmap and you start to understand why the velocity numbers look the way they do.
The integration bug rate tripled in the six months after the reorg. Not because the engineers got worse. Because the code that had previously been owned and understood by people who sat next to each other and talked constantly was now maintained by engineers in different teams with different roadmap pressures and different sprint priorities. Shared code with shared owners becomes shared code with no owner very quickly.
The Specific Failure: Killing the Team That Carried the System
The hardest part of this story is what happened to the three engineers who had been, effectively, the architecture backbone of the whole system. They were the people who understood the shared layers, made the consequential design decisions, held the historical context that explained why things were built the way they were.
Under the old structure, they had operated as a de facto platform function — not formally titled, not separately resourced, but recognised by the broader team as the people whose opinion on architectural questions mattered. The informal structure worked because the team was small enough that the informal structure was legible to everyone.
The reorg made that informal structure illegible. Each of the three was assigned to a different team stream. Their architectural judgment was still needed everywhere — but their time was now owned by a single business line. Two of them spent the next six months trying to do two jobs: the product delivery work their new team lead expected from them, and the architectural work the rest of the organisation kept pulling them back for. They burned out. One left within eight months. One transferred to a different company inside the group. The third is still there, doing work well below what he is capable of, because the structure does not give him space to do the job he is actually good at.
That is the real cost of the reorg. Not the slower features. The slower features were recoverable. The loss of those three engineers — their knowledge, their judgment, their institutional context — was not.
| Before the Reorg | After the Reorg |
|---|---|
| Shared platform ownership, informal but legible | Ownership fragmented across three team streams |
| 3-day cross-cutting change cycle | 3-week cross-cutting change cycle |
| Architectural decisions made in corridor conversations | Architectural decisions require formal cross-team alignment |
| Integration bug rate: baseline | Integration bug rate: 3x baseline, 6 months post-reorg |
| Platform experts: embedded, recognised, available | Platform experts: siloed, over-allocated, burning out |
| Deployment coordination: within-team | Deployment coordination: cross-team, sequenced |
| Key talent: retained | Key talent: 2 of 3 lost within 12 months |
What We Should Have Done
This is not a counsel of perfection. Restructuring was necessary. But there are two things we did wrong that I would not repeat.
The contrast between what we built and what we should have built looks like this:
First, we did not start from the system's seams. The right way to draw team boundaries is to start with the system architecture and ask: where are the natural ownership boundaries? Where does the code already divide? What are the high-frequency integration points, and how do we make sure they have a single clear owner? We did the reverse: we started from the business structure we wanted and tried to map engineers onto it. The business structure did not match the system structure. Conway's Law then spent the next 18 months proving us wrong.
Second, we failed to formally staff the platform function. When you have a shared system and you're growing past 30 engineers, you need a platform team — not informally, not as a secondary allocation for a few senior engineers, but as a properly resourced team with its own roadmap, its own lead, and a clear mandate to serve the other teams. We tried to get the platform function for free by distributing its practitioners across the product teams. You do not get it for free. You get the cost without the service.
The Inverse Conway Maneuver
The concept is named but underused in practice: design the team structure you want first, then reorganise toward it deliberately. If you want a modular, loosely-coupled architecture, you need modular, loosely-coupled teams with genuine end-to-end ownership. If you need a shared platform to underpin product delivery, staff it explicitly and give it the same organisational standing as the product teams it serves. The team structure precedes the architecture. Not the other way around.
The Recovery
Eighteen months after the original reorg, we restructured again. This time we started with the system.
We mapped the actual ownership boundaries — where the code naturally divided, where the high-frequency integration points were, where the data crossed domain lines. We identified the shared services that genuinely needed a single owner and carved out a platform team to own them, with three dedicated engineers and its own product-style roadmap. We reduced the number of cross-team dependencies in any given sprint by routing shared service requests through the platform team's backlog rather than through direct cross-team coordination.
The integration bug rate returned to baseline within two quarters. The cross-cutting change cycle dropped from three weeks to five days. Not because the engineers changed — the same people — but because the communication structure stopped fighting the system structure.
We did not get the three engineers back. That cost does not have a recovery.
What This Means for Anyone Planning a Reorg
Reorgs are usually planned in PowerPoint. The decisions are made in a room with an org chart on a whiteboard and a set of business requirements about accountability, scale, and reporting lines. The engineering system is not in the room.
Before you finalise any team boundary, do three things.
Draw the dependency graph of your actual system — not the idealised architecture diagram, but the real one, including the shared services, the common libraries, the cross-domain data flows. Then overlay your proposed team boundaries. Any team boundary that cuts through a high-frequency integration point is a coordination tax you are about to impose on every engineer who works near that seam. Decide consciously whether that tax is worth paying.
Identify where your architectural judgment currently lives — the people who hold the system's history and context. Trace what happens to them under the proposed structure. If they end up allocated across multiple teams without a formal platform mandate, you are about to distribute tribal knowledge until it disappears.
Name the shared services explicitly. For every service or component that more than one team will need to change, decide before the reorg who owns it, how other teams request changes, and how that ownership is resourced. "We'll figure it out" is not an answer. It is a promise that you will revisit this in 12 months when someone is trying to explain to you why features are taking three times as long.
If you're navigating a restructure, scaling past 30 engineers, or trying to understand why your current team structure is costing you more than it should — let's talk. A 30-minute discovery call is usually enough to identify where the friction is actually coming from.