Your manager reads the first line of your weekly update. Sometimes the second. If something in those two lines suggests a problem they own, they read the rest; otherwise they scroll.

This is not a character flaw and you should stop writing as though it were. They have nine of these. They are reading yours on a phone between two meetings, and the useful question is not how to make them read more — it is what has to be in the part they definitely read.

Almost all of the fix is reordering. You are not writing less. You are moving the same sentences.

The before

A real-shaped update from someone running a hiring process and a design system refresh at the same time.

Weekly update

Hi — here's where things are this week.

Design system: we've completed the audit of the existing
components and started documenting the tokens. Colour and
spacing are done, typography is in progress. Anika has been
doing most of the token work and it's going well. We're aiming
to have the full token set documented by the end of next week,
after which we can start on the migration guide.

Hiring: we did four first-round interviews this week. Two
progressed to the take-home, one declined to continue, one
wasn't a fit. The take-homes are due Monday. I'm slightly
worried about the pipeline — we're getting fewer applications
than we were in February and I think the job description may
be part of it.

Other: I've been pulled into the billing incident review, which
took about a day and a half. Also did the quarterly access
audit.

Let me know if you need anything else.

There is nothing wrong with the information. It is roughly the right amount, it is specific, and it names a real concern. It also fails, because the two things this manager needed to act on are in sentence eleven and sentence fourteen.

What a skimming reader actually extracts

Read the first two lines of that update the way a manager reads them: Hi — here’s where things are this week. Design system: we’ve completed the audit of the existing components and started documenting the tokens.

An audit is complete. Tokens are being documented. Nothing is wrong, nothing is needed, this is fine.

They scroll. And so the sentence we’re getting fewer applications than we were in February and I think the job description may be part of it — which is a request for their help, wearing the costume of a feeling — arrives nowhere.

The day and a half spent on the incident review arrives nowhere either. That one matters because it is the answer to the question they will ask in three weeks about why the token work took longer than you said.

The after

Same facts. Same author. Reordered, and about eighty words shorter.

Weekly update — 17 April

Two things need you. Everything below them is FYI.

1. Hiring pipeline is thinner than it was — four first-rounds
   this week against eight in February. I think the job
   description is part of it. Can you look at the description
   with me for 20 minutes before Wednesday? I'd rather change
   it before the next batch goes out than after.

2. I lost a day and a half to the billing incident review. That
   is fine and I'd do it again, but it comes out of the design
   system time, so the token set now lands 24 April rather than
   17 April. Tell me if that trade is wrong.

FYI:
- Design system: component audit done. Colour and spacing tokens
  documented, typography in progress. Anika is doing the token
  work. Migration guide starts once tokens are finished.
- Hiring: 4 first-rounds, 2 progressed to take-home (due Monday),
  1 declined, 1 not a fit.
- Also completed the quarterly access audit.

The reader who stops after line two knows there are two things and that they are numbered. The reader who reads to the end of item two — which is about forty seconds — has everything they need to act. The FYI block exists for the version of them that is preparing for a skip-level and wants the detail.

What the rewrite actually did

Put the count in line two. Two things need you. A skimmer’s first decision is whether to keep reading, and you can answer that decision explicitly instead of making them infer it. It also bounds the commitment: two is finite, and a finite ask gets read where an unbounded one gets deferred.

Named the FYI as FYI. The bottom half is now formally optional. That is a gift to the reader and it is also self-protective — you have still said the thing, in writing, on the record, and their choice not to read it is now visibly theirs.

Turned the worry into a request. I’m slightly worried about the pipeline asks for nothing. Can you look at the description with me for 20 minutes before Wednesday? asks for twenty minutes, before a day, from them. Hedged concern is the single most common way a competent person’s update fails: it discharges the anxiety of not having mentioned it without ever creating an obligation.

Attached a number to the comparison. “Fewer applications than February” became “four against eight”. Any manager receiving the first version has to decide how alarmed to be with no information. The second version does that work for them, in four extra characters.

Made the interruption cost visible, once, without complaint. I lost a day and a half to the billing incident review. That is fine and I’d do it again, but it comes out of the design system time. The middle clause is doing real work: without it, the sentence is a grievance and the reader spends their attention on managing your morale rather than on the date. With it, the sentence is arithmetic.

Moved the date change into the thing that caused it. The old version never said the date moved at all. It said “aiming to have the full token set documented by the end of next week”, which was already the slipped date, presented as the plan. That is the quietest way to lose a week, and it works until someone checks.

Ended on a question that can be answered with one word. Tell me if that trade is wrong. Silence is now consent to a specific trade you have named. If they say nothing and object in May, you have the sentence.

The line you cannot delegate

Everything above is mechanical. One thing is not.

The first line has to carry whichever piece of news the reader would most want to have been told early. Not the most important item on your project. The item that, if they found out about it in three weeks from someone else, would make them ask why they were hearing it now.

That is usually the slip, the cut, or the thing you decided on your own. It is almost never the thing you are most proud of. Every instinct you have will put the finished work first, because the finished work is what you want to be read as, and the update is not for that.

If you cannot tell which item it is, use this test: which sentence would you be relieved not to have to write? Put that one first.

What this does not fix

A reordered update is still an update sent into a channel. If your manager was never going to open it, the first line does not help — the failure is upstream of the writing and it needs a different repair.

And an update that has been optimised for skimming three weeks running trains the reader to skim. That is fine, mostly; it is what the FYI block is for. But it means that on the week the news is genuinely bad, the format is working against you. On that week, take the first line out of the update entirely and send it on its own, before the artifact arrives. The document is still the record. It just is not how someone finds out.