TL;DR
Architecture isn’t just about systems — it’s about how people work inside them. The way we draw boundaries, share platforms, and split responsibilities quietly shapes how fast teams move, how safe they feel making changes, and where things get stuck. If your team feels slow or stuck, it might not be the code. It might be the structure around it.
Introduction: Why Architecture Is More Than Boxes and Arrows
Architecture’s often treated like plumbing — ignored when it works, cursed when it leaks.
But it does more than route data or enforce boundaries. It shapes how people think, how teams interact, and how decisions unfold. A good system creates freedom. A brittle one breeds hesitation.
Architecture is cultural. Psychological. Organisational. Not something you draw — something you live inside.
“Architecture is not just structure. It’s the set of design decisions that are hard to change.”
— Ruth Malan
The Blueprint Behind the Bottleneck
Most bottlenecks aren’t technical. They’re architectural.
Design’s a bit like a floorplan. If the hallway’s too narrow, it doesn’t matter how quickly people walk — they’ll still end up shoulder-to-shoulder. Same goes for software.
“Every system is perfectly designed to produce the results it gets.”
— W. Edwards Deming
flowchart TB
subgraph Team A
A1[Feature A]
end
subgraph Team B
B1[Feature B]
end
subgraph Team C
C1[Feature C]
end
A1 --> X[Shared Blocker]
B1 --> X
C1 --> X
X --> D[Deploy Step]
classDef team fill:#eef,stroke:#336,stroke-width:1px;
class A1,B1,C1 team
It probably made sense when things were small. But now? It’s the thing everyone queues behind.
You don’t see it in the architecture diagram. You feel it — in stuck PRs, duct-taped workarounds, and simple changes that somehow take all week.
The code’s not the issue. It’s the layout that’s working against you.
Decomposition as Destiny
Cutting up a system isn’t just technical — it’s political. You’re deciding who gets to move fast, who has to wait, and who needs to check in before touching anything.
And that mess shows up in all sorts of places. Six teams wrangling the same “cross-cutting” change. An interface everyone touches but no one owns. That’s not a breakdown in communication — that’s a structural trust issue.
A clean split keeps things moving. A messy one? That’s how you end up stuck in meetings, rehashing decisions that no one really owns.
flowchart TD
subgraph Teams - ish
T1[👩💻 Team A]
T2[👨💻 Team B]
T3[🧑💻 Team C]
end
subgraph Shared Core
X1[🔧 Shared Utils]
X2[🧱 God Class]
X3[🌀 WTF Module]
end
subgraph Features
F1[❗ Login & Signup]
F2[❗ Checkout]
F3[❗ Alerts & Receipts]
end
X1 --> F1
X2 --> F1
X2 --> F2
X3 --> F2
X1 --> F3
X3 --> F3
F1 --- T1
F2 --- T2
F3 --- T3
classDef bad fill:#fdecea,stroke:#a94442,stroke-width:1px;
classDef team fill:#fff3cd,stroke:#b8860b,stroke-dasharray: 4 4;
class X1,X2,X3,F1,F2,F3 bad
class T1,T2,T3 team
Interfaces don’t just shape the system — they shape the social contract. They quietly signal who’s trusted, how safe it is to make changes, and what kind of workarounds won’t get you in trouble.
When a two-week approval trail gets you a proper fix, but a dodgy patch sails through in an afternoon, people don’t pick the messy option out of laziness. They pick it because it works.
It’s not corner-cutting — it’s rational behaviour in a structure that rewards shortcuts.
So don’t just ask where the boundary should go.
Ask who never needs permission in the first place
Conway’s Law: From Observation to Operating Principle
Back in 1968, Mel Conway observed something simple but powerful: systems end up shaped by the way the people building them communicate.
You split teams by function — you get layers. You silo conversations — you ship silos. It’s not accidental. Software takes on the shape of the dialogue behind it.
What we ship isn’t just a reflection of design decisions — it’s a map of how we talked while making them.
%%{init: {"themeVariables": { "fontSize": "20px" }}}%%
flowchart LR
subgraph Organisation
FE[Frontend Team]
BE[Backend Team]
INF[Infra Team]
end
subgraph System Architecture
WEB[Web Layer]
LOGIC[Business Logic]
DEPLOY[Deployment Scripts]
end
FE <--> WEB
BE <--> LOGIC
INF <--> DEPLOY
classDef team fill:#eef,stroke:#336,stroke-width:1px;
classDef arch fill:#f9f9f9,stroke:#999,stroke-dasharray: 5 5;
class FE,BE,INF team
class WEB,LOGIC,DEPLOY arch
Conway’s Law is a lever.
Reverse Conway is about flipping that mirror: if you want modular systems, start with modular teams. Make movement easy. Design for fewer permissions. Most blockages aren’t in code — they’re in structure.
Team Topologies sticks because it puts a name to what we’ve all felt — some team setups give you space to move, others tie you in knots.
Boundaries as Enablers, Not Fences
Boundaries cop a bit of flak. They’re often seen as walls — ways to keep the chaos out.
But the good ones don’t shut people out. They make it easier to know what’s yours — and when to hand something off. Teams can stay focused, but still connect cleanly when they need to. Not a barricade — more like a clear edge you can meet at without tripping over each other.
When HelloFresh restructured around domain boundaries, it wasn’t about cleaner diagrams. It was about giving teams proper footing — a slice they could really own. And it worked.
Handoffs dropped off. The usual noise stopped getting in the way. People finally had space to focus on what mattered.
flowchart LR
subgraph Shared Contracts
SH_USER[🪪 User ID]
SH_PROD[🛍️ Product ID]
SH_CURR[💱 Currency]
end
subgraph Orders Domain
ORD_API[🧾 Orders API]
ORD_PAY[(💳 Payment DB)]
end
subgraph Inventory Domain
INV_API[📦 Inventory API]
INV_DB[(📊 Stock DB)]
end
subgraph Marketing Domain
MKT_CAM[🎯 Campaign Manager]
MKT_DIS[🏷️ Discount Engine]
end
SH_USER --> ORD_API
SH_PROD --> ORD_API
SH_PROD --> INV_API
SH_CURR --> MKT_DIS
classDef zone fill:#eef,stroke:#336,stroke-width:1px;
classDef contract fill:#f9f9f9,stroke:#aaa,stroke-dasharray: 4 4;
class SH_USER,SH_PROD,SH_CURR contract
class ORD_API,ORD_PAY,INV_API,INV_DB,MKT_CAM,MKT_DIS zone
Strong boundaries don’t create silos — they give teams something solid to stand on. They cut through the ambient swirl and point people in the right direction. Not rigid. Just reliable.
And when the edge is clear, teams don’t waste energy defending it — they just get on with the work. There’s still friction — it just shows up in places that sharpen, not stall.
Platforms, Power, and the Politics of Defaults
Not every constraint comes with flashing lights. Some are quieter — just enough pull in one direction, or enough friction the other way to make you think twice.
Internal platforms work like that. They don’t ban anything. They just make one route obvious — and leave the rest feeling a bit rough around the edges.
Give engineers a working stack and they’ll use it. Not because they’re told to, but because it’s solid. And when something breaks, there’s a Slack channel full of people who know what they’re doing.
What looks like convenience often becomes quiet influence — guiding decisions without anyone noticing.
%%{ init: { "themeVariables": { "fontSize": "20px" } } }%%
flowchart TD
TEAM["🧑💻 Team Needs Capability X"]
PLATFORM["🛠️ Internal Platform"]
TEAM --> PLATFORM
PLATFORM -->|✅ Works well, well-supported| AUTONOMY["🚀 Used it by choice"]
PLATFORM -->|⚠️ Required, hard to avoid| CONFORMITY["🔒 Used it because we had to"]
classDef soft fill:#e0f7e9,stroke:#3c763d;
classDef hard fill:#fdecea,stroke:#a94442;
class AUTONOMY soft
class CONFORMITY hard
People don’t always pick the ideal path. They pick the one that feels safe, makes sense in the moment, and doesn’t come back to bite them.
Defaults don’t have to be loud to be powerful. They steer decisions quietly — just by being the easiest thing to reach for.
And the best platforms? They don’t push. They just make the right thing easier than the wrong one.
When Systems — or People — Get Too Tightly Coupled
Coupling isn’t just in the code. It shows up in calendars, inboxes, and all those moments where people hesitate — not because they’re unclear, but because they’re waiting for a nod.
It starts with one helpful person. Someone who knows the system inside out. At first, they unblock things. Then they start orbiting every decision. Eventually, nothing moves without them.
You don’t see the system grind to a halt. It just gets quieter. Threads hang. Work doesn’t break — it lingers.
%%{ init: { "theme": "default", "themeVariables": { "fontSize": "20px" } } }%%
flowchart LR
subgraph Tightly Coupled
TCA[👩💻 Team A]
TCB[👨💻 Team B]
TCC[🧑💻 Team C]
TCD[👩🏽💻 Team D]
BOTTLENECK["🧠 The Go-To / Shared Module"]
TCA --> BOTTLENECK
TCB --> BOTTLENECK
TCC --> BOTTLENECK
TCD --> BOTTLENECK
BOTTLENECK --> DEPLOY1[🚧 Coordinated Release]
end
subgraph Breathable
BA[👩💻 Team A]
BB[👨💻 Team B]
BC[🧑💻 Team C]
BD[👩🏽💻 Team D]
DEPLOY2[🚀 Independent Deploys]
BA --> DEPLOY2
BB --> DEPLOY2
BC --> DEPLOY2
BD --> DEPLOY2
end
classDef tight fill:#fdecea,stroke:#a94442;
classDef clean fill:#e0f7e9,stroke:#3c763d;
class TCA,TCB,TCC,TCD,BOTTLENECK,DEPLOY1 tight
class BA,BB,BC,BD,DEPLOY2 clean
This isn’t something you fix with more process. It’s a design problem — and the fix starts by making sure no one becomes the team’s single point of certainty.
So build interfaces that carry context. Decisions that don’t need sign-off. A structure where trust flows across, not just down the chain.
When Architecture Breathes — or Doesn’t
Some systems feel off before you can explain why.
A merge lingers — not because the code is broken, but because no one feels safe clicking “approve.” A new hire spends weeks retracing decisions just to figure out what’s okay to touch.
It’s not chaos. It just doesn’t fit anymore. The choices that once felt sharp now cloud how people work — and slow things down without anyone noticing.
And then there are the systems that stay out of the way.
People find their rhythm. Ownership is obvious. Platforms do what they need to, then fade into the background. Instead of asking “Can I?”, teams start asking “What’s the smartest way through this?”
From the outside, it might look a bit loose. Inside, though — it works.
%%{ init: { "theme": "default", "themeVariables": { "fontSize": "18px" } } }%%
flowchart LR
%% Teams and Features
subgraph Team A
A1[Feature A1]
A2[Feature A2]
end
subgraph Team B
B1[Feature B1]
B2[Feature B2]
end
subgraph Team C
C1[Feature C1]
C2[Feature C2]
end
%% Shared Contract
SC[🔗 Shared Contract]
%% Deployed Outcomes
OA[🚀 Outcome A]
OB[🚀 Outcome B]
OC[🚀 Outcome C]
%% Connections
A2 --> SC
B1 --> SC
A1 --> OA
B2 --> OB
C1 --> OC
C2 --> OC
classDef team fill:#e0f7e9,stroke:#3c763d;
classDef shared fill:#f0f0f0,stroke:#999,stroke-dasharray: 5 5;
classDef outcome fill:#e6e6fa,stroke:#666;
class A1,A2,B1,B2,C1,C2 team
class SC shared
class OA,OB,OC outcome
From Machinery to Ecology: A Shift in Metaphor
For decades, we treated software systems like factories.
Inputs go in. Outputs come out. Stability was the goal — repeatable processes, predictable results. That mindset gave us pipelines, orchestrators, and staging environments.
It worked. Especially at scale. Though over time, it made things rigid — and people, too.
%%{ init: { "theme": "default", "themeVariables": { "fontSize": "20px" } } }%%
flowchart TD
arch_constraints[🧱 Architecture as Constraints]
tight_coupling[🔗 Tightly Coupled Components]
control_points[🧭 Centralised Decision Points]
uniformity[📏 Enforced Consistency]
output[📤 Predictable Output – Low Variation]
arch_constraints --> tight_coupling
arch_constraints --> control_points
tight_coupling --> uniformity
control_points --> uniformity
uniformity --> output
classDef machine fill:#f0f0f0,stroke:#999;
class arch_constraints,tight_coupling,control_points,uniformity,output machine
But systems don’t have to run like clockwork. They can grow — if you let them.
In a garden, you don’t control the outcome. You set the conditions. Feed the soil. Let in the light. Keep the structure strong enough to hold, but loose enough to flex.
That shift changes the question.
Not “How do we make people behave?”
But “What kind of setup helps the right behaviour emerge on its own?”
%%{ init: { "theme": "default", "themeVariables": { "fontSize": "20px" } } }%%
flowchart TD
soil[🌾 Healthy Soil – Context]
sun[☀️ Sunlight – Clarity]
water[💧 Feedback Loops]
beds[🪴 Modular Beds – Teams]
growth[🌻 Natural Growth – Flow]
soil --> beds
sun --> beds
water --> beds
beds --> growth
classDef machine fill:#f0f0f0,stroke:#999;
classDef garden fill:#e0f7e9,stroke:#3c763d;
class soil,sun,water,beds,growth garden
It starts slow, but finds its rhythm — adapting, flexing, and holding together when things get messy.
If architecture shapes behaviour, maybe it’s time we stopped drawing factories — and started designing ecosystems.
Conclusion: Designing for Fit, Not Just Function
The best architecture doesn’t draw attention to itself. It’s not about shiny diagrams or clever abstractions. It’s about how a team feels when they’re inside it.
Do they move freely, or do they pause? Are they guessing who to ask, or just getting on with it? Are decisions stalling, or flowing with the work?
When things line up, the system fades into the background. People just get on with it. There’s less back and forth. Less friction. More trust. And a bit more breathing room.
Ownership feels natural. Platforms help without needing a spotlight. Teams stop asking “Am I allowed?” and start asking “What makes sense here?”
Because in the end, we’re not just designing systems. We’re shaping the environment those systems live in — and the way people move through it every day.
And when we get that right, everything else gets a little bit easier.