The Organisation Chart is a Lie

Here is a thought experiment. Take your organisation's most complex delivery challenge last year — a regulatory programme, a product launch, a major incident. Now look at the org chart. How many of the people who actually solved it report to the same box?

Very few, I would wager.

The reality is that value in most organisations is not delivered down the hierarchy. It is delivered across it — through informal connections, trusted relationships, and ad hoc working arrangements that no one formally designed and no one formally manages. We call these collaboration networks, and for most organisations they are the invisible engine of delivery.

The problem is not that they exist. The problem is that we pretend they do not.

The Org Chart and the Operating Reality

Every organisation publishes an org chart. It defines reporting lines, accountability chains, and — in theory — who is responsible for what. It is a necessary management artefact.

But watch how a complex customer complaint actually gets resolved. Or how a regulatory deadline actually gets met. Or how a technology failure actually gets contained. You will see something the org chart does not capture:

• A risk analyst in one division calling a colleague in another because they trust each other's judgement.
• A product team pulling in a technology architect from a different reporting line because she is the only one who understands the legacy system.
• An operations manager and a finance partner solving a reconciliation issue informally before it ever reaches a committee.

These interactions are not outside the operating model. They are the operating model. They are just invisible to anyone looking at the org chart.

What Is a Collaboration Network?

In Business Architecture terms, a collaboration network is a structured — but often informal — arrangement where people, teams, or functions work together to achieve outcomes that no single unit can deliver alone.

They are not project teams, although projects often rely on them. They are not governance forums, although governance often depends on them. They are the webs of trust, knowledge, and co-ordination that sit underneath the formal structure.

They come in different forms:

• Virtual enterprises: temporary clusters that form around a specific problem — a regulatory response, a crisis, a time-limited opportunity — and dissolve when it is resolved.
• Extended working groups: more durable arrangements that link teams across divisions to deliver ongoing capabilities — think onboarding, claims handling, or risk reporting.
• Communities of practice: networks built around shared expertise rather than shared process, where knowledge moves laterally across the organisation.
• Business ecosystems: the broadest form — where internal teams, suppliers, regulators, and partners are all participants in delivering value.

What all of these have in common is that they cannot be read off a reporting structure. They must be mapped, understood, and actively supported.

Why This Matters: The Cost of Invisibility

When collaboration networks are invisible, several predictable failures follow.

Delivery depends on individuals, not design. When the person who "knows everyone" leaves, capability walks out with them. The network fractures not because the work changed, but because the connector did.

Governance misses where decisions actually happen. Committees make formal decisions. But the framing, the options, and the informal consensus are often shaped in the collaboration network long before the meeting. If you cannot see the network, you cannot audit the decision trail — a problem that becomes acute in regulated environments where evidence of control matters.

Change programmes underestimate resistance. A technology migration or operating model redesign that looks clean on paper will fail if it cuts across a collaboration network that is load-bearing. The resistance is not irrational. It is structural.

Duplication goes undetected. When teams operate in silos and the informal connections between them are not visible, the same problem gets solved multiple times in parallel — different tools, different processes, different answers. I have written before about the Duplicate Spend Heatmap as a way of surfacing this. Collaboration network mapping is often what reveals why the duplication exists in the first place: disconnected communities solving the same problem independently.

The Business Architecture Opportunity

This is where Business Architecture can move from documentation discipline to genuine operational value.

Mapping collaboration networks is not an academic exercise. Done well, it answers directly the questions executives actually care about:

• Which informal networks are load-bearing — and what breaks if they are disrupted?
• Where are the connectors and knowledge brokers who are not visible in the org chart but are critical to delivery?
• Which collaboration patterns are working well and could be formalised, resourced, and scaled?
• Where are the gaps — places where teams should be collaborating but are not, and where that absence is costing time, money, or risk control?

The method does not require expensive tooling or a six-month programme. A Business Architect can map a collaboration network within a domain in a matter of weeks, using structured interviews, working session observation, and process tracing. The output is not a 300-box diagram. It is a practical view of who connects to whom, around what outcomes, and with what degree of formalisation and support.

From Mapping to Supporting: The Design Move That Matters

Mapping is necessary but not sufficient. The real value comes from deciding what to do with what you find.

For each significant collaboration network, there are three design choices:

• Formalise it. If a network is load-bearing and currently depends entirely on informal trust, give it structure: a named owner, a shared space, a light governance cadence, and explicit recognition in the operating model. You are not bureaucratising it — you are protecting it.
• Support it. Not every network needs formalisation. Some function best as lightweight communities. What they need is visible sponsorship, access to shared tools and knowledge infrastructure, and protection from organisational change that would accidentally sever critical connections.
• Redesign around it. Where a collaboration network exists because the formal structure creates an artificial boundary, the right answer is to move the boundary — redesign the operating model so the co-ordination cost is reduced, not just managed.

This is the difference between Business Architecture as a mapping activity and Business Architecture as a design authority — one that shapes how the organisation actually works, not just describes it.

A Practical Test

If you want a quick diagnostic for your organisation, try this:

• Pick one complex, cross-functional process that ran well last year — and trace how it actually worked. Who called whom? Where were the informal checkpoints? Who unblocked it when it stalled?
• Now pick one that failed or ran poorly. Apply the same tracing. Where were the missing connections? Where did the collaboration network break down — or simply not exist?
• Finally, ask: does your current operating model design reflect what you just found? Or is it still built around the org chart fiction?

In my experience, this exercise consistently surfaces two things: the networks that are performing above what the org chart would predict — and the structural gaps that no amount of individual heroism can bridge.

The Closing Thought

Business Architecture has a long history of mapping what is. The next step — and the more valuable one — is designing what should be.

Collaboration networks are not a workaround for a broken org chart. They are the organic response to the reality that complex value delivery requires co-ordination that no hierarchy can fully pre-specify. They deserve to be seen, mapped, and intentionally designed — not left to chance, individual heroics, or the next organisational restructure that accidentally severs them.

Three questions to leave you with:

• Can you name the three most critical collaboration networks in your organisation right now?
• Do you know who the key connectors are — and what happens to delivery if they leave?
• Is your operating model designed around them, or despite them?

I suspect the answers will be uncomfortable. But that discomfort is exactly where Business Architecture can create the most value.