Organizational Understanding: Why Capabilities Go Unused

Our project team 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. Nobody phoned their account manager instead, nobody escalated. 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.

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 our 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 is that the architect designs it and 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. You need both. 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 rather than 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.
• Assign ownership to someone with a name and the capacity to take it. 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.
• Watch for silence. 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. Working out how your organization actually operates is part of the design job, 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?