I have watched excellent architecture die in a meeting. Not because it was wrong — because it was explained to the people funding it in a language they couldn't act on, and so they did the rational thing when faced with something they didn't understand: they said no, or they said "let's revisit next quarter," which is the same thing wearing a politer coat. And I've watched more ordinary architecture sail through because the person presenting it could make a room of executives see what it was for. Over enough of these rooms, an uncomfortable truth settles in: the ability to explain your technical decisions to the people who sign the cheques is not a soft skill you bolt on after the real work. It's the skill that decides whether the real work ever happens at all. You can be right and unfunded, which is just a more frustrating way of being stopped.

This is a lesson I came to honestly, from a background in communication before I ever built a pipeline, and it's the thread I keep pulling: a message is never just its content — it's its content plus the person receiving it. The most brilliant architecture diagram is meaningless to a CFO, not because the CFO is unintelligent, but because you handed them a message written for a different receiver. The whole task of explaining your architecture upward is translation — taking a thing that is true in the language of engineering and making it true, and actionable, in the language of the person deciding whether to fund it.

Start from what they're actually deciding

The first mistake technical people make in the boardroom is answering a question nobody asked. The board is not deciding whether your medallion architecture is elegant. They're deciding whether to spend money, take on risk, and back a direction — so the explanation has to live in their terms: cost, risk, opportunity, and time. "We should adopt this platform because it decouples storage from compute" is a true sentence that lands as noise. "This lets us grow our data capability without our costs growing at the same rate, and here's roughly what that saves over three years" is the same decision, translated into the currency the room actually uses. Same architecture. Utterly different reception.

The practical translations

A few moves that reliably work, learned the hard way:

  • Lead with the why, not the what. Open with the business problem the architecture solves, not the architecture. The technical shape is your answer to their problem — so state the problem first, or your answer has nothing to attach to.
  • Trade jargon for consequence. Every technical term you use, translate on the spot into what it means for them. Not "we'll implement row-level security" but "people will only see the data they're allowed to, which keeps us on the right side of the regulator." The instant translation is the whole craft.
  • Use analogy without condescension. A good analogy — the warehouse and its loading bays, the plumbing behind the wall — lets a non-technical person hold a technical idea long enough to decide about it. The art is illuminating without talking down; you're building a bridge, not lowering yourself.
  • Quantify what you can, honestly. Boards think in numbers. A defensible estimate of cost, saving, or risk beats a vague "this is better" every time — and if you can point to a concrete result, like a cleanup that meaningfully cut infrastructure cost, do, because a real number from your own work is worth a hundred adjectives.
  • Be honest about risk and cost. Nothing builds the trust that gets things funded like naming the downside yourself. The presenter who volunteers the risks reads as a trustworthy advisor; the one who only sells the upside reads as someone managing you. Boards have seen enough of the latter to prize the former.

The part that feels unfair, and isn't

Plenty of brilliant engineers find this genuinely galling — the sense that they should be funded on the merits of the work, not on their ability to perform it in a meeting. I understand the frustration, and I'd gently push back on it. The communication is part of the merit. An architecture that can't be explained to the people who must maintain, fund, and trust it has a real design flaw, even if the flaw isn't in the diagram. Part of doing the work well is making it legible to the people it has to serve, and the people it has to serve include the ones holding the budget. A solution nobody with money understands is, functionally, not a solution yet.

The counter-view deserves its due: yes, this can tip into style over substance, and there are smooth presenters who fund bad ideas by explaining them beautifully. That's real, and it's a reason to insist the substance be there — not a reason to neglect the explaining. The goal isn't to become a slick presenter of hollow ideas. It's to make sure your good ideas get the hearing they deserve, because the alternative is watching worse ideas, better explained, get the budget instead. That helps no one, least of all the organisation that needed your good idea and never got to see it clearly.

So if you're technical and ambitious, invest in this as seriously as you invest in any tool. Learn to stand in a room of people who sign cheques and make them see what you see, in their language, on their terms. It is not a betrayal of the technical work. It's how the technical work survives contact with the world — and it turns out to be, in the end, the same discipline as everything else I care about: never mistaking what you said for what they heard.