Executive communication: BLUF, altitude, signposting, bounded uncertainty
What it is
Four techniques for talking to people whose time is expensive and whose context differs from yours. They are separable skills and each has a specific failure it prevents.
BLUF Bottom Line Up Front. The conclusion in
the first sentence, then the reasoning.
Prevents: the listener not knowing what
you want until minute three.
ALTITUDE CALIBRATION Matching the level of detail to the
audience, and adjusting when you have
misjudged.
Prevents: explaining Kafka partitions
to a CFO, or hand-waving to a principal.
SIGNPOSTING Announcing the structure before the
content. "Three things: the cause, the
fix, and what I need from you."
Prevents: the listener trying to work
out where you are going while you are
going there.
BOUNDED UNCERTAINTY Saying what you know, what you do not,
and when you will know.
Prevents: false confidence, and the
equally bad "it's complicated".
Commonly confused with being brief. Brevity is a consequence, not the technique. A five-minute BLUF answer is fine if the first sentence was the conclusion; a thirty-second answer that buries the point is worse.
Also commonly confused with dumbing down. Altitude calibration is about which details are load-bearing for this listener's decision, not about simplifying. A CFO does not need less truth; they need different truth.
The problem it solves
Senior people make decisions from summaries, and a summary that requires them to do the synthesis has failed.
THE FAILURE MODE, in a status update to a director:
"So we've been looking at the latency issue, and initially
we thought it was the database, but then Sam found that
the connection pool was actually the constraint, and we
tried increasing it but that caused the memory issue, so
we backed that out, and now we're looking at whether the
batch job..."
Three minutes in, the director still does not know: is
this fixed, is it getting worse, or do they need to do
something?
The narrative order (what happened, in sequence) is the wrong order for a decision-maker, and it is the order everyone defaults to because it is the order they lived it in.
And the second problem: engineers systematically over-hedge. "It might be the connection pool, but it could also be GC, and there are some other possibilities" is an accurate statement of uncertainty and it is unusable. The listener cannot act on it and concludes you do not know.
Mechanics
BLUF: the conclusion first
NARRATIVE ORDER (how you lived it)
investigation -> findings -> conclusion -> what I need
BLUF ORDER (how they need it)
conclusion -> what I need -> findings -> investigation
BEFORE
"We've been investigating the checkout latency. We started
with the database, ruled that out, then looked at the
connection pool..."
AFTER
"Checkout latency is fixed as of this morning, and I need
one decision from you about the follow-up.
The cause was connection pool exhaustion from a batch job
sharing the pool. We've separated the pools, and p99 is
back to 340 ms.
The decision: the proper fix is a query timeout on the
batch job, which is two days of work. I'd like to do it
next sprint rather than this one. That leaves us exposed
to a recurrence for about two weeks, at maybe a one in
ten chance."
The structure: conclusion, ask, cause, evidence, decision with its cost. And notice that the "after" version is not shorter, it is reordered. Brevity comes from the listener being able to stop early once they have what they need, which they cannot do when the conclusion is last.
The test for whether you have done it: could the listener leave after your first two sentences and still act correctly? If not, the bottom line is not up front.
Altitude calibration
The mistake is thinking of it as one dial. It is two: technical depth, and organisational scope.
TECHNICAL DEPTH
low high
ORG narrow | a PM a peer engineer
SCOPE | "the checkout "the pool was sized
| page was slow at 20 and the batch
| for an hour" job held 18"
|
wide | a CFO / board a principal / CTO
| "an outage cost "we have a
| us roughly systemic pattern
| $40k in orders" of shared resource
| pools across
| services"
The second axis is the one people miss. A CTO wants high technical depth and wide scope, which means the answer is not "the connection pool was exhausted" (narrow) and not "we had an outage" (shallow), it is "this is the third incident from an unbounded shared resource, and I think we need a policy rather than three fixes".
The calibration signals to watch for, and the recovery:
YOU ARE TOO DEEP IF
they ask a question you already answered
they look at their phone
they say "so at a high level..."
-> Recovery: "Let me back up. The one-sentence version is X."
YOU ARE TOO SHALLOW IF
they ask "but why?"
they ask a question that presumes more detail
they start proposing solutions you already ruled out
-> Recovery: "Happy to go a level deeper on that."
*** Ask once, explicitly, rather than guessing: ***
"Do you want the two-minute version or the detail?"
It costs three seconds and it removes the whole problem.
Asking directly is under-used because it feels like weakness, and it is the opposite: it demonstrates that you know the answer has multiple altitudes and that you are choosing deliberately.
Signposting
"Three things: what happened, what we've done, and the one
decision I need from you."
Then deliver exactly three things, in that order, and say
"first", "second", "third".
Why it works: the listener stops spending attention on working out the structure and spends it on the content. It also commits you to a structure, which prevents the drift that turns a two-minute update into six.
The variants worth having:
FOR A STATUS UPDATE
"Green, with one risk. The risk is X, and here's the
mitigation."
FOR BAD NEWS
"I have bad news and a plan. The news is X. The plan is Y.
What I need from you is Z."
FOR A RECOMMENDATION
"I recommend X. Three reasons, and one thing that would
change my mind."
FOR AN ANSWER YOU ARE UNSURE OF
"Short answer is X. I'm about 70 percent confident, and
here's what would move it."
"One thing that would change my mind" is the highest-value phrase in this list, because it demonstrates that the recommendation is a judgement rather than a preference, and it invites the listener to supply information rather than to argue.
Bounded uncertainty
The failure is symmetric: false confidence and unbounded hedging are both unusable.
FALSE CONFIDENCE
"It's the connection pool."
(when you are 60 percent sure)
-> They act on it. If you are wrong, your next assertion
is discounted.
UNBOUNDED HEDGING
"It might be the pool, or GC, or the network, hard to say."
-> Unusable. They conclude you do not know, and they ask
someone else.
BOUNDED UNCERTAINTY
"Most likely the connection pool, maybe 70 percent. The
alternative is GC pressure. I'll know for certain within
two hours, and the fix is the same for both, so I'm
proceeding."
-> Actionable. They know what you think, how sure you are,
when it resolves, and that they need not decide now.
The four elements: the answer, the confidence, the alternative, and when you will know. All four, and the fourth is the one that converts uncertainty from a problem into a schedule.
And the version for when you genuinely do not know:
"I don't know, and here's how I'd find out."
That is a complete and strong answer. What is weak is
guessing, or filling the silence. See: handling what you
do not know.
Writing, which is the same skills with different constraints
An executive summary that works:
ONE SENTENCE the conclusion
THREE BULLETS the reasoning, one line each
ONE ASK what you need, specifically
------- everything below here is optional reading -------
DETAIL for whoever wants it
The line matters. Putting the detail below an explicit
boundary means the reader knows they can stop, which means
they read the top carefully instead of skimming everything.
And the rule for documents: if the recipient reads only the title and the first paragraph, have they got it? That is the same BLUF test applied to writing, and it is why titles like "Q3 Latency Update" fail and "Checkout latency fixed; one decision needed on the follow-up" works.
A worked example: the same incident at four altitudes
THE FACTS
A batch job shared a connection pool with the checkout
service. The pool held 20 connections; the batch job held
18 for 40 minutes. Checkout p99 went from 340 ms to 8 s.
Roughly 4% of checkout attempts abandoned. Fixed by
separating the pools. The permanent fix is a query timeout
on the batch job, two days of work.
TO A PEER ENGINEER
"Connection pool exhaustion. The nightly reconciliation
job shares checkout's pool, sized at 20, and it held 18
with long-running scroll queries. Little's Law says with
two usable connections and an 8 ms service time we cap at
250 requests a second, and we were taking 400. Separated
the pools; the real fix is a timeout on the scroll."
TO A PRODUCT MANAGER
"Checkout was slow for 40 minutes last night, and about 4
percent of people trying to check out gave up. It's fixed.
The cause was a background job competing for a shared
resource. There's a two-day piece of work to make sure it
can't recur, and I'd like to schedule it next sprint."
TO A DIRECTOR
"We had a 40-minute checkout degradation, roughly 4 percent
abandonment, now resolved. The cause was a shared
resource pool with no isolation between batch and
interactive work. I'd flag that this is the second
incident from the same pattern, so I'm proposing a policy
that batch work never shares a pool with a user-facing
path, which is about a week across the three services
affected. The decision I need is whether that displaces
something in the current sprint."
TO A CFO OR THE BOARD
"A 40-minute checkout outage last night, estimated impact
around $40,000 in abandoned orders. Resolved, and we've
identified a systemic pattern behind it that we're
addressing this quarter. No customer data was affected."
Notice what changes and what does not. The facts are identical. What changes is which facts are load-bearing for that listener's decision, and the scope: the peer gets the mechanism, the director gets the pattern across incidents, and the CFO gets the money and the reassurance about data.
And notice the director version is the only one that names a decision needed, because the director is the one who can make it. Asking a CFO to prioritise a sprint is an altitude error in the other direction.
Production evidence
BLUF originates in US military communication doctrine and is standard in situations where the recipient may stop reading at any point, which is the same constraint an executive summary operates under.
Barbara Minto's The Pyramid Principle is the canonical treatment: answer first, then supporting arguments, then evidence, developed at McKinsey precisely because clients would not read to the end.
Amazon's six-page narrative memo culture is the opposite convention and the exception worth knowing: no slides, a written narrative read silently at the start of the meeting. It works because the reading is enforced, and it does not transfer to organisations where documents are skimmed.
Research on expert-novice communication consistently finds that experts systematically over-estimate what novices know, which is the mechanism behind altitude errors and why asking directly is more reliable than judging.
Studies on hedging in professional communication find that unbounded hedging reduces perceived competence while calibrated confidence statements do not, which is the empirical basis for bounded uncertainty over both false confidence and vague qualification.
The debate
The case for BLUF everywhere: senior people's time is the scarcest resource in the organisation, and requiring them to synthesise a conclusion from a narrative is a transfer of work from you to them. It also forces you to have a conclusion, which is a useful discipline in itself.
The case against: for genuinely complex or contentious decisions, leading with the conclusion can trigger an immediate reaction before the reasoning lands, and some audiences disengage from a conclusion they disagree with. Narrative order can be the right choice when you need someone to reach the conclusion themselves.
The case for maximum detail: withholding detail from a technical leader is patronising, and some decisions genuinely require the mechanism to be understood.
My position: BLUF by default, ask about altitude explicitly rather than guessing, and always bound your uncertainty with all four elements.
The default matters because the narrative order is what everyone reverts to under pressure, since it is the order they lived it in, and the cost is that a director spends three minutes not knowing whether they need to act. Making BLUF the default costs nothing when the audience wants detail, because the detail follows immediately.
Asking directly about altitude, "do you want the two-minute version or the detail", is the technique I would push hardest because it is the most under-used. It feels like weakness and it is the opposite: it demonstrates you know the answer has several altitudes and you are choosing deliberately rather than guessing. Three seconds, and it removes the whole problem.
On uncertainty, all four elements or the statement is unusable: the answer, the confidence, the alternative, and when you will know. Engineers reliably give the first and the third and omit the second and fourth, which produces "it might be the pool or it might be GC", and the listener correctly concludes they cannot act on it. Adding "70 percent, and I'll know within two hours" converts the same uncertainty into a schedule.
And the phrase I would put in every recommendation: "one thing that would change my mind." It converts a preference into a judgement, it invites the listener to supply information rather than argue, and it is the difference between a recommendation someone can engage with and one they have to accept or reject.
Where I would concede the counter-argument: for a contentious decision where you need someone to arrive at the conclusion themselves, narrative order is legitimate. But that is a deliberate choice for a specific reason, and it is not what is happening when an engineer walks a director through their debugging session chronologically.
Follow-up Q&A
"What is BLUF and why does it matter?" Bottom line up front: the conclusion in the first sentence, then the ask, then the reasoning. It matters because senior people decide from summaries, and a summary requiring them to synthesise the conclusion has transferred work to them. The failure it prevents is specific: three minutes into a narrative update, the listener still does not know whether this is fixed, getting worse, or something they need to act on. And the test is whether they could leave after two sentences and still act correctly.
"Isn't that just being brief?" No, and the distinction matters. A five-minute answer is fine if the first sentence was the conclusion; a thirty-second answer that buries the point is worse. Brevity is a consequence: the listener can stop early once they have what they need, which they cannot do when the conclusion is last. The BLUF version of an update is often the same length, reordered.
"How do you calibrate altitude?" By asking, which is the most under-used technique here. "Do you want the two-minute version or the detail" costs three seconds and removes the guessing. And I would think of it as two dials rather than one: technical depth and organisational scope. A CTO wants high depth and wide scope, so the answer is neither "the connection pool was exhausted" nor "we had an outage", it is "this is the third incident from the same pattern and I think we need a policy rather than three fixes".
"What are the signals that you have it wrong?" Too deep: they ask something you already answered, they check their phone, or they say "so at a high level". Too shallow: they ask "but why", or they start proposing solutions you already ruled out. Either way the recovery is one sentence, "let me back up, the one-sentence version is X" or "happy to go a level deeper", and recovering explicitly is better than adjusting silently and hoping.
"How do you communicate uncertainty without sounding like you do not know?" Four elements, all of them. The answer, the confidence, the alternative, and when you will know. "Most likely the connection pool, about 70 percent, the alternative is GC pressure, and I'll know within two hours" is actionable. Engineers reliably give the answer and the alternative and omit the confidence and the timeline, which produces "it might be this or it might be that", and the listener correctly concludes they cannot act on it.
"What if you genuinely do not know?" Say so, and say how you would find out. "I don't know, and here's how I'd find out" is a complete and strong answer. What is weak is guessing to fill the silence, because a guess presented as an answer costs you on the next assertion too.
"What is signposting and why bother?" Announcing the structure before the content: "three things, what happened, what we've done, and the one decision I need from you". It works because the listener stops spending attention working out where you are going and spends it on the content. And it commits you to a structure, which prevents the drift that turns a two-minute update into six.
"Is there a phrase you would always include in a recommendation?" "One thing that would change my mind." It converts a preference into a judgement, it demonstrates you have thought about the conditions under which you would be wrong, and it invites the listener to supply information rather than to argue with you. It is the single highest-value phrase in this whole area.
"When is BLUF wrong?" For a contentious decision where you need someone to reach the conclusion themselves, leading with it can trigger a reaction before the reasoning lands. Narrative order is legitimate there, and it is a deliberate choice for a specific reason. What is not that is an engineer walking a director through their debugging session chronologically, which is the default everyone reverts to under pressure because it is the order they lived it in.
Common misconceptions
"Executive communication means less detail." It means different detail. A CFO does not need less truth; they need the truth that bears on their decision.
"BLUF means brief." It means reordered. Brevity follows because the listener can stop early.
"Hedging is honest." Unbounded hedging is unusable and reads as not knowing. Bounded uncertainty with a confidence and a timeline is both honest and actionable.
"Asking what level of detail they want looks unprepared." It demonstrates you know the answer has several altitudes. Guessing wrong is what looks unprepared.
"Altitude is one dial." It is two: technical depth and organisational scope, and the second is the one people miss.
Interview delivery note
This is assessed indirectly, in how you answer everything else, and directly in questions about communicating with leadership.
If asked directly, lead with the failure it prevents rather than the acronym: "The failure is that three minutes into a status update the director still doesn't know whether this is fixed, getting worse, or something they need to act on. That happens because we narrate in the order we lived it, and the decision-maker needs the conclusion first, then the ask, then the reasoning."
Then the technique with the test: "So: conclusion, ask, cause, evidence. And the test is whether they could leave after two sentences and still act correctly. Notice the reordered version isn't shorter, it's reordered, and the brevity comes from them being able to stop early."
Volunteer the altitude technique that is most under-used: "And for altitude I'd ask rather than guess. 'Do you want the two-minute version or the detail' costs three seconds and removes the problem entirely. It feels like weakness and it's the opposite: it shows you know the answer has several altitudes and you're choosing deliberately."
Give the uncertainty formula, because engineers systematically get this wrong in one of two directions: "And for uncertainty, four elements or it's unusable: the answer, the confidence, the alternative, and when you'll know. 'Most likely the pool, seventy percent, alternative is GC, I'll know in two hours' is actionable. 'It might be this or that' isn't, and the listener correctly concludes you don't know."
And demonstrate it throughout the interview rather than describing it, because that is what is actually being scored: lead every answer with the conclusion, signpost when you are about to give three things, and bound your uncertainty when you have any.
Further reading
- Barbara Minto, The Pyramid Principle, for answer-first structure and the pyramid of supporting arguments.
- The US Army's writing guidance on BLUF, for the original convention and its rationale.
- Amazon's published description of its narrative memo culture, as the instructive exception.
- Chip and Dan Heath, Made to Stick, on the curse of knowledge, which is the mechanism behind altitude errors.