You already know the date is not going to hold. Nobody has asked. There is a review in eleven days where somebody will ask, and between now and then you get to decide whether this is news you delivered or news that was extracted from you.
Those are two different documents with the same facts in them. The second one is worse in every way that matters, and it is the one most people end up writing, because writing the first one requires saying a hard thing on a day when nobody is making you.
Report it the week you believe it, not the week you can prove it
The instinct is to wait. One more sprint, one more conversation with the vendor, and you will either have recovered or have a real number instead of a bad feeling.
That instinct is why bad news arrives late. By the time you can prove a slip, the slip is visible to other people — a dependent team notices their input has not landed, a dashboard turns, someone asks a customer-facing question and gets a hedge. Once the situation is independently discoverable, you have lost the thing that made reporting it valuable. You are no longer informing anyone. You are confirming.
So the trigger is belief, not proof. The week you stop believing the committed date, you write the update. You are allowed to be wrong. Being wrong early is recoverable; being right late is not.
What “red” should mean
The word is worth pinning down, because half the arguments about status colours are arguments about definitions.
Useful version: it is red when the committed date or scope will not hold, and recovery requires a decision that is not yours to make. If you can fix it inside your own authority — reorder your week, drop something you own, work the problem — it is not red. It is a Thursday.
That definition makes red mean somebody has to do something, which is what turns a status colour into a document that gets acted on rather than logged. It also stops the slow inflation where everything is amber forever and the colour carries no information at all.
The update, in full
This is the whole thing. Subject line included, because the subject line is where most of it is decided.
Subject: Atlas migration is red — new date 12 October, need a scope decision by Thursday 17 Sept
Where it is. Atlas will not be done on 28 September. The realistic date is 12 October, two weeks late. I am confident in that date to within about three days.
Why. The account-merge step is roughly three times the work we estimated. We scoped it from the schema and did not account for the four legacy account types, which need their own migration path and their own tests. That was my estimate and it was wrong; I did not find it until we ran the first dry migration on 1 September.
What I have already done. Pulled Dario off reporting work onto the merge path. Cut the admin backfill from scope, which saves about four days and nobody outside the team will notice. Dry migration now runs nightly so we find the next surprise in a day rather than a fortnight.
What I need, and from whom, by Thursday 17 September. Priya: a decision between two options. Option A, we hold 28 September and ship without the two rarest legacy account types, which affects about 40 accounts who would keep using the old flow until November. Option B, we take 12 October and ship everything. I recommend A. Both are survivable; I do not want to pick this one alone because it is a customer-visible call.
What happens if nobody replies by Thursday. I proceed with Option A and we tell the affected accounts on 21 September. Reversing that after the 21st costs a week.
What I am not asking for. More people. Adding anyone to the merge path now costs more than it returns.
Next update. Friday 18 September, or immediately if the date moves again.
Six hundred characters of it are load-bearing. The rest is scaffolding.
Why it is worded that way
The subject line carries the whole document. Colour, new date, ask, deadline. Someone who reads nothing else has the three facts they need and knows a reply is expected. If your subject line is “Atlas update — week of 8 September”, you have written a filing label.
“Where it is” comes first and is one sentence. No context, no preamble, no paragraph explaining that the team has worked extremely hard. Context after the fact, always. A reader who gets two lines of background before the news has already decided the news is manageable, which is the mechanism buried bad news runs on — the fact was included and not communicated.
The new date has a confidence attached. “12 October, confident to about three days” is a different commitment from “12 October”, and it is the honest one. It also pre-empts the question you would otherwise be asked in the review, which is whether this date is real or the same kind of date the last one was.
“What I have already done” is short and specific. It exists so the reader knows which decisions are still open. It is not a defence, and the moment it starts reading as one — three paragraphs about the effort involved — it has become a document about you rather than about the project.
The ask names a person, two options, a recommendation and a day. Not “we need to discuss scope”. You are not offloading the judgement; you are stating yours and asking someone with the standing to own the customer-visible half of it.
“What happens if nobody replies” is the part that works. Without it, Thursday is a preference. With it, silence is a choice with a known outcome, and a reader who dislikes that outcome has to act. It also protects you: when the reply arrives on the 22nd, the document already said what would happen.
The paragraph most people delete
It is this one:
That was my estimate and it was wrong; I did not find it until we ran the first dry migration on 1 September.
It gets deleted because it reads like handing someone a weapon. Everything in you says to write “the account-merge step proved more complex than anticipated” instead, and the passive voice will do its job — no one is at fault, complexity arrived on its own.
Delete it and you have not removed the question of cause. You have left the reader to supply one. What a reader supplies, absent a stated cause, is almost always some version of they were not on top of this — worse than the true answer, and impossible to argue with because you never raised it.
Naming the cause plainly also does something the hedged version cannot: it makes the rest of the document credible. A person who tells you the unflattering half of the diagnosis is a person whose date you can believe. That is the entire trade, and it is a good one.
Two limits, both real. Name the cause once, in one sentence — a paragraph of self-examination stops being information and becomes a performance the reader has to respond to. And name a cause, not a person: “we scoped it from the schema” describes a method, and if the method was yours, say so and stop there.
The version that failed
Subject: Atlas — update
Wanted to give everyone a quick view on Atlas. The team has made good progress on the core migration and the new schema is in place. The account-merge work has turned out to be more complex than initially anticipated, particularly around some of the legacy account types, and we are working through the implications for the timeline. We remain committed to delivering a high-quality migration and will keep you posted as things develop. Happy to discuss in more detail if useful.
Every fact in the real update is technically present in some form. Nothing in it can be acted on.
There is no date, so nobody can tell whether their own plans are affected. There is no ask, so nobody has anything to do. “Working through the implications for the timeline” means the date has moved and takes care not to say so, which every reader senior enough to matter correctly translates as this is late and they are not ready to tell me by how much. “Happy to discuss” hands the initiative to the reader; the ones who take it book a meeting, which is how a document written to avoid a conversation produces a worse one with less preparation.
The failure is not the writing. The author had not yet decided to say the thing, and wrote a document around that gap.
What this costs
It costs you a durable, dated, quotable record that the project went red on 9 September and that the estimate was yours. That record does not expire. A year from now, in a conversation you are not in, someone can open it. The same permanence that makes a written update useful is what makes this one uncomfortable.
It costs you a period of increased attention. Reporting red reliably produces more questions, more check-ins, and occasionally a meeting you did not want. That is not a malfunction; it is the system responding, which is what you asked it to do.
And it can be read as blame by anyone whose work is in the causal chain. Name methods and decisions rather than people, and where the decision was yours, say so first.
Against that: the alternative is arriving in the review on the 20th with a slip someone else has already noticed, and spending that meeting establishing why they are hearing it now rather than deciding what to do. That conversation is longer, worse, and the one that changes how your next date is read.
If it is already too late
If the news has already leaked — a dependent team asked, a dashboard turned, someone forwarded a question — write the same document anyway, today, and do not open it by acknowledging that people have started to notice. Open with the date. The sequence is spoiled; the content is not, and the content is what people will still be reading in November.