TL;DR / The Direct Answer: When something's blocked and you have to explain it upward, lead with the answer, not the backstory. Give AI the real technical reason and ask it to rewrite it "bottom line up front" — status and revised ETA in the first line, the explanation underneath. It's the same answer-first method McKinsey consultants use (the Minto Pyramid), and it's the difference between sounding in control of a problem and sounding like you're making excuses.
Who this is for: Anyone who has to explain a technical delay to a non-technical senior — engineers, but also consultants and analysts whose work gets blocked by things their reporting manager doesn't see.
Skip this if: Your manager is technical and you're already comfortable giving crisp, answer-first status updates.
Note: AI pricing, plan names, and product features can change quickly. Re-check official pages before you pay for a tool or choose a plan.
Why This Conversation Goes Wrong
You know exactly why the task is late. The migration is blocked on a flaky third-party API. The "small change" touched a module with no tests, so you're untangling ten years of assumptions. The reason is real and reasonable — and then you open your mouth and two things go wrong.
First, you start at the beginning: the background, the investigation, the technical detail, and finally — four minutes in — the actual status. Your non-technical reporting manager checked out after sentence two. Second, because you feel the pressure, you over-explain, and a long technical defence sounds like an excuse even when it's the truth.
The fix isn't to say more. It's to invert the order. Lead with the bottom line; put the explanation underneath for whoever wants it.
The Method: Bottom Line Up Front
Two of the most respected communication frameworks in the world say the same thing. The military calls it BLUF — Bottom Line Up Front. McKinsey calls it the Minto Pyramid — start with the answer, then support it. Both exist because senior people are busy and want the conclusion first.
For a status update, "bottom line up front" means four things, in this order:
- Status — one phrase: on track, at risk, or blocked.
- Revised ETA — the new date, with honest confidence.
- The blocker, in plain terms — what's in the way, no jargon.
- The plan — what you're doing about it.
Notice the technical backstory isn't even on the list. It goes below the fold, for anyone who asks. Most engineers do this exactly backwards — backstory first, status last. Flipping it is the whole trick.
The Prompts
Each prompt below follows the same shape — Role (who the AI should be), Task (what to do), Context (your situation), and an Example when the format matters. That structure is what reliably gets a usable answer instead of a vague one.
1. The BLUF Compressor
Role: You are a sharp project lead who briefs busy executives "bottom line up front." Task: Rewrite the technical reason below as a status update. The FIRST line must state the status (on track / at risk / blocked) and the revised ETA. Underneath, give the blocker in plain business English (no jargon) and my plan. Under 70 words, confident and factual — not apologetic, no "so sorry for the delay." Context: The reader is my non-technical reporting manager. The real technical reason (written like I'd tell another engineer): [PASTE]
2. The SCQA Framer (when they DO want the why)
Sometimes the explanation matters — a steering call, a client review. Minto's structure for that is SCQA: Situation, Complication, Question, Answer. It walks a non-technical audience to your conclusion without losing them.
Role: You are a McKinsey-trained communicator using the Minto Pyramid's SCQA structure. Task: Frame the situation below as a short SCQA brief for a non-technical audience: - Situation: the one-line context everyone already agrees on. - Complication: what changed / what's blocking us. - Question: the decision or question that creates. - Answer: my recommendation and the revised timeline. Two or three sentences each, plain English. Context (the raw situation): [PASTE]
3. The Analogy Generator
Role: You are great at explaining technical things to non-technical people with everyday analogies. Task: Explain the technical blocker below using ONE everyday analogy (traffic, plumbing, moving house — not computers). Two sentences for the analogy, then one sentence on what it means for the timeline. Context: The listener is my non-technical reporting manager. The blocker: [PASTE]
4. Deliver Bad News (own it)
Role: You are a calm, accountable engineer delivering bad news to your reporting manager. Task: Draft a 4-5 sentence message about a deadline slip. Lead with the new date and the recovery plan. Own it without grovelling — honest, calm, accountable, no over-apologising. Context: What slipped and why: [PASTE]
Before and After: 4 Real Situations
1. The Dependency Block
Your instinct (backstory first):
"So I was working on the payments piece and their team's sandbox kept returning 500s, I checked the logs and..."
BLUF version:
Blocked — revised ETA Thursday. We're waiting on another team's sandbox environment, which is currently failing. I've raised it with them and have a workaround ready if it's not fixed by tomorrow. I'll confirm by EOD.
2. The Hidden Tech Debt
BLUF + analogy:
At risk — revised ETA Friday. The change itself is small, but the part of the system it touches is fragile: it's like repainting one wall and finding the wiring behind it needs redoing first. Rushing it risks a production bug, so I'd rather take two extra days and do it safely.
3. Scope Creep
BLUF, non-blaming, with a decision:
On track for the original scope; at risk for the additions. Three new requirements came in this week. I can ship the original version Friday and take the additions as a fast follow — or hold for the full set. Which would you prefer?
4. The Flaky Third Party
BLUF, in control:
At risk — revised ETA Wednesday. We depend on an external service that's been intermittently down this week, outside our control. I'm adding retry-and-fallback handling so our side degrades gracefully instead of failing. That adds a day.
Same facts each time. The difference is you sound like someone managing a problem, because you led with the bottom line instead of burying it.
When NOT to Use This
- Don't polish away a real risk. A smooth four-line update that hides a project quietly going off a cliff is worse than an awkward honest one. Use the method to communicate bad news clearly, not to bury it.
- Don't invent an ETA to sound confident. If you don't know yet, the honest version is: "Can't give a reliable date until I've scoped it — I'll have one by tomorrow." A made-up date is just a future broken promise.
- Escalations need judgement, not wording. If another team is failing repeatedly, the phrasing is the easy part; the real move may be a direct escalation, which is a decision.
Which AI Does This Best?
- Claude is strong at plain-English translation and at holding a calm, non-grovelling tone — good default.
- ChatGPT works well; tell it explicitly "no apologies, no filler" or it opens with "I sincerely apologise for the inconvenience."
- Gemini is handy if your updates already live in Google Docs or Chat.
Why I Wrote This
I'll be honest: I'm not the engineer whose migration is blocked — I'm an automation consultant. This section of the site exists because a software engineer I trust told me there was nothing here for the parts of his job that aren't writing code, and this is one of the biggest: explaining yourself upward.
So I didn't invent the approach. "Bottom line up front" comes from military communication; the Minto Pyramid and SCQA come from McKinsey — both built for exactly this problem of getting a busy senior person to the point. I shaped the prompts around them and tested them.
What I do live, every week in consulting, is the work of translating something technical or complicated for a manager or a client who doesn't share the jargon. If this helps you walk out of a status call looking like the person who's on top of it, it did its job.