Every so often a problem lands on my desk dressed as an architecture problem. The integration keeps breaking. The service boundaries are in the wrong place. Two systems disagree about the same customer. And often enough, when you pull the thread, the technical symptom unravels into something far less tractable: two teams that never agreed what a “policy” actually is, a decision nobody remembers making, a corner of the domain that exactly one person understood — and they left in March.
The uncomfortable conclusion I’ve come round to is that most architecture problems are people problems wearing a technical disguise. It’s uncomfortable because people problems don’t have a merge button.
The real bottleneck is shared context
We talk about architecture as though the hard part is the design — the boxes, the lines, the choice between a queue and a synchronous call. But the boxes are rarely where things come unstuck. What sinks a system is how much of the why is genuinely shared across the people building it.
You can see it in the questions that never get asked. A developer makes a locally sensible choice — a nullable field here, a “temporary” fallback there — because they don’t hold the context that would have told them it mattered. Nobody is negligent. The information simply wasn’t in the room. Multiply that by a hundred small decisions and you don’t get a clean architecture with a few bugs; you get a system whose shape nobody intended and nobody can now explain.
This is why “just document it” so rarely fixes anything. A wiki page is context that has been frozen and filed away from the moment of decision. The context you actually need is live — it’s the difference between a team that can finish each other’s sentences about the domain and one that can’t. That shared understanding is the scarce resource. Everything else is comparatively cheap.
It’s also why I’ve argued that you can’t draw a boundary the business hasn’t decided. When ownership of a process is smeared across three people who each hold a fraction of it, the fuzziness in your model isn’t a modelling failure — it’s the org’s indecision showing through. You can draw the cleanest boxes in the world; if the people behind them haven’t agreed who owns what, the diagram is fiction.
Conway’s Law cuts both ways
If you’ve read my piece on Conway’s Law in practice, you’ll know the shape of this argument: organisations ship their communication structure. Two teams that don’t talk build two systems that integrate badly, because the integration is a conversation that never happened.
The half people miss is that this runs in reverse, and that’s the useful half. If your system’s shape is really a cast of your org’s shape, then you cannot fix the system by redrawing the diagram. You have to change the org — who talks to whom, who owns what, where the seams between teams fall. I’ve watched well-intentioned re-architectures fail precisely here: the new design assumed a collaboration between two groups that, in reality, escalated to a director every time they needed to agree on anything. The picture was clean. The people were unchanged. The old shape grew straight back.
A shared language is shared context you can keep
The most durable tool I know for this isn’t a tool at all — it’s language. Eric Evans made the case years ago for a ubiquitous language: a single vocabulary, shared by developers and domain experts alike, that shows up unchanged in conversation, in the whiteboard sketch, and in the code. I used to treat that as a tidy naming convention. I now think it’s the single highest-leverage thing a team can invest in.
A shared word is shared context made durable. When “renewal” means exactly one thing to the underwriter, the developer, and the class named Renewal, an entire category of expensive misunderstanding simply stops happening. When it means three different things, no amount of clean layering will save you — you’ve built a system that faithfully encodes a disagreement. This is really the same argument I made about bounded contexts and aggregates: the seams in your software should fall where the language changes, because that’s where the people actually change.
The tension: autonomy versus alignment
None of this is a plea to lock everyone in a room until they agree. Shared context has a cost, and like most things in architecture it’s something you optimise, not maximise. Total alignment — every decision run past everyone — is just a committee with extra steps, and it’s death to the pace that made small teams worth having in the first place. Total autonomy, where every team invents its own vocabulary and its own version of the truth, gives you speed now and an integration bill later.
The real decision, the one worth being deliberate about, is how much context to share and where. Some boundaries deserve heavy investment in a common understanding because getting them wrong is expensive and hard to unpick. Others can be left loosely coupled and blissfully ignorant of each other, and should be. Knowing which is which is most of the job.
The people are the lever
I’ve argued before that the barriers to any real transformation are rarely technical, and that the honest deliverable of an architect isn’t a diagram but a team that shares an understanding. This post is the blunt version of both. The people are the constraint. That sounds like a complaint, and for a long time I treated it as one — as if the work would be so much easier without all the humans in the way.
It’s the wrong frame. The same people who are the constraint are the only lever that actually moves it. You do not buy your way out of a shared-context problem with a better message broker or a stricter linter. You close the gap by investing in the understanding itself: pairing across team lines, writing decisions down at the moment you make them and reading them back, insisting on one word for one thing, and putting the people who hold the context in the same conversations as the people who need it.
The caveat, so this doesn’t read as naïve: this is slow, it’s unglamorous, and it never finishes. Context decays as people join and leave; the language drifts if nobody tends it. But it’s the work with the highest return I know of in this job — because when you get it right, half the architecture problems you were bracing for never turn up at all.