No surprises
The plan is live and something has changed. What an update is actually for, and how to escalate while it is still cheap.
Everything in this course so far happens before you commit. Framing, options, a range, a pre-mortem — all of it is thinking done in advance, and all of it is the easy part.
It is now week three. The deprovisioning spike you scheduled came back, and the answer is the bad one: behaviour really does differ per identity provider, each needs its own handling, and you are heading for the top of your range rather than the bottom.
Note what just went right, before we get to what you do about it. You know this in week three rather than week seven, because you retired that risk instead of monitoring it. The pre-mortem already paid for itself. What remains is entirely a communication problem, and communication problems are where good plans go to die.
What an update is actually for
Most status updates are written as evidence of effort. They list what the author did that week, in roughly the order they did it, and they are read by nobody because they answer a question nobody asked.
An update has exactly one job:
It follows that the unit of an update is not activity, it is change against the plan. “Worked on the SCIM integration” tells a reader nothing they can act on. It does not say whether the plan still holds. Three sections, and they can be three sentences:
- What changed against what we said would happen.
- What it means for the date, the cost or the scope — stated, not left for the reader to infer.
- What I need from you, and by when. Often nothing, and saying so explicitly is worth a line.
If nothing changed, the update is one sentence saying so, and that is a complete and useful update. Padding it out with activity to look productive is how you train people to stop reading — which costs you exactly on the week when something has changed.
Why bad news travels slowly
There is a reason the honest update is harder than it sounds, and it is not a personal failing. It is structural, and it has been studied.
Ron Westrum, working on safety in aviation and healthcare, classified organisations by how information moves through them, and found three recurring types (DORA on generative organizational culture):
- Pathological, organised around power. Information is hoarded, withheld for political advantage, or distorted so the sender looks better. The person who brings bad news pays for bringing it.
- Bureaucratic, organised around rules and turf. Information stops at departmental boundaries. The messenger is not punished so much as filed.
- Generative, organised around the mission. Information flows, teams bridge, and the person who surfaces a problem early is treated as having done their job.
The reason this matters beyond vocabulary: Westrum’s typology was picked up by the DORA research and reported in Accelerate, where generative culture turned out to predict software delivery performance. Not correlate vaguely with pleasantness — predict delivery. Whether bad news reaches the people who can act on it is a performance characteristic of an organisation.
Where people get burned
You cannot unilaterally change which type you are in, and pretending otherwise is how people get hurt. What you can do is notice it, because it tells you how much care a given message needs. In a generative team, “the spike found trouble” is a sentence. In a pathological one, the same message needs the evidence attached, the decision request stated, and a written record of when you sent it. Same information, different amount of armour.
Escalate while it is still cheap
Escalation feels expensive, so people defer it, and deferring it is what makes it expensive. The asymmetry is worth stating plainly:
Escalating early costs a little social capital, and it is reversible — if the problem resolves itself you have spent a small amount of credibility on being cautious, and most reasonable people do not hold that against you. Escalating late costs the schedule and the trust, because the person you told now knows two things: the project is late, and you knew before they did. The second is the one that lasts.
The good news is that you already decided when to escalate. In the pre-mortem you gave every monitored risk an owner, a trigger and a response. That trigger is the escalation rule, written down at a moment when you were calm and nothing was at stake. The discipline is simply honouring it when it fires, on the day it fires, rather than negotiating with yourself about whether it really counts yet.
Escalation is not complaint
The difference is one thing: an escalation carries a decision request.
“I’m worried about the deprovisioning work” is a feeling. It hands the reader an emotion and no way to help, and it invites the reply that means nothing — “thanks for the heads-up”. Compare:
“The spike finished. Deprovisioning needs per-provider handling, which puts us at the top of the four-to-nine range rather than the bottom — call it eight weeks. Two options: I cut Entra from the first release and we ship Okta-only in six, or we hold the scope and I give you eight. I need a call by Thursday because the Entra work starts Friday.”
That is the same bad news. But it names what changed, states the consequence rather than implying it, offers a decision with real options, and puts a date on when the decision stops being free. Nobody reading it has to do any work to know what to do — which is the entire difference between being informed and being told.
Retrieval check
Without scrolling up: what is the single test for whether an update did its job, and why does escalating early cost less than escalating late — name both costs.
Check your answer
The test: nobody learned something late that you knew early. Not whether it was thorough, timely or well-formatted.
Early escalation costs a little credibility and is reversible — you spent it on being cautious. Late escalation costs the schedule and the trust: the reader learns the project is late and that you knew before they did, and the second cost is the one that outlives the project.
Now apply it: write the week-three update
Hands on
Deliver the bad news properly
Done when: You have an update that states the change, its consequence and a decision request with a deadline — and that a busy reader could act on without asking you anything.
- Write what changed in one sentence, against what you previously said. Not what you did — what is now different from the plan on record.
- Write what it means, in the units the reader cares about. For a VP of Sales that is the date and the deal, not the number of identity providers.
- Write the decision request: at least two real options, each with its cost. If you only have one option you are reporting, not escalating — and if one option is obviously correct, say which and ask them to confirm.
- Put a date on the decision, and say what happens on that date if nobody answers. You have done this before — it is the assumption-with-deadline from lesson two, reused.
- Now reread it as the recipient. Is there anything in it that makesyou look better at the cost of being less clear? Cut that. It is the most common thing in a real update and the hardest to see in your own writing.
- Bring it into the chat. I’ll read it as the VP would — checking whether I could act on it without replying to ask a question, which is the bar.
What this does not cover
The plan survived contact with reality and the people around it, and eventually it ships. Which raises a question the estimate lesson left open and could not answer at the time: it told you to build a range from what comparable work had actually taken, and then admitted that history usually does not exist.
It does not exist because nobody records it at the end. You are about to be in a position to fix that for whoever estimates next — including yourself — and the reason almost nobody does is not that it takes long. That is where this goes next.
Read this next — primary source
Generative organizational cultureDORA (dora.dev) — free, and short
DORA’s write-up of Ron Westrum’s typology, which originates in his 2004 paper “A typology of organisational cultures” in Quality & Safety in Health Care — the journal now called BMJ Quality & Safety — and reached most engineers through Accelerate. Read it for the information-flow argument: the claim is not that nice cultures perform better, it is that cultures which let bad news travel perform better, which is a much more useful and much more testable idea.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.