Executive Communication
Presenting technical matters to an audience that owns outcomes and money, in a form that supports a decision within their attention span.
The structural mistake is building to a conclusion. Technical narrative moves from context through analysis to recommendation; executive communication inverts it — conclusion first, then the reasoning, then detail available on request.
What the audience needs: the decision being asked for, stated plainly; the cost in money and time; the risk of acting and of not acting; and the business outcome affected. What they do not need is the technology, unless it changes one of those four.
The framing that fails predictably: presenting technical debt, platform work or modernisation in technical terms. "We need to refactor the payments service" competes for budget against a revenue feature and loses. "Payment failures cost roughly £400,000 a year in lost transactions and 30% of the support team's time; this addresses it in two quarters" is the same request in the terms the decision is actually made in.
Two practical disciplines. Quantify with ranges and stated assumptions rather than false precision, because a confident single number invites challenge on the number rather than engagement with the argument. And prepare the one sentence you want repeated in the meeting you are not in, since that is what actually travels.
The temptation to resist is proving competence through detail. Credibility with this audience comes from clarity about consequence and from being right previously, not from depth.