Organizational Understanding: Why Capabilities Go Unused

I built a self-service portal for SME customers once. Technically it was fine. It shipped, it worked, it had a genuinely large number of options behind it, and the majority of those options were never used. Not under-used. Never used.

The interesting part is why. The option set had been built around what the business wanted to offer, so it mirrored the internal product catalogue and, underneath that, the shape of the organization that sold those products. It answered an internal question, "what do we sell?", with admirable completeness. It never answered the external one, "what does a small business actually need to do today?" And here is the detail that still bothers me: the SMEs did not route around it. They did not phone their account manager instead, they did not escalate, they did not complain. There was simply no demand for those options in the first place, so nothing happened at all. The architecture faithfully reproduced the organization's view of itself, and that view did not match anybody's reality outside the building.

That is the failure mode I want to talk about, and it is a failure of organizational understanding rather than of engineering. It is also not Conway's Law. Conway's Law is about what the org chart does to your design before you build it, and I have written about that elsewhere. This is the other half, the part that happens after the deployment succeeds: a capability arrives, the way the organization works never adapts to receive it, and the capability quietly never materialises. Most architects treat organizational structure as background context. In practice it is more often the limiting factor on a transformation than the technology ever was.

The Extension Wing Nobody Walks Into

Picture an organization as a building that people have worked in for years. Every day they walk the same corridors, and over time those routes wear into the floor. They know which stairwell is quickest, which door sticks, whose desk to pass to get an answer without booking a meeting. Nobody planned those paths. They accumulated.

Now build a new wing onto it. Good foundations, better light, more space than the old rooms. Then look at it three months later. The doors are closed, the windows are dark, the heating was never switched on, and every worn path on the ground still curves back into the old structure. The old rooms are crowded. The new wing is cold and full of dust.

That is what an unadopted capability looks like from the inside. The technology is the wing, the operating model is the paths people walk, and pouring a foundation has never once redirected foot traffic. The architect's job includes the signage, the doorways, and the reasons anyone would take the new route.

The analogy breaks in one important place, and it breaks in the direction that matters. A building has no politics. Its old corridors do not have someone's headcount attached to them, they do not have an approval step that protects a manager's authority, and they do not have twenty years of muscle memory defending them. In a real organization the old route is often genuinely faster for the incentives people are actually judged on. So "just open the door" is never the fix, and any change plan that amounts to an announcement and a training video is a plan to leave the wing dark.

What Actually Blocks Adoption

Three things, in my experience, and none of them are technical.

Nobody owned it

Ownership was either never assigned or assigned to a team that had no capacity to take it. Both look identical on a slide. The second is worse, because it comes with a name attached and therefore looks resolved. A capability that belongs to everyone belongs to nobody, and a capability that belongs to a team already running at full load belongs to a backlog.

The approval chain never changed

This is the most quietly infuriating one. The technology removed a bottleneck the process still enforced. You automate a step, and the sign-off that existed to control that step stays exactly where it was, so the cycle time barely moves and everyone concludes the new thing did not work. The capability was real. The organization simply kept charging the old toll.

People were engaged too late

Too late means after the build, at rollout. The people who would have to change how they worked first saw the thing when it was finished and unchangeable, at which point the only two available responses are compliance and quiet non-adoption. Most organizations pick the second.

This is the mechanism that produced my portal. Nobody who could have said "an SME will never ask for this" was in the room while it was still a room where things could change. The build was correct throughout. The inputs were organizational, and they were wrong.

Organizational Understanding Is The Missing Input

All three failures share a root. They are visible only if you understand how the organization actually works rather than how it is drawn. The distinction is old. HBR named it in 1993 with "Informal Networks: The Company Behind the Chart", and it remains the standard reference for the gap between the reporting lines and the real ones. Your architecture will be adopted, or not, by the second organization.

There is a second thing hiding in adoption failure, and it is capacity. Every new capability adds something to somebody's plate, and if you have not worked out whose, you have designed a burden and labelled it an improvement. The second edition of Team Topologies, published in September 2025, puts cognitive load at the centre as the design constraint and extends the model up to whole-organization scale. That framing is useful here precisely because it forces the question "who now carries this?" before rollout rather than after.

Two Ways to Deliver the Same Capability

The difference between a capability that lands and one that gathers dust rarely shows up in the architecture diagram. It shows up in what was designed alongside it.

	Capability only	Capability plus operating model
Design inputs	Internal catalogue, existing structure	What the user needs to do that day
Affected people involved	At rollout	While the design can still change
Ownership	Implied, or a team at capacity	Named person, with capacity to accept it
Approval chain	Untouched	Redesigned alongside the automation
Definition of done	Deployed and available	In use, old route retired
Typical failure	Silent non-adoption	Visible friction, which is fixable

The last row is the one I would put on a wall. Silent non-adoption gives you nothing to work with, because nobody complains about a door they never opened. Visible friction is an argument you can have.

Who Owns The Organizational Change

My position: the architect designs it, someone else drives it.

Designing it means the operating model change is part of the deliverable. Which decisions move, which approvals disappear, which team picks up the new work and what they stop doing to make room, what the old route looks like once it is closed. Those are design questions with the same weight as a choice of data store, and they belong in the same document.

Driving it is a different job, and architects are usually the wrong people for it. It needs sustained presence in one part of the business, day after day, long after the interesting decisions are made.

The handover is where this usually falls apart, so be precise about the conditions. It works when there is a specific accountable person on the receiving end, a named individual with the authority and the capacity to change how their part of the organization works. And it works when the project team stays engaged, driving and facilitating, rather than declaring victory at go-live. Both conditions, together. Drop the first and the change has no owner. Drop the second and you have thrown a document over a wall and called it enablement.

Build The Paths, Not Just The Wing

A few things I would hold onto:

• A capability is not delivered when it is deployed. It is delivered when the old route is retired. Until then you have optionality, not value.
• Involve the people who must change how they work while the design can still change. After the build, you are not consulting them, you are informing them.
• Ownership needs a name and capacity. One without the other is decoration.
• Automate a step and remove the approval that guarded it, or accept that you paid for speed and kept the queue.
• Silence is the failure signal. Nobody escalates about a feature they never wanted.

The portal taught me that a system can be a perfectly accurate model of an organization and still be useless, because the organization is not the thing the customer is trying to interact with. Understanding how your organization actually works is design work with the same standing as any technical decision, and it belongs to us.

So, the capability your team shipped last quarter: who owns the change in how people work, and do they have the capacity to accept it? Which approval step should have disappeared when it went live, and is it still there? And most importantly, if nobody is using it, would you actually hear about it?