You have to present the same architecture to the board on Tuesday and to the engineering teams on Wednesday. How do the two differ?

They are different artifacts, not the same one with different notes

The common mistake is one deck with the technical slides skipped for the board. The board notices, and the engineers get a session pitched below what they need.

For the board

A context diagram — one box for the system, surrounded by the people and external systems it touches. No internals. It is the only diagram in the pack a non-technical audience can read unaided.

Outcomes and money. What capability this enables, what it costs to build and to run, what risk it retires, and when.

The two or three decisions that carry real consequence, framed as trades: we chose this, it costs that, we gave up this alternative and here is why.

Risks, with owners and dates.

No technology names unless a name is itself the decision — a vendor commitment, a platform standard.

For the engineers

A container diagram with technologies named, because the choices are what they will live with.

Sequence diagrams for the hard interactions — the ones with failure paths, timeouts and compensation.

The decision records, so the reasoning is available rather than summarised.

What is not yet decided, which is the part engineers most want and most decks omit.

The shared spine

Both should be traceable to the same set of decisions. If the board's version implies something the engineering version contradicts, that will surface, and it damages both audiences' confidence in the whole pack.