Skip to content
Institute of Technical Leadership
All blog posts

Communication

The CIO Doesn't Want Your Architecture Diagram

Principal Architect · 19 May 2026 · 6 min read

Forty minutes into a steering committee at a mobile network operator, the slide went up. Nineteen boxes, four swim lanes, a dotted line for the replication path, and a legend in six point font. The architect had spent a genuinely impressive amount of Sunday on it.

The CIO looked at it for about four seconds and said: "So when can I turn the old one off?"

They are not evaluating your design, they are deciding whether to keep funding you

This is the thing that took me years to understand, and I wish somebody had just said it to me plainly.

When you present to a senior stakeholder, you are not being examined on the quality of your technical thinking. They have already decided you're competent, or you wouldn't be in the room. What they are doing is quite different: they're working out whether this project is still going to do the thing they told somebody else it would do, and whether they need to spend any of their own attention on it this month. Their attention is the scarcest resource in the building and they are ruthless about where it goes.

So a diagram is an odd thing to hand them. A diagram is evidence of thinking. It answers "is this well designed?", a question they are not asking and mostly cannot evaluate. Meanwhile the question they came in with, when can I turn the old one off, is sitting unanswered while you talk about the replication path.

And when you don't answer it, they don't conclude "the design must be complicated". They conclude that you haven't got a date, which is an entirely different and much more expensive thought to put in a CIO's head.

What they're actually carrying into your meeting

Picture their Tuesday. Before your slot they had a supplier negotiation, a conversation about somebody's resignation, and fifteen minutes with the CFO about next year's number. Your project is one of maybe eleven things they're accountable for. They walked in holding four things, and none of them is your architecture.

The date they've already said out loud to somebody else. That's the big one. A CIO who has told the board the legacy platform is gone by March is personally exposed to your March, and they will care about it far more than you expect and in ways that have nothing to do with engineering.

The money, in the shape it appears on their budget line. Not your effort estimates. The capital that's already committed and the run cost they're promising will drop when you're done.

The risk they'll have to explain. Regulators, auditors, the incident that will have their name on it if it goes wrong at 3am on a Sunday.

Their own credibility with peers. This is the one nobody says out loud. If the head of retail thinks IT is unreliable, your CIO's life gets harder in every meeting they attend for the next year, and a project that surprises the business is a project that does that to them.

Now look at your deck again. How many of your slides speak to any of those four? On most decks I've reviewed, the honest answer is one, and it's usually the last one, and it usually gets cut for time.

Rebuilding the pack at the operator

Back to the operator. Billing platform replacement, eighteen months, two integrators, a 25-person delivery group, and a steering committee every three weeks that everybody quietly dreaded.

The old pack ran to twenty-two slides. Architecture, workstream status by RAG, a risk register with forty entries sorted by ID, and a slide called "technical achievements this period" which listed things like "completed non-functional test harness". All true. All produced by people doing careful work.

We cut it to four slides and the meeting got shorter, louder and considerably more useful.

Slide one: the date. One line saying decommission of the legacy platform is still 14 March, and one line saying what would move it, which that period was the data migration dress rehearsal on 9 February. No colour, a date and a dependency.

Slide two: the decisions needed today. Two of them, each with a named owner, a recommendation, and the consequence of not deciding by a specific date. That period it was whether to fund a second migration rehearsal window, and whether the head of customer operations would accept a four hour read-only period on the Saturday.

Slide three: the three risks that could actually move the March date, written in business terms. Not "interface complexity". Instead: "if the customer data cleanse isn't finished by 20 January we lose the February rehearsal, and the next clean weekend is 7 March, which leaves no recovery room."

Slide four: what changed since last time, in four or five lines, including anything the CIO might hear about from someone else before the next meeting. That last part matters more than it sounds. The worst moment in a senior relationship is when they learn something about your project from a peer at lunch.

The architecture diagram went into the appendix. Over the following four months, one person asked for it once, and it was the enterprise architect, who already had it. That's not an argument against having the diagram. Build it, argue about it, keep it current, it's how you and your team hold the design honest. Just recognise who it's for. It's a working artefact for the people doing the work, and it is not a communication tool for someone with eleven projects and a board meeting on Thursday.

The cadence does more work than the pack

One more thing, because the pack isn't really the point.

Trust with a senior stakeholder gets built in the gaps between meetings, not in the meetings. If the only time your CIO hears from you is in a formal committee every three weeks, every contact carries weight and every piece of bad news arrives as an event. If they get two lines from you on a Tuesday when something material shifts, the formal meeting becomes a confirmation rather than a reveal, and you'll notice they start defending your project in rooms you're not in.

That's the actual prize. Not a better deck. A senior person who repeats your version of the situation accurately when you're not there to correct them.

Before your next steering committee

Delete your first slide. Replace it with two lines: where you are against the date they care about, and the one decision you need from them today, with a name on it.

Then send the pack to your sponsor 48 hours early with a one line note asking whether anything in it will surprise the room. Whatever they flag is the thing you should have led with, and their answer tells you more about your standing with that committee than the meeting itself will.

Principal Architect

Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.

This is the kind of thing we teach properly in Foundations of Technical Leadership.

Foundations of Technical Leadership is 25 self-paced lessons, with templates you can use the same week.