Quick Navigation
- Start here — Conway's Law
- Centralised vs federated
- Platform teams
- Product operating models
- Team topologies
- Governance in federated models
- Choosing an operating model
- Inverting Conway's Law
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
The architecture of the systems you build will mirror the communication structure of the teams that build them — whether you design it that way or not. This is Conway's Law, and it's not a suggestion. It's a description of reality. I've seen organisations design beautiful microservice architectures with layered teams — and wonder why they ended up with a distributed monolith. The system mirrored the team.
The operating model defines how technology teams are structured, governed, and organised to deliver — and the architecture of the organisation shapes the architecture of its systems, whether intentionally or not.
If you want a unified platform, you need a team that communicates as a unified platform. If you want independent services, you need teams that communicate independently. If you don't design the organisation, the organisation will design the architecture — and you may not like the result.
Keep it in mind.
1. Conway's Law — How team structure becomes system structure
Most architects design systems without considering the teams that will build them. But the system will end up reflecting the team structure anyway — because teams can only build what they can communicate about.
Conway's Law states: "Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations." In practice:
flowchart TD
ORG["👥 Organisation Structure"] --> COMM["💬 Communication Patterns\nWho talks to whom"]
COMM --> SYSTEM["🏗️ System Architecture\nMirrors communication\nwhether designed or not"]
WANT["🎯 Desired Architecture"] --> DESIGN_ORG["👥 Design Organisation\nThat produces it"]
DESIGN_ORG --> COMM
COMM --> SYSTEM
Examples of Conway's Law in action:
| Organisation structure | System architecture it produces |
|---|---|
| One large team | One large monolith |
| 3 teams with separate managers | 3 services with minimal integration |
| Frontend team + backend team | Frontend/backend split with API boundary |
| Feature teams that own end-to-end | Independently deployable services |
The inverse Conway manoeuvre: instead of accepting that the system mirrors the organisation, design the organisation to produce the system you want.
Desired system: independently deployable microservices. Required team structure: small, autonomous teams that own services end-to-end.
Desired system: unified data platform. Required team structure: one team that owns the platform, consuming teams that use it.
Desired system: event-driven integration. Required team structure: teams that own events, not teams that own databases.
Conway's Law = the system will mirror the team — design the team to design the system.
Try it yourself — The mirror test
Look at your current system architecture. Now look at your team structure.
| System component | Owning team | Do they match? |
|---|---|---|
| e.g. Frontend app | Frontend team | Yes — but creates frontend/backend split |
If your system has boundaries you didn't design, Conway's Law designed them for you.
2. Centralised vs federated — The spectrum of operating model choices
There's no single right operating model. Centralised works for small organisations but creates bottlenecks at scale. Federated works for large organisations but risks fragmentation.
The operating model sits on a spectrum from fully centralised to fully federated:
flowchart LR
CENT["🏢 Centralised\nOne team decides all\nConsistent but slow"] --> HYBRID["🔀 Hybrid\nCentral for cross-cutting\nFederated for domains"]
HYBRID --> FED["🌐 Federated\nTeams decide locally\nFast but fragmented"]
CENT --> BEST_C["Best for: <5 teams\nSingle domain\nEarly stage"]
HYBRID --> BEST_H["Best for: most orgs\nScales with size"]
FED --> BEST_F["Best for: >20 teams\nMature domains\nStrong culture"]
Model comparison:
| Dimension | Centralised | Hybrid | Federated |
|---|---|---|---|
| Consistency | High | High for standards | Low — varies by domain |
| Speed | Slow — bottleneck | Balanced | Fast — parallel |
| Autonomy | Low | Moderate | High |
| Scalability | Poor at scale | Good | Good |
| Risk | Single point of failure | Balanced | Fragmentation |
The hybrid model in detail: Cross-cutting standards owned by central body — consistency across domains. Platform owned by platform team — shared capability, not central control. Domain architecture owned by domain teams — autonomy within guardrails. Implementation owned by stream teams — full ownership of delivery.
Transitioning from centralised to federated: Centralised — everything through one body. Delegate — push decisions to domains. Platform — central team builds shared foundation. Federated — domains own decisions within guardrails.
Centralise the cross-cutting, federate the domain-specific — hybrid works for most organisations.
Try it yourself — The model fit
Which model fits your organisation right now?
| Factor | Your situation | Points toward |
|---|---|---|
| Size | e.g. 15 teams | Hybrid |
| Maturity | ||
| Domain clarity | ||
| Culture | ||
| Goal |
If you're trying to run centralised with 15 teams, you have a bottleneck. If you're running federated with 3 teams, you have fragmentation.
3. The platform team model — Building internal platforms for stream-aligned teams
As organisations scale, every team rebuilding the same foundation — CI/CD, observability, deployment, authentication — becomes wasteful. But centralising everything creates a bottleneck. Platform teams solve this: they build the shared foundation that teams consume.
Platform teams are a structural solution to shared capability without central control:
flowchart TD
subgraph STREAM["🎯 Stream-Aligned Teams"]
T1["Team 1"]
T2["Team 2"]
T3["Team 3"]
end
subgraph PLATFORM["🏗️ Platform Team"]
CI["CI/CD"]
OBS["Observability"]
DEPLOY["Deployment"]
AUTH["Authentication"]
end
T1 -->|"Consumes"| PLATFORM
T2 -->|"Consumes"| PLATFORM
T3 -->|"Consumes"| PLATFORM
PLATFORM -->|"Provides"| T1
PLATFORM -->|"Provides"| T2
PLATFORM -->|"Provides"| T3
Platform team principles: Product mindset — internal teams are customers; platform is the product. Self-service — teams provision and configure without asking permission. Opinionated defaults — sensible defaults that teams adopt without deciding. Clear boundaries — platform provides the foundation; teams own the application.
Platform team responsibilities: CI/CD — pipeline templates, deployment automation. They don't write application code. Observability — logging, metrics, tracing infrastructure. They don't monitor application-specific metrics. Deployment — Kubernetes clusters, environments. They don't deploy applications. Security — IAM, encryption, secrets management. They don't write application-level security logic. Developer experience — templates, documentation, golden paths. They don't build features.
Platform success metrics: Adoption rate — % of teams using the platform. Target: >80%. Self-service rate — % of requests handled without platform team. Target: >90%. Time to deploy — how fast teams can deploy on the platform. Target: <1 hour. **Developer satisfaction** — do teams find the platform helpful? Target: >70% positive.
Platform teams = shared capability without central control — teams consume, platform provides.
Try it yourself — The platform check
Does your organisation have a platform team?
| Question | Your answer |
|---|---|
| What shared capabilities do teams rebuild? | |
| Could a platform team provide these? | |
| Would teams self-serve or wait for permission? |
If teams are rebuilding the same foundation, you need a platform team. If they're waiting for permission, you need a self-service platform.
4. Product operating models — Organising around outcomes, not projects
Project-based models fund work for a fixed duration, then disband the team. The result is: no ownership, no continuity, and systems that nobody maintains. Product-based models fund teams indefinitely to own and evolve a product.
The shift from project to product changes everything — funding, measurement, ownership, and architecture:
flowchart TD
PROJECT["📋 Project Model\nFixed duration\nFunded temporarily\nNo long-term ownership"] --> PROBLEMS["Problems:\nNo ownership\nNo continuity\nLegacy accumulates"]
PRODUCT["🎯 Product Model\nOngoing ownership\nFunded continuously\nOutcome-focused"] --> BENEFITS["Benefits:\nClear ownership\nContinuous improvement\nArchitecture evolves"]
Project vs product:
| Dimension | Project model | Product model |
|---|---|---|
| Funding | Temporary — project budget | Continuous — team budget |
| Ownership | Ends when project ends | Ongoing — team owns indefinitely |
| Measurement | On time, on budget | Outcomes — revenue, adoption, satisfaction |
| Architecture | Build to spec, then hand off | Evolve continuously |
| Team | Formed and disbanded | Stable, long-lived |
The product team structure: Product manager — what to build: outcomes and priorities. Tech lead — how to build: architecture and quality. Engineers — build and evolve: implementation and operations. Designer — user experience: usability and accessibility.
Funding the product model: Instead of "£500K project to build feature X", fund as "£100K/month team that owns product Y and delivers outcomes." Outcomes measured: customer adoption, revenue impact, operational health. Not measured: lines of code, features delivered, project milestones.
Product models create ownership and continuity — project models create legacy systems.
Try it yourself — The project vs product test
How are your teams funded?
| Team | Funding model | Ownership after delivery | Who maintains it? |
|---|---|---|---|
If the answer to the last column is "someone else" or "nobody," you're running a project model.
5. Team topologies — The four team types and their interaction modes
Team Topologies (Skelton & Pais) provides a framework for designing team structures that produce the architecture you want. Four team types, three interaction modes — a practical vocabulary for organisational design.
The four team types:
flowchart TD
TOPO["👥 Team Topologies"] --> STREAM["🎯 Stream-Aligned\nOwn a business domain\nEnd-to-end delivery"]
TOPO --> PLATFORM_T["🏗️ Platform\nProvide shared foundation\nSelf-service"]
TOPO --> ENABLING["🔧 Enabling\nHelp other teams\nadopt new capabilities"]
TOPO --> COMP["⚙️ Complicated Subsystem\nOwn complex, specialist\ncomponents"]
STREAM --> INTERACT["🔗 Interaction Modes\nCollaboration · X-as-a-Service\nFacilitating"]
PLATFORM_T --> INTERACT
ENABLING --> INTERACT
COMP --> INTERACT
The four team types:
| Team type | What they do | Example |
|---|---|---|
| Stream-aligned | Own a business domain end-to-end | Payments team, Onboarding team |
| Platform | Provide shared foundation | Platform team, Data platform team |
| Enabling | Help other teams adopt new capabilities | DevOps enablement, Security champions |
| Complicated subsystem | Own complex, specialist components | Search engine, ML pipeline |
The three interaction modes:
| Mode | What it means | When to use |
|---|---|---|
| Collaboration | Teams work together closely | Discovering new patterns |
| X-as-a-Service | One team provides, others consume | Stable, well-defined capabilities |
| Facilitating | Enabling team helps others | Capability adoption |
Applying Team Topologies: Identify streams — what business domains exist? Each gets a stream-aligned team. Identify platform needs — what is shared across streams? Platform team provides it. Identify enabling needs — what capabilities need adoption help? Enabling team facilitates. Identify complex subsystems — what is too complex for a stream team? Complicated subsystem team owns it. Define interaction modes — how do teams interact? Collaboration, service, or facilitation. Limit team cognitive load — each team must be able to understand their scope.
Cognitive load — the constraint: Intrinsic — the hard part of the domain itself. This is what the team should focus on. Extraneous — unnecessary complexity — bad tooling, unclear processes. Remove this — it wastes capacity. Germane — learning and improvement. Protect time for this.
Four team types + three interaction modes = a vocabulary for organisational design.
Try it yourself — The topology map
What team types exist in your organisation?
| Team | Type | Interaction mode with others | Cognitive load manageable? |
|---|---|---|---|
If you can't classify a team, your topology isn't designed — it's accidental.
6. Governance in federated models — Maintaining coherence without central control
Federated models give teams autonomy — but without governance, autonomy becomes fragmentation. Every team chooses different technologies, different patterns, different standards. The result is an incoherent landscape.
Federated governance uses guardrails, not gates:
flowchart TD
FED_G["🌐 Federated Model"] --> AUTONOMY["🎯 Team Autonomy\nTeams decide locally"]
AUTONOMY --> RISK["⚠️ Risk\nFragmentation\nInconsistency"]
RISK --> GUARDRAILS["🛡️ Guardrails\nNot gates\nAutomated enforcement"]
GUARDRAILS --> COHERENCE["✅ Coherence\nAutonomy within\nboundaries"]
The federated governance toolkit:
| Tool | What it does | Example |
|---|---|---|
| Guardrails | Automated constraints teams cannot violate | Encryption required, APIs versioned |
| Defaults | Sensible choices teams adopt without deciding | PostgreSQL for relational, Kafka for events |
| Fitness functions | Automated compliance checks in CI/CD | API spec compliance, security scan |
| Platforms | Standards implemented as self-service | API gateway enforces auth, versioning |
| Guilds | Cross-team knowledge sharing | Architecture guild, security guild |
The coherence mechanisms: Architecture principles — all teams, interpret per context. Technology standards — cross-cutting, exception required. Guardrails — non-negotiable, automated — block if violated. Reference architectures — common problems, teams adapt from reference. Guilds — knowledge, voluntary — influence through value.
Federated governance = guardrails, not gates — automate compliance, don't create bottlenecks.
Try it yourself — The guardrail check
What governance mechanisms do you have in place?
| Mechanism | Gate or guardrail? | Automated? |
|---|---|---|
| e.g. Architecture review board | Gate | No |
If most of your mechanisms are gates, you're creating bottlenecks. Convert them to guardrails.
7. Choosing an operating model — Matching structure to context, not copying what worked elsewhere
Organisations often copy another company's operating model — "we should be like Spotify" or "we should be like Amazon." But operating models are context-dependent. What works at 10,000 people may fail at 200.
The right operating model depends on three factors:
flowchart TD
CHOICE["🧭 Operating Model Choice"] --> SIZE["📏 Size\nHow many teams?"]
CHOICE --> MATURITY["📊 Maturity\nHow experienced are teams?"]
CHOICE --> GOALS["🎯 Goals\nConsistency or speed?"]
SIZE --> MODEL["🔀 Model Selection"]
MATURITY --> MODEL
GOALS --> MODEL
MODEL --> RESULT["✅ Matched Model\nRight for your context"]
The selection guide:
| Factor | Points toward centralised | Points toward federated |
|---|---|---|
| Size | <5 teams | >20 teams |
| Maturity | Junior teams, early career | Senior teams, experienced |
| Domain clarity | Domains not yet discovered | Domains well understood |
| Culture | Hierarchical, risk-averse | Autonomous, experiment-driven |
| Goal | Consistency and control | Speed and ownership |
The maturity progression: Start — <5 teams, centralised. Grow — 5-15 teams, hybrid. Scale — 15-30 teams, federated with platform. Mature — 30+ teams, fully federated.
Match the model to your context — size, maturity, and goals determine the right operating model.
Try it yourself — The context check
Where does your organisation sit on each factor?
| Factor | Your situation | Model it points to |
|---|---|---|
| Size | ||
| Maturity | ||
| Domain clarity | ||
| Culture | ||
| Goal |
If the answers point in different directions, you're in transition. Design for where you're going, not where you are.
8. Inverting Conway's Law — Using team boundary design as a proactive architecture tool
Most organisations accept Conway's Law passively — the system ends up however the teams are structured. Inverting Conway's Law means designing team boundaries proactively to produce the architecture you want.
Instead of designing the system and hoping teams adapt, design the teams to produce the system:
flowchart TD
DESIRED["🎯 Desired Architecture\nIndependently deployable services\nEvent-driven integration"] --> TEAM_DESIGN["👥 Team Design\nSmall autonomous teams\nOwn services end-to-end\nTeams own events"]
TEAM_DESIGN --> PRODUCED["🏗️ Produced Architecture\nIndependently deployable services\nEvent-driven integration"]
PASSIVE["😐 Passive Acceptance\nWhatever teams exist\nproduce whatever system"] --> RANDOM["🎲 Random Architecture\nNobody designed"]
The inversion exercise:
| Desired architecture | Required team structure |
|---|---|
| Microservices | Small, autonomous teams owning services |
| Event-driven | Teams that own events, not databases |
| Platform-based | Platform team + consuming teams |
| Data mesh | Domain teams owning data products |
| API-first | Teams that own APIs as contracts |
The communication structure heatmap — map communication frequency between teams to understand what system coupling it produces:
Platform Payments Orders Analytics Auth
Platform — Daily Daily Weekly Daily
Payments Daily — Daily Monthly Daily
Orders Daily Daily — Monthly Daily
Analytics Weekly Monthly Monthly — Monthly
Auth Daily Daily Daily Monthly —
Interpretation: High communication = tight coupling (consider merging or abstracting). Low communication = loose coupling (good — or potential integration gap). Platform communicates with everyone = correct — it's the shared foundation.
The proactive design process: Define desired architecture — what system structure do you want? Map required communication — who needs to talk to whom to produce it? Design team boundaries — where do teams end? What do they own? Validate with heatmap — does the communication pattern match the desired coupling? Restructure — move people, change boundaries, establish new teams.
Invert Conway's Law — design the team boundaries that produce the architecture you want.
Try it yourself — The inversion exercise
What architecture do you want? What team structure would produce it?
| Desired architecture | Current team structure | Required team structure | Gap |
|---|---|---|---|
If the current and required don't match, you need to restructure.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
LAW["🔗 Conway's Law\nTeam structure =\nsystem structure"] --> CHOOSE["🧭 Choose Model\nCentralised · Hybrid\nFederated"]
CHOOSE --> TOPO["👥 Team Topologies\nStream · Platform\nEnabling · Subsystem"]
TOPO --> GOVERN_F["🏛️ Govern\nGuardrails not gates\nAutomated compliance"]
GOVERN_F --> INVERT["🔄 Invert\nDesign teams to\nproduce desired architecture"]
INVERT --> VALUE["✅ Architecture\nproduced by design\nnot by accident"]
The foundation:
Conway's Law isn't optional. The system will mirror the team structure whether you design it or not. Design the organisation to produce the architecture you want. Centralise the cross-cutting, federate the domain-specific. Hybrid works for most organisations. Platform teams solve shared capability without central control. Team Topologies gives you a vocabulary — four team types (stream-aligned, platform, enabling, complicated subsystem) and three interaction modes (collaboration, X-as-a-service, facilitating). Product models create ownership and continuity — project models create legacy systems. Design the organisation first. The architecture follows.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Conway's Law | System mirrors team structure | Design teams to produce desired architecture |
| Centralised | One body decides all | Good for small orgs |
| Federated | Teams decide locally | Good for large orgs |
| Hybrid | Central for cross-cutting, federated for domains | Best for most |
| Platform teams | Shared capability without central control | Self-service, opinionated defaults |
| Product model | Outcomes, not projects | Fund teams continuously |
| Team Topologies | Four types + three modes | Vocabulary for organisational design |
| Governance in federated | Guardrails, not gates | Automate compliance |
| Inverse Conway | Design teams proactively | Communication heatmap |
How to know if this landed
You'll know this has landed when someone stops asking "what architecture should we build?" and starts asking "what team structure would produce the architecture we want?" Can articulate how team structure affects system architecture (Conway's Law). Has chosen an operating model (centralised, hybrid, federated) matching context. Team topology is designed — not accidental. Platform teams exist for shared capabilities — teams self-serve. Product teams own outcomes, not project milestones. Federated governance uses guardrails, not gates — automated enforcement. And communication heatmap exists — coupling is understood and designed.
What changes when the mental model clicks
I've run this session with teams where they were organised by technology layer: frontend, backend, data, infrastructure. System architecture mirrored this: monolithic frontend, monolithic backend, shared database. Every feature required coordination across 3-4 teams. The gap at the start is usually not about understanding operating models — it's about not realising that the team structure is the architecture.
What changes after this session:
Teams stop designing systems and start designing the organisations that produce them. The Conway's Law assessment — "map your current team structure to your current architecture" — is always the moment things click. People stop treating operating models as HR concerns and start treating them as architecture concerns. Their results get better. They stop fighting their own system when the real problem was that their team structure produced exactly the architecture they got.
The team topology exercise tends to immediately change how teams think about their structure. They start classifying teams — stream-aligned, platform, enabling, complicated subsystem. Their clarity goes up. They stop creating accidental team types when the real problem was that they didn't have a vocabulary.
Book a Workshop
Ready to design the organisation that produces the architecture you want?
or
1-day workshop includes Conway's Law assessment — map your current team structure to your current architecture, operating model selection — choose the right model for your context, team topology design — define team types and interaction modes, platform team scoping — what should the platform provide, communication heatmap creation — map actual coupling between teams, inverse Conway exercise — design team boundaries to produce desired architecture, and operating model design canvas + team topology guide + Conway's Law application worksheet + Communication Structure Heatmap.