Every architecture decision I make comes with a second document nobody asked for. Not the system diagram. The org chart the system will eventually force into existence.
Most architecture reviews end after the first one. That is where I start asking uncomfortable questions.
The question nobody puts on the agenda
Before I sign off on any major architecture decision, I draw a second diagram. It maps not the system, but the organization the system assumes exists. it basically tracks human resentment. Who owns this boundary? Does that team exist today? What has to change in the reporting structure for this to work?
These questions are deeply unpopular. They pull the conversation out of the cozy, predictable territory of Kubernetes clusters and API contracts and into the radioactive mess of people, authority, and accountability. We are trained for the first kind of conversation.
Patricia Routhledge: Wonderful art of Hyacint Bucket
Most organizations are the equivalent of a Victorian household when it comes to the second: “We simply do not discuss such things at the dinner table of the Bouquet residence”.
(I ask anyway)
What the architecture is actually saying
Software architecture is not neutral. Every architectural decision implies something about how work should be organized. Who communicates with whom, where decisions need to be made, where things can be owned independently and where they cannot.
Mel Conway noticed this in 1967. You know the one. Organizations produce systems that mirror their communication structures. What gets less attention is the reverse:
Systems, once built, will pressure the organization toward the structure they require
Not immediately. Not obviously. Usually about umpteen months later, in the middle of a restructuring that nobody connects to the technical decision that caused it. Or the software will be minimally used and become stale.
The architecture does not wait for the org chart to catch up. It just makes the misalignment expensive until something gives.
The distance metric
When I draw the second diagram, I am trying to estimate and measure a gap. On one side: the org chart you have. On the other: the org chart the architecture requires. That gap is your implementation risk, and it is almost never on the architecture review agenda.
That gap is your real implementation risk. It’s the “hidden tax” on every sprint. A small gap is manageable with a few extra Slack channels and some shared empathy. A large gap means the system and the organization are going to go ten rounds in the ring.
Spoiler alert: the architecture usually loses, but it takes your quarterly roadmap down with it.
It is usually not the architecture
I am actually looking for these three things
Who owns the boundary? Every interface in the system is a negotiation in the organization. If two teams have to coordinate every time a feature crosses that line, and they don’t share a backlog, a manager, or an incentive, that interface will slow you down until the org catches up to the architecture. Or until the architecture gets simplified enough that it stops requiring coordination it cannot get.
Does that team exist? A platform architecture implies a platform team. A data mesh implies distributed data ownership with the skills and accountability to go with it. Designing the system without designing the team is not an architecture decision. It is half of one.
What has to change for this to work? This is the question that makes people uncomfortable. Sometimes the answer is “not much.” Sometimes the answer involves reporting lines, budget ownership, and conversations that go well outside the architecture review. Those conversations need to happen before the concrete is poured, not after it has set.
Chart worth drawing?
I am not arguing that the org chart should drive the architecture. That way lies Conway’s Law in its most destructive form. That would prpbably lead to systems that faithfully replicate every dysfunction of the organization that built them. I’m saying that both are design problems. If you treat them as separate, you’re just building a beautiful engine and realizing too late that you’ve installed it in a boat when you’re standing in the middle of a desert.
The second diagram isn’t extra work. It’s the sanity check that prevents your “innovative <insert agentic/AI keyword> transition” from becoming a three-year case study in why everyone hates the CTO.
If your architecture requires a better version of your company to succeed, you’d better start building that company at the same time you’re writing the code. Otherwise, you aren’t an architect. You’re just a very expensive dreamer with a Visio license.
Leave a Reply