How to write a pre-read people actually read

A pre-read is the document you send before a meeting so the meeting can start at the hard part. It gets read when it opens with the decision, fits one screen, and names what the reader has to do with it before they show up.

What usually goes out instead is a status report with an invite attached. People open it for the first time while the host is still saying hello, then scroll quietly with the camera pointed at a wall.

Why nobody reads your pre-read

People skip a pre-read when they cannot tell what happens if they skip it.

That is the whole diagnosis. A reader scans your first lines, works out whether the meeting will run identically either way, and acts on the answer. They are not lazy. They are triaging, exactly like you do.

The usual reasons a document fails that test:

• It lands so close to the meeting that reading it means dropping something else.
• It reports what happened instead of asking for anything.
• It runs five pages and the real question is on page four.
• It is written for the record rather than for the six people invited.
• Nothing in the meeting changes based on whether they opened it.

That last one is fatal, and it is the most common. If the meeting proceeds the same way for someone who skipped the doc, you did not write a pre-read. You wrote a handout.

Put the decision in the first three lines

Open with what you need decided, then say what you would do about it.

Background goes underneath. This feels backwards, because the background is the part you built and the part you understand best, and it is genuinely the most interesting bit to the one person who wrote it. The reader does not need your route. They need your destination and one reason to trust it.

Here is the top of a pre-read I would read: "Decision needed: ship the importer without CSV support, or hold two weeks and include it. I recommend shipping now and adding CSV next. Below is what CSV costs us in both directions. If you disagree, bring the number you are using."

Four sentences. Someone could reply to that from a phone in a lift.

A pre-read with no recommendation is unfinished. I have made the case against option menus elsewhere, so here is only the part specific to documents: the recommendation is what makes the rest of the pages readable. Readers work backwards from it. Without one, nobody can tell which of your four sections they are supposed to be checking, so they check none of them and skim to the end looking for the ask.

Keep the required part to one screen

Everything a reader must read should fit on one screen, with the rest clearly marked as optional.

A pre-read has two jobs that fight each other. It has to be short enough to read on a phone between meetings, and complete enough to defend three months later when someone asks where a number came from.

Split it rather than compromising. The top screen carries the argument, which is the recommendation plus whatever makes the recommendation obvious. Everything else sits under a heading called detail, and you say out loud that detail is skippable.

Telling people they may skip the second half does not make them skip it. They were going to skip it regardless. What changes is that they now read the top part properly instead of bailing at paragraph two out of guilt about the other four pages.

The appendix is not wasted either. It is what you paste into the thread when one person wants to see how a number was built, and it is the reason you can answer a challenge live instead of promising to check and get back to them.

Say what the reader should arrive with

Finish the top section with one line naming the action you want before the meeting starts.

"Please read before Thursday" is a wish, not an instruction. Give people something to turn up holding:

• Come with an objection to the recommendation, or say yes in the thread.
• Check the figures in the detail section if they touch your team.
• Reply with anything you know that contradicts this.
• Bring your own number if you think mine is wrong.

The line pays for itself in an unexpected way. When three people reply "agreed, nothing to add", you can cancel the meeting, and cancelling one meeting buys attention for the next few documents you send. People read the writer whose documents have previously given them their afternoon back.

Writing that recommendation line is where my own drafts go soft. Putting a position in front of the whole invite list feels like volunteering to be wrong in public, so I pad it, and the padding is invisible to me until someone asks what I am actually proposing. I rewrite that sentence more than any other in the document; taking the Direct rewrite in Unvent gets it back to the claim I meant to make.

Send it while it can still change something

A day ahead is usually right, and the send has to land somewhere the reader will see it.

Ten minutes before the call is not a pre-read. That is a document you are hiding behind, and everyone can tell.

Four days ahead fails in the other direction. It slides off the bottom of the inbox, you re-send it the night before anyway, and the re-send is where the reading actually happens. So plan for the re-send instead of resenting it.

Put it where the meeting lives. Paste the link into the invite, and into the channel the attendees already watch, with the decision line in the message itself rather than hidden behind a click. A notification that says "pre-read attached" gets ignored. A notification that says "deciding whether we ship without CSV, doc attached, tell me if I am wrong" gets opened, because the second one has already started the argument.

Ninety seconds of summary, then start anyway

Summarize it out loud in ninety seconds, then start the discussion anyway.

Do not ask who read it. That question has one honest answer, nobody is going to give it, and you have spent the opening minute of your meeting making adults feel like students who forgot their homework.

Some teams open with five silent minutes for reading. I think that is an admission the pre-read failed, and I do it anyway, because a room arguing from the same page beats a room arguing from memory.

If it goes unread twice running, believe the signal. Either the document is answering a question nobody in that room actually has, or the meeting does not need to exist. Both are worth finding out, and neither will be discovered by writing a longer document.

Try this on the next one. Write the pre-read as if the meeting has already been cancelled and the document is the only thing left standing. Sometimes you send that version and the meeting genuinely does not need to happen, which is the best outcome on offer and the one nobody will ever thank you for.