The Diagram Test: If You Can’t Draw It, You Probably Don’t Understand It (June 2026)

There is a moment in almost every transformation programme where the room goes quiet.

Not because agreement has been reached.

Because somebody finally asks:

“So… how does this actually work?”

That is usually when the architecture diagram appears.

Three pages.

Forty-seven boxes.

Nineteen arrows.

Two dotted lines.

One “integration layer”.

And a growing suspicion that nobody in the room fully understands what they are looking at.

The modern workplace has become remarkably good at manufacturing complexity. Particularly in delivery environments where systems, platforms, governance structures, vendors, APIs, workflows and reporting layers collide under the broad banner of “digital transformation.”

But here is the uncomfortable truth:

If you cannot explain the system simply, you probably do not understand the delivery context well enough yet.

Not technically.

Operationally.

Or organisationally.

And that matters.

Because projects rarely fail due to a lack of diagrams.

They fail because people misunderstand the system they are trying to change.

The 10-Box Test

One of the simplest exercises I have seen recently (thanks Dave Westgarth), and one of the most revealing, is this:

Draw the system you are delivering in ten boxes or less.

Not the enterprise architecture version.

Not the 120-slide governance pack.

Not the “future-state capability model” with seventeen shades of blue.

Just the version a stakeholder could understand.

Your boxes might include:

• The customer or user

• The front-end

• The workflow

• The API

• The data source

• The approval process

• The reporting layer

• The database

• The human intervention point

• The downstream operational system

Then connect the arrows.

Where does work enter?

Where does data move?

Where does transformation happen?

Where does somebody manually intervene?

Where does the output land?

Where could it fail?

Who owns each part?

It sounds deceptively simple.

It is not.

Because the exercise exposes things organisations often work very hard to avoid seeing.

What the Diagram Usually Reveals

The first thing it exposes is alignment.

Or more accurately, the lack of it.

If five people draw five different versions of the same system, you do not have a delivery plan.

You have competing assumptions.

The second thing it exposes is ownership.

There is almost always one box nobody truly owns.

Sometimes it belongs to a vendor.

Sometimes to “the business.”

Sometimes to a team that no longer exists but is still mysteriously referenced in governance papers.

These orphaned boxes become delivery risk magnets.

The third thing it exposes is operational fragility.

The manual spreadsheet.

The undocumented workaround.

The “temporary” process now running business-critical operations two years later.

Every delivery leader eventually discovers the same thing:

The most dangerous parts of a system are usually the parts everybody has normalised.

Complexity Is Often a Status Symbol

There is also a deeper organisational issue hiding underneath all of this.

In many environments, complexity has become associated with credibility.

The more complicated the diagram, the more sophisticated the work appears.

But complexity is not maturity.

Sometimes complexity is simply unresolved thinking with branding.

Good delivery leadership is not about making systems sound impressive.

It is about making them understandable enough for people to make decisions, identify risks, and move valuable work through them with confidence.

Clarity is not simplistic.

Clarity is operational.

Where AddsValue Fits

At AddsValue, a significant amount of delivery risk assessment work starts with exactly this type of conversation.

Not:

“What methodology are we using?”

But:

“Does everyone actually understand the system we are changing?”

Because before strategy can succeed, before governance can function, before benefits can be realised, people need a shared understanding of how value moves through the system.

That is where many programmes quietly break down.

Not at implementation.

At comprehension.

The Better Questions

So take one project, platform, service, AI initiative or operational workflow you are involved with.

Draw it.

Ten boxes or less.

Then ask:

• What do I understand better now?

• Which box worries me most?

• Where does ownership become vague?

• Where are humans compensating for system weakness?

• Where could the process silently fail?

• Which arrows depend on trust rather than structure?

• What still feels unclear?

Because delivery leadership is not just managing timelines and status reports.

It is helping people make sense of messy systems, and turning that understanding into outcomes.

And if the system cannot be explained simply yet, the work probably is not ready to scale.