Tag: technical presentation non-technical executives

In 2017 I coached a lead infrastructure engineer the week before he presented a server-replacement programme to the board of a technology company. He was, by some distance, the most capable person in the room on the subject — he had designed the architecture, run the failure analysis, and modelled the capacity himself. His deck opened with a topology diagram: load balancers, redundant nodes, a failover path drawn in three colours. He walked the board through it carefully, because he respected them enough to show them the real engineering. Four minutes in, the chief executive turned her copy of the deck face-down on the table and said, “Stop. I don’t need to know how the plumbing works. Tell me what happens to the business if we don’t spend this money, and tell me what happens if we do.” He could not switch tracks. He kept reaching back for the diagram. The programme was sound, the risk was real, and the spend was justified — and it was sent back for “a clearer business case” anyway, which cost him six weeks and a slice of his standing he did not get back quickly.

(This article was created with AI assistance; all stories and insights are based on 35 years of real client work.)

That afternoon taught me the rule I have spent years teaching technical specialists who present to senior, non-technical audiences: an executive room does not reward you for explaining your work. It rewards you for translating it into a decision they can make. The engineer’s instinct — show the rigour, prove the competence, let the detail speak — is exactly the instinct that loses the room, because the room is not equipped to read the detail and is not trying to. This piece walks through the method that reverses the effect: the Translation Layer, a four-move structure for turning specialist work into an executive decision; the repeat-back test that tells you, before the meeting, whether your translation has actually landed; and why doing this is the opposite of dumbing your work down. It works whether you are an engineer, a data scientist, a clinician, a lawyer, an actuary, or any specialist whose competence is not in doubt and whose presentations keep getting sent back anyway.

Why explaining your work loses a non-technical room

The instinct that drives the topology diagram is reasonable and almost always wrong. The specialist reasons: this is an important decision, the board should see the rigour behind it, so I will show them the engineering. The flaw is the assumption that understanding the mechanism is what produces the decision. It is not. A non-technical director cannot evaluate a failover path; what they can evaluate is what the failover path does to risk, cost, and continuity. When you show them the path and not its consequence, you have handed them a problem they cannot solve in the room, and a person who has just been handed an unsolvable problem does not feel informed. They feel uneasy — and that unease attaches itself not to the diagram but to the proposal.

This is the mechanism behind the failure. Every technical detail a non-specialist audience cannot evaluate adds cognitive load without adding confidence, and unresolved cognitive load is experienced as risk. The board is not thinking “I do not understand the redundancy design.” It is thinking “there is a lot here I am being asked to take on trust, and I still do not know what happens to the business either way.” A board that does not know the business consequence does the safest available thing, which is to ask for a clearer case and defer. The detail did not fail because it was wrong. It failed because it asked the wrong people to do the translation — to convert your mechanism into their decision — in real time, in public, which is the one thing a senior audience will not do. The broader discipline of presenting as a technical expert reduces to a single shift: the translation is your job, not theirs, and a presentation that outsources it back to the room has failed before you reach the second slide.

The reframe that fixes it is uncomfortable for people who built their careers on depth. You are not presenting your analysis. You are presenting the decision your analysis points to, supported by the minimum a non-specialist needs to trust it and to defend it to their own bosses. The depth still exists — it lives in the appendix, in your head, in the answers you give when challenged — but it is not the spine of the talk. The spine is the decision and the one translation that makes the decision feel safe. Everything else is available on request, not on screen by default.

The Translation Layer: four moves

The Translation Layer is a four-move structure you run on every technical point before it reaches a slide. It is not a style preference; each move removes one of the ways technical content pushes work back onto a non-technical audience. A point that passes all four moves arrives as a decision a director can act on. A point that skips any of them starts to read as a lecture, and a senior room disengages from a lecture faster than from almost anything else.

The four moves are these. One, anchor to a decision they already make. Open from a choice the executive recognises and owns — a budget trade-off, a risk they are accountable for, a deadline they have committed to externally — not from the technology. The anchor tells them why they should care before you have said anything they cannot follow. Two, map the unfamiliar to the familiar. Carry the mechanism across with one clean analogy drawn from their world, not yours: the redundancy design is “a spare engine that takes over mid-flight without the passengers noticing,” not “an active-active cluster with automated failover.” Three, state the business implication, not the technical fact. Say what changes for cost, risk, time, or revenue — “this removes the single point of failure that took the payments system down for nine hours last year” — rather than the property of the system that produces it. Four, hand back exactly one technical fact — the single piece of detail the executive needs to defend the decision when their own boss or auditor asks. One fact, chosen deliberately, not the ten you are proud of.

What makes the four moves work together is that each protects the audience from a specific failure. The anchor removes the “why are you telling me this?” gap. The analogy removes the comprehension gap. The implication removes the “so what?” gap. The single handed-back fact removes the “what do I say when I’m challenged on this upstairs?” gap, which is the gap senior people care about most and mention least. None of the four is about simplifying for its own sake. Each removes a task the audience would otherwise have to perform silently, in the room, while deciding whether to trust you — and the cumulative effect is a point a non-specialist can act on in seconds rather than puzzle over for a minute.

The repeat-back test

The Translation Layer needs a test that tells you, before the meeting, whether your translation has actually happened or whether you only think it has. The test is mechanical and it is the single most useful thing in this article. Take your central point — the one the whole presentation turns on. Explain it out loud, once, to a colleague who does not work in your field: someone from HR, finance, operations, anyone outside the specialism. Then ask them to explain it back, not to you, but to a third person, as if briefing them. Listen to what survives the relay. If they reproduce the business implication — “they want to spend this to stop the payments outage that cost us nine hours last year” — the translation works. If they reproduce your mechanism, hedge, or go quiet, the translation has not happened, and the board will do exactly what your colleague just did, except the board will not tell you. It will simply ask for a clearer case.

The relay matters more than a simple “did you understand that?” because understanding in the moment is not the bar. The bar is whether your point can travel without you in the room. Executive decisions are rarely made by the people you present to alone; they are ratified later, defended to a chief executive, justified to an audit committee, repeated to a colleague who was not there. If your point cannot survive being repeated by a non-specialist, it cannot survive that journey, and the decision dies somewhere you never see. The repeat-back test simulates the real condition of the room, which is that your work will be carried onward by people who do not share your vocabulary.

The test also diagnoses which of the four moves has failed. If your colleague cannot say why it matters, your anchor is missing — you led with the technology. If they grasp why it matters but mangle what it does, your analogy is wrong or absent. If they can describe the mechanism but not the consequence, you stated the technical fact instead of the business implication. And if they reach for your jargon to explain it, you handed back the wrong fact, or too many. The test does not just tell you the point is unclear; it tells you which move to fix. Run it on the three points your presentation depends on and you will catch the failures the board would otherwise catch for you — with days left to fix them instead of finding out in the room. The same translation discipline applies the moment a non-technical executive asks you a question, when there is no time to prepare and the relay happens live.

Choosing the analogy that carries the decision

Of the four moves, the analogy does the heaviest lifting and is the one specialists distrust most, because a good analogy is never perfectly accurate and accuracy is the specialist’s religion. That instinct is the trap. The analogy’s job is not to be accurate; it is to be true enough to carry the decision while being instantly graspable. “A spare engine that takes over mid-flight” is not how an active-active cluster works, and an engineer can list ten ways it differs. None of those ways changes the decision the board is making, which is whether the redundancy is worth the spend. The analogy that carries the decision is the right analogy, even if it would fail a peer review — because the board is not a peer review, and the cost of imperfect analogy is far smaller than the cost of perfect incomprehension.

The craft is in drawing the analogy from the audience’s world, not yours. A board of retailers understands stock-outs and shelf space; a board of bankers understands liquidity and counterparty risk; a board of clinicians understands triage and contraindication. The same technical point needs a different analogy for each, because the analogy only works if the audience already owns the thing you are mapping to. The mistake specialists make is reaching for analogies from adjacent technical fields — explaining one system in terms of another system — which lands only with people who would have understood the original anyway. Build a small stock of analogies drawn from your specific audience’s domain, and test each one with the repeat-back test, because an analogy that does not survive the relay is decoration, not translation.

There is one discipline that keeps analogies honest: name the limit yourself, in one clause, the moment the analogy has done its work. “It’s a spare engine that takes over mid-flight — the difference being it switches in milliseconds, not minutes.” Naming the limit does two things. It pre-empts the one technical person in the room who was about to point out the flaw, and it signals that you know precisely where the simplification stops, which is itself a credibility move. An analogy offered with its limit named reads as mastery. An analogy offered as if it were the literal truth reads as a salesperson’s trick, and a senior room can smell the difference instantly.

The one technical fact you hand back

In 2014 I worked with a data analytics lead at a financial-services firm who had the opposite problem to the infrastructure engineer: she had over-translated. Coached once to “keep it simple,” she had stripped her model presentation down to a single sentence — “the model is more accurate, so we should use it” — and the board, sensing there was nothing underneath, declined to rely on it. We rebuilt her close around one handed-back fact: “The model is right four times out of five on accounts we’ve never seen before, against three times out of five for the rule we use today — and I can show you the year of back-testing behind that the moment you want it.” One fact, with the rigour visibly available behind it. The board approved a pilot the same meeting. She had the depth all along; what she lacked was the single fact that proved it without burying it.

The fourth move is the one specialists most often get backwards. They either hand back nothing, which reads as thin, or they hand back everything, which reads as a lecture. The discipline is to choose the one fact the executive needs — not the one you find most interesting — and the fact they need is almost always the one that lets them defend the decision when they are challenged by someone you will never meet. A director who approves your proposal has to repeat it to a chief executive, a regulator, or a sceptical peer. The fact you hand back is the ammunition for that conversation. Choose it as if you are arming an ally for a fight you will not be present at, because that is exactly what you are doing.

Knowing which fact to choose is itself a senior skill, and it is the inverse of the skill that made you a good specialist. As an analyst you were rewarded for holding all the facts; as a presenter to executives you are rewarded for knowing which single one survives contact with a non-specialist’s next conversation. The test is to ask: when this director defends my proposal to their boss tomorrow, what is the one thing they will be asked, and what is the one fact that answers it? Hand that back. Hold the rest in reserve. The vocabulary you choose at this point signals your seniority as much as the content does — the fact that lands is the one phrased in the executive’s language, not the lab’s.

Translating is not dumbing down

The fear that stops specialists translating is that it looks like dumbing down — that a board will think them shallow, or that simplifying betrays the work. The opposite is true, and the confusion between translating and dumbing down is what keeps brilliant people stuck at the level below the one their competence deserves. Dumbing down removes the rigour. Translating relocates it. The infrastructure engineer who says “a spare engine that takes over mid-flight” has not removed the active-active cluster; he has moved it from the spine of the talk to the answer he gives when a director asks how it actually works. The rigour is still there, visibly available, reachable in a sentence. That is the opposite of shallow.

What a non-technical board actually reads as shallow is the presenter who cannot translate — who can only operate at the level of the mechanism and stalls the moment the conversation moves to consequence. That presenter looks like a technician, however brilliant, because they cannot rise to the altitude at which decisions are made. The presenter who translates fluently looks like a leader, because translation is itself the senior act: it requires you to understand the work deeply enough to know which parts the decision actually depends on, and to understand the audience well enough to carry those parts across. You cannot translate what you only half understand. Fluent translation is therefore evidence of mastery, not a substitute for it, and senior audiences read it exactly that way.

This is why translation is a career skill, not a presentation trick. The specialist who repeatedly hands boards untranslated work earns a quiet reputation as someone whose output needs an interpreter before it can be used — valuable, but not yet ready for the room where decisions are made. The specialist who repeatedly translates earns the opposite reputation: the person you put in front of the board because they can take the hardest technical material and make it decidable. Over a dozen meetings, those two reputations diverge sharply, and they diverge on a skill that has almost nothing to do with the depth of the underlying work and almost everything to do with who is made to do the translating in the room.

One thing to do before your next technical presentation

Take the single most important slide in your next technical presentation — the one the whole recommendation rests on. Write one sentence at the top that names the business decision it supports, in the language of cost, risk, or time, with no technical noun in it at all. Find one analogy from the audience’s world for the mechanism underneath, and write the clause that names its limit. Decide on the single technical fact you will hand back and cut the rest to the appendix. Then run the repeat-back test: explain the point to someone outside your field, ask them to brief a third person, and listen for whether the business decision survives. If it does, you are ready. If it does not, you have just found the slide your board would have sent back — with days left to fix it instead of discovering it when a chief executive turns the deck face-down on the table.

Frequently asked questions

Won’t a technical audience member think I’m oversimplifying if I use analogies and hold back the detail?

This is the fear that keeps the topology diagram alive, and naming the limit is what resolves it. When you offer an analogy and then add the one clause that says where it stops — “the difference being it switches in milliseconds, not minutes” — you signal to the one technical person in the room that you know precisely where the simplification ends. That reads as mastery, not concealment. The detail is not gone; it is in your appendix and in your head, reachable the instant anyone asks. Technical audience members rarely object to translation done well, because they recognise the skill it takes. What they object to is translation done carelessly, where the analogy is wrong and no limit is named. Get the limit clause right and the specialist in the room becomes your ally, not your critic.

What if the executives genuinely need to understand the mechanism to make the decision?

This is rarer than specialists believe, but it does happen — and when it does, the Translation Layer still applies; you just extend the third move. Anchor to the decision, map with an analogy, and then walk one level deeper into the mechanism only for the specific part the decision turns on, never the whole system. The discipline is to ask which piece of the mechanism actually changes the choice in front of them, and to teach only that, in their language, with the analogy as scaffolding. A board deciding between two architectures may need to grasp one genuine difference between them; it does not need the full design of either. Teach the load-bearing difference, translate it, and leave the rest in the appendix. Needing some mechanism is not a licence to present all of it.

How long does it take to rebuild a technical deck this way, and is it worth it under time pressure?

Rebuilding an existing deck to the Translation Layer usually takes a couple of hours the first time and far less once the pattern is familiar, because most of the work is writing decision headlines and moving mechanism slides to an appendix you should have built anyway. Under genuine time pressure, the single highest-return move is the first one: spend ten minutes writing, at the top of each key slide, the business decision it supports in cost, risk, or time. That alone shifts the room from trying to follow your method to evaluating your recommendation. The full rebuild is worth it for any high-stakes approval where a deferral costs you weeks; for a routine update, the decision-headline pass is often enough. The structural work is cheap relative to the cost of being sent back for “a clearer business case.”

What’s the most common mistake technical experts make presenting to senior leaders?

Leading with the mechanism instead of the decision. The diagram, the model, the method goes first because it feels like the honest, rigorous way to begin — and it loses the room before the recommendation arrives, because the audience spends its attention trying to follow something it was never going to be able to evaluate. The second most common mistake is the opposite over-correction: stripping out so much that nothing rigorous remains, which reads as thin and gets declined for lack of substance. The fix for both is the same structure — anchor to their decision, translate the mechanism with one named-limit analogy, state the business implication, and hand back the single fact that lets them defend the choice. Get that order right and most of the technical-to-executive problem disappears, because the translation is finally being done by you, before the meeting, rather than by the room, during it.

The Winning Edge — weekly newsletter

The Winning Edge is a weekly (Thursday) newsletter for senior professionals who present to boards and executive committees. One short email a week on the structural moves that separate the technical work boards act on from the work they send back. Subscribe to The Winning Edge →

For the full set of skills behind a board-ready technical presentation — slides, storytelling, confidence, and delivery — the seven-product Complete Presenter bundle brings them together as a single resource — £99 for everything, lifetime access.

About the author

Mary Beth Hazeldine is Owner & Managing Director of Winning Presentations Ltd. With 24 years of corporate banking experience at JPMorgan Chase, PwC, Royal Bank of Scotland, and Commerzbank, she advises senior professionals across financial services, insurance, consulting, and technology on the structural moves that turn deep specialist work into decisions a board can act on.