Conway's Law Already Chose Your Target Architecture

← All posts

Your target-state diagram is a prediction; your org chart is what will actually decide the outcome.

There is a wall in your programme office with the target state on it. Forty-something services, clean bounded contexts, an event backbone, a platform layer underneath. It took an architecture team four months and it is good work.

Now look at the other diagram, the one in HR’s system. A database team that owns all schema changes. A QA function that receives builds. An infrastructure group that provisions environments through a ticket queue. A change advisory board that meets Thursdays. Release trains that leave quarterly.

Only one of those diagrams will describe your system in three years, and it is not the one in the programme office.

Here is the claim, and plenty of vendors avoid it because it does not sell a platform: your target architecture is a prediction, and Conway’s Law will settle the bet. Decompose a monolith while keeping a functionally-siloed organisation and you will not get microservices. You will get a distributed monolith: the operational cost and observability burden of a distributed system, combined with the release cadence and coupling of the mainframe you were leaving.

Programmes that survive change the organisation on the same schedule as the architecture, and usually the organisation moves first. Not a reorg announced at the end as a “new operating model”, but a reshaping of team boundaries, ownership and funding before the first service is extracted.

Deloitte’s 2025 Tech Value Survey found that around 60% of leaders believe another 21–50% of enterprise value remains trapped in their current technology, data and people. The trapped value is not only in the COBOL. It is in the reporting lines.

What Conway’s Law actually says, and what the inverse manoeuvre means at enterprise scale

Conway’s 1968 paper states it precisely: organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations. Two things get lost in the paraphrase.

First, it is a constraint, not a tendency. A design gets split into pieces people can work on, and the interfaces between them are negotiated by the people who own them. Where negotiation is cheap, interfaces stay fluid. Where it is expensive, teams freeze the interface and design around it. The system ends up shaped like the cost of communication.

Second, it concerns communication structure, not the formal hierarchy. Two teams under different VPs who sit together have a cheap interface. Two under the same director who coordinate through an intake form do not. The org chart is only a proxy for the real variable: how expensive it is for one engineer to change something another depends on.

The Inverse Conway Manoeuvre in an organisation that has an HR business partner

The inverse manoeuvre, named by Thoughtworks, is deliberate: rather than accepting the architecture your organisation produces, reshape the organisation to produce the architecture you want. In a forty-person startup that is a Tuesday. In a 3,000-person IT function it is a multi-quarter programme with its own risk register, and pretending otherwise is why it fails.

It means five things, none architectural:

• Redraw team charters around business capabilities. Not “the Java team” and “the mainframe team” but “policy servicing” and “claims payment”, each owning its slice front to back.
• Move reporting lines, not just allocations. When a matrixed engineer’s team and function conflict, the function wins, and that conflict becomes an interface in your architecture.
• Change what gets funded. Persistent teams with an annual capacity, not projects with a delivery date and a dissolution date.
• Change who carries the pager. On-call is the sharpest signal of who owns a service, and usually the last thing to move.
• Renegotiate shared-service boundaries. A central DBA team that approves every schema change is a coupling point; services behind it are not independent.

Each has a stakeholder who loses something: the DBA lead loses control of schema, the QA director a headcount base, the CAB chair the meeting. These are the load-bearing walls of the current architecture, and removing them is the work.

How to tell whether you are building a distributed monolith

Nobody presents a slide saying the services are coupled. The programme reports green and the symptoms show up in the texture of the week. Score each item: 0 if it never happens, 1 if sometimes, 2 if it is how things normally work.

Scoring. 0–5: real service independence; protect it, because it erodes quietly. 6–12: drifting, with the coupling usually concentrated in one or two shared assets, and still cheap to fix. 13–18: a distributed monolith, and adding services makes it worse. 19–24: stop extracting and spend six months on organisational work.

Almost every item is an organisational fact in a technical costume: item 3 is a team boundary, item 6 a governance body, item 11 a funding model. No service mesh fixes them.

If you measure one thing, measure independent deployability: what share of production changes last quarter involved exactly one service and no cross-team coordination? Below roughly 60%, the diagram on the wall is fiction. Legacy maintenance already consumes between 60% and 80% of IT budgets across the industry, and a distributed monolith adds a second operating model without retiring the first.

Team Topologies applied to a modernization programme, not a greenfield product

Team Topologies, from Matthew Skelton and Manuel Pais, gives four team types and three interaction modes. Most enterprises apply it to the target state and leave the programme organised as a project. That is backwards: the programme is where the structure gets set.

Your legacy specialists are a complicated-subsystem team

In most enterprises the mainframe group is a maintenance backwater: keep the lights on, attrition managed by not replacing people. A complicated-subsystem team exists because part of the system needs specialist knowledge it is not efficient to spread everywhere. That is precisely a 40-year-old COBOL policy administration system.

The reframe is not cosmetic. The team gets a charter and a roadmap instead of a ticket queue, publishes an interface others consume, and becomes a place to build a career.

If you take one instruction from this post, take this: never let the word “legacy” appear in a team name. Call it the core platform team, the policy engine team, the settlement systems team. Names set expectations and expectations set attrition.

The migration tooling group is a platform team with a product owner

The people building extraction pipelines, test data management, anti-corruption layer scaffolding and observability defaults are not a shared service. They are a platform team, and the distinction is that a platform team has customers who could refuse to use it.

That clause is the whole discipline. Give them a product owner and measure voluntary adoption, time-to-first-deploy, and how many teams provision without human intervention. Measure them on uptime alone and they optimise for control, which means gates, which means a queue, which means the coupling has simply moved.

Enabling teams must have a dissolution date

An enabling team teaches a capability and leaves: a small group who know how to wrap untested legacy behaviour in characterization tests, embedded with a stream-aligned team for six to ten weeks, then gone.

The failure is easy to spot. The team becomes permanently attached, then reviews other teams’ tests, then becomes an approval step: a bottleneck with a friendly name. Write dissolution criteria into the charter on day one, so it stands down when six teams write characterization tests without it.

Collaboration is expensive on purpose

Collaboration is high-bandwidth and right for discovery, when two teams are finding a boundary that does not exist yet. X-as-a-Service is low-bandwidth and right once the boundary is known. Facilitating is a teaching relationship.

The mistake is leaving everything in collaboration mode because it feels cooperative. When talking is cheap, nobody commits to a contract and the interface stays fuzzy. Use collaboration for a quarter while extracting a service, then force the move to X-as-a-Service. If you cannot, the boundary is wrong.

The knowledge problem is a schedule constraint, so model it

Roughly 220 billion lines of COBOL run in production, the average COBOL programmer is around 55, and about 10% retire every year (DreamFactory). Those figures usually appear as background colour. Treat them as a schedule input instead.

For each critical subsystem, list the people who genuinely understand it, not those on the support rota, with years to retirement. From a composite of several insurance and banking estates:

Look at rows two and four. Premium rating is scheduled for year four and the knowledge has an eight-month horizon. That is not a risk, it is an arithmetic contradiction, and the plan is already invalid. Nobody noticed because it was sequenced by technical dependency, not knowledge availability.

Resequencing then follows mechanically: subsystems whose knowledge is most concentrated and closest to departure move earlier, whatever the technical convenience. That makes year one harder and year four possible. And a bus factor of one, common in the Delphi and Oracle Forms tier below the radar of a mainframe programme, is a risk you would never accept in writing.

Knowledge transfer that works, and the documentation drive that does not

Every programme tries the documentation drive. Six months before a key person retires, someone asks them to write down how the system works. You get 200 pages describing what the code already says and none of the reasoning a new engineer needs.

It fails because the valuable knowledge is conditional, not descriptive: why the reversal logic special-cases policies written before 2003, which batch jobs can safely be re-run. That surfaces only when someone is about to get a change wrong.

Four mechanics work, and they share one property: knowledge moves through work, not through documents.

1. Pair the legacy specialist with a modernization engineer on the migration itself. Not a handover meeting: joint ownership of one subsystem’s extraction. The specialist explains behaviour at the moment the engineer is about to get it wrong, which is when conditional knowledge becomes speakable. Budget both full time; part-time “support” across four workstreams kills it.

2. Record decision rationale, not system description. One page per decision: what we found, why the original design made sense, what we chose, what we deliberately did not preserve. Ten of these beat 200 pages, and they outlive the specialist.

3. Run archaeology sprints with a named output. Two to three weeks, a mixed pair, one question, one deliverable: the nightly batch chain as an annotated sequence diagram, or a characterization suite for the rating engine’s top twenty scenarios. The named output separates this from discovery that produces an unread wiki.

4. Reverse mentoring, in both directions. The specialist teaches the domain; the modernization engineer teaches Git, containers, CI and the cloud runtime. This is the retention lever that actually works. A 58-year-old COBOL developer knows their market value is tied to a shrinking platform, and a route to the modern stack offers them a future. Documenting everything and then retiring offers redundancy with extra steps.

The retention arithmetic, which almost nobody does

Retention bonuses feel expensive because they are a visible line item; the alternative shows up as schedule slip, which is not. Take a composite: a regional insurer we will call Northmark, a 70-person programme at roughly £14M a year, with twelve people holding critical knowledge.

The pool for all twelve costs about 12% of one quarter of slip. One departure that delays a workstream by a quarter pays for the pool for eight years. It does not get done because the pool needs a budget approval and the slip does not.

Tie payments to milestones rather than dates, and offer phased retirement eighteen months out. By the exit interview the decision is emotional as much as financial, and money rarely reverses it.

The two-tier culture problem, and how to design it out

The new stack is where the interesting work is, where promotions happen, where the CTO visits. Legacy becomes the place you get left. Within about two quarters, your most capable legacy engineers, the ones with options, transfer or leave. You lose the knowledge you needed most through a mechanism you created.

The countermeasures are structural. Posters about how everyone’s contribution matters do not survive the promotion committee.

• Never staff a “legacy team” and a “new team”. Staff mixed capability teams owning a business flow across both stacks, same standup, same objectives. That removes the boundary the status difference attaches to.
• Rotate deliberately, both directions. A modernization engineer who has never read the COBOL will rebuild the wrong thing. A legacy engineer who has never deployed to Kubernetes cannot see what good looks like. Six to twelve weeks, set at team level.
• Put legacy work on the promotion path explicitly. Add the sentence to the criteria, then count how many of the last two promotion rounds went to legacy-side work. If the answer is zero, your engineers have already run this analysis.
• Give the complicated-subsystem team the same tooling. A mainframe group on a 2011 change process while cloud teams have modern CI states the hierarchy plainly.

You cannot hire your way out of this

The market for COBOL, RPG, PL/I, PowerBuilder and Oracle Forms expertise is thin and thinning faster than your programme is moving. Even where you can hire, you get someone who knows the language, not your system, and the second is where the value sits. Expect twelve to eighteen months before an external hire is productive.

So sourcing is retention plus transfer, with hiring as a supplement. Which leads most enterprises to a systems integrator, where the failure mode is not incompetence but that knowledge leaves with the contract: three years in, the partner’s team knows your claims system better than anyone you employ, the contract ends, and the capability walks out with them.

Structure the engagement so this cannot happen:

• Two in a box. Every partner role has a named internal counterpart paired on the same work with the same commitments. Not a shadow observing, a genuine pair with both names on the outcome. It doubles the visible cost of a role and is cheaper than repurchasing the knowledge.
• Make knowledge transfer a payment milestone, with an acceptance test: the internal counterpart independently completes an equivalent extraction with the partner advising only, and writes the decision log.
• Cap the partner share of any capability team at around 50%. Above that, the internal counterparts are spectators.
• Write the run state into the contract. Decide who operates the system after go-live at the start. If the answer is the partner, you have outsourced the capability, which may be legitimate, but make it a choice.

Governance has to be decomposed on the same schedule as the architecture

Decompose the architecture and keep centralised change control and you have made things strictly worse. A monolith with a weekly CAB is a coherent system with slow releases. Forty services with a weekly CAB is forty times the coordination surface at the same cadence.

Four changes are non-negotiable, and each has an owner outside engineering, which is why they take longer than the code.

Fund teams, not projects. Project funding creates temporary teams, and temporary teams cannot own anything long enough for Conway’s Law to work in your favour. A team that dissolves at go-live leaves a service with no owner, and unowned services are how a distributed monolith congeals. Move to persistent capability teams with an annual envelope. This is a finance change owned by the CFO’s office and your longest lead-time item. Start it first.

Give internal platforms real product ownership. A named owner, a roadmap, published service levels, adoption as the measure.

Move on-call to the team that writes the code. The sharpest intervention available and the most resisted. When the team that ships a service is woken by it, design quality changes within a quarter without any architectural governance, and ownership disputes settle: the pager does not accept ambiguity.

Dissolve the CAB into automated policy and progressive delivery. The CAB answers a legitimate question: is this change safe? Replace the mechanism, not the question. Encode what it checks into the pipeline: test gates, dependency and security scanning, policy-as-code, change metadata captured for audit. Then replace human approval with canary releases, feature flags and automated rollback on error-budget breach. Start with a standard-change category for low-risk changes, narrow the CAB to novel ones, then let it wither.

A 90-day organisational readiness plan, before the first service is extracted

Run this before extraction one, not alongside it. Every item has an owner and an exit criterion, because plans without those are just intentions.

1. Days 1–10: Map the real communication structure. Owner: modernization lead. Not the org chart: who talks to whom, which changes need which approvals. Exit: a one-page map of every mandatory cross-team dependency, with wait times.
2. Days 1–15: Build the knowledge risk register. Owner: engineering lead with HR. Every critical subsystem, named individuals, years to retirement, bus factor. Exit: board-reviewed, every bus factor of one mitigated.
3. Days 10–30: Resequence the roadmap against knowledge availability. Owner: chief architect. Exit: nothing is scheduled later than the projected departure of its last knowledgeable person, or the exception is accepted in writing.
4. Days 15–35: Approve the retention and phased-retirement package. Owner: CIO with HR and finance. Exit: budget approved, offers made, acceptance above 70%. If lower, find out why.
5. Days 20–45: Design the team topology. Owner: modernization lead with architecture. Exit: a document naming every team, what it owns, its interaction modes and, for enabling teams, dissolution criteria.
6. Days 30–60: Stand up the platform team with a product owner. Owner: platform lead. Exit: a new service can be provisioned with pipeline, environment and observability defaults through self-service in under a day.
7. Days 35–60: Staff mixed teams and start rotations. Owner: engineering managers. Exit: no team is defined by technology stack, no team name contains “legacy”, first rotations scheduled with named participants.
8. Days 40–70: Negotiate the funding model change. Owner: CIO with CFO. Exit: at least three capability teams funded persistently with an annual envelope next fiscal year. Do not wait for full conversion.
9. Days 45–75: Agree the CAB wind-down path. Owner: head of change management with the CAB chair. Exit: a standard-change category covering most deployments, agreed with internal audit.
10. Days 60–90: Move on-call for two pilot services, then publish baselines. Owners: head of operations, then modernization lead. Exit: owning teams hold the pager for 30 days, and independent deployability, lead time and change failure rate reach a board dashboard.

Ninety days looks slow when a board is expecting extractions. It is faster than extracting forty services into an organisation that reassembles them.

Frequently Asked Questions

Do we really have to reorganise before extracting the first service?

Not everything, but the parts that set team boundaries and ownership do. Once a team has shipped a service the interfaces are set, and changing that later means rewriting working code and taking something away from a team that has it. Reorganising after the fact is more disruptive and less effective. A reasonable minimum before extraction one: capability teams defined and staffed, a platform team with self-service provisioning, and knowledge-risk resequencing done. The funding model and CAB changes can run in parallel, since they have longer lead times and different owners.

What if our CAB is a regulatory requirement?

It almost certainly is not, in that form. DORA, SOX and PCI DSS 4.0 require demonstrable, auditable change control with segregation of duties, not a weekly committee. Automated pipeline gates with immutable evidence usually satisfy auditors better than meeting minutes, because the record is complete and tamper-evident rather than a summary written afterwards. Bring internal audit in as a design partner early rather than presenting a finished proposal, start with a pre-approved standard-change category, prove the evidence trail over a quarter, then extend.

How do we keep legacy specialists engaged when the exciting work is elsewhere?

Structurally, by removing the boundary that creates the status difference: mixed teams owning a capability across both stacks, rotations in both directions, and legacy work explicitly on the promotion criteria. Then check the last two promotion rounds to see whether the change was real. The strongest individual lever is reverse mentoring: a specialist learning containers, CI and cloud runtimes while teaching the domain has a future here, and people who can see a future stay. Bonuses alone do not fix a dead end.

We already extracted twenty services and our checklist score is 16. What now?

Stop extracting. More services will increase coordination cost faster than they deliver autonomy. Spend two quarters on three things: find the shared coupling point, usually a database schema or a centrally versioned domain model, and break it; fix ownership so every service has exactly one team carrying its pager; and remove the deployment gate, whether that is the CAB, the shared integration environment or the release train. Then re-run the checklist and resume extraction once the score is below 10. This feels like losing six months, and it is cheaper than discovering the same thing at service sixty.

The Bottom Line

The architecture diagram is a hypothesis about what your organisation can produce. The org chart, the funding model, the approval gates and the reporting lines are the actual specification, already being executed.

So the most consequential decisions in your programme are not architectural. Who owns what. Who carries the pager. Whether teams or projects get funded. Whether the person who understands the claims batch engine is still here in eighteen months.

Two of those are urgent in a way the others are not: the knowledge deadline is dated whether anyone has written it down or not, and the funding model change has a lead time measured in fiscal years. Start both this quarter. Skip the organisational work and Conway’s Law will deliver a faithful copy of the organisation you have, distributed across forty services, with the people who understood the original system gone.

If your programme has a target-state diagram but the org chart still has a database team, a separate QA function and a Thursday CAB, that gap is worth measuring before the next service is extracted. Modernize Software runs a two-week organisational readiness assessment that scores your independent deployability, maps your real communication structure against the target architecture, and builds the knowledge-risk register with dated departure horizons: the resequenced roadmap most programmes only write after losing someone.