Think of the analyst who opens the weekly sales dashboard first thing on Monday and has to tell a director whether the numbers can be trusted. She does not care how your pipeline is wired. She wants to know one thing: is today’s data safe to quote? Most data summaries are written for “stakeholders” in general and read by nobody. This FAQ walks through how to write a data summary, status note or pipeline update for one specific person, in the order she would ask the questions.
Who exactly is the reader, and why does it matter?
Because the answer decides everything else. A summary for the on-call engineer lists failed tasks and timestamps. A summary for the Monday analyst says whether the revenue table is complete and which columns to treat carefully. Mixing the two produces a wall of text that serves neither. Write the reader’s name, or a role plus a habit, at the top of your draft: “Monday analyst, checks at nine, has ten minutes, quotes numbers to a director.”
That single line becomes your filter. Every sentence either helps that person decide or it goes.
What is the first thing she needs to see?
A verdict. Not a dashboard of twenty tiles, a sentence: “Yesterday’s orders are complete and safe to use,” or “Yesterday’s orders arrived late; figures before noon are partial.” Put it first, in plain words, and treat it like a headline.
Only then add the supporting detail. If she stops reading after the first line, she should still behave correctly. This is the data equivalent of the inverted pyramid in journalism, and it respects her limited minutes.
How much technical detail should I include?
As much as changes her decision, and not a word more. She needs to know that a source system changed a field format only if it affects a number she will quote. She does not need the name of the failing job or the retry count. Offer a link or a short “details for the engineering team” block at the bottom, so the curious can dig and the busy can skip.
A useful trick: after drafting, delete every sentence that she could not act on, and see whether the note still works. If it does, those sentences belonged in a log, not a message.
How do I explain data quality without scaring her?
Be specific about what is wrong and equally specific about what is fine. “Three percent of rows have no region code” frightens people; “Rows without a region code are listed under Unassigned, so regional totals add up but may undercount the north” tells her what to do. Quantity matters less than consequence.
If your team uses automated checks, mention only the ones whose failure she would feel. Articles such as our practical walk-through of declaring and testing expectations on tables explain how those checks are set up. In a summary for the analyst, however, the check names are noise. Translate each one into the question it answers: “Are all stores reporting?” “Did prices stay in a sane range?”
What if there is nothing to report?
Say so, in one calm line. A boring summary is a successful one, and she will learn to trust a sender who reports good days as faithfully as bad ones. Skipping the note on quiet days teaches the reader that silence might mean trouble, which is the opposite of the habit you want.
How do I handle surprises that cannot yet be explained?
State what you know, what you do not, and when she will hear next. “Order counts dropped sharply after midnight. We have not found the cause yet. Treat today’s totals as provisional; we will update by two o’clock.” That is three short sentences, and each one answers a question she would otherwise have to send you.
Observability tooling can catch many such surprises early, and posts like this look at spotting broken data before it reaches production describe the detection side. What the tools cannot do is decide how to tell one worried person about it. That remains a writing job.
Should I use charts?
Only if the reader would otherwise have to imagine a shape. One small chart that shows “yesterday against a normal day” can replace a paragraph. Ten charts replace nothing; they move the work onto her. When in doubt, choose a sentence with a number in it over a picture, because she can paste a sentence into her own email.
Does this approach work for people who are not analysts?
Yes, but you will have to write a second note. The finance lead who signs off month-end cares about reconciliation windows and cut-off times. The product manager wants to know whether an experiment’s data is clean enough to read. Each is a distinct person with a distinct question, and a single message cannot answer all of them without bloating. Write several short ones instead of one long one. The extra effort is smaller than you expect, because each note is tiny.
Where can I practise writing for one reader?
Anywhere you can get honest feedback. One low-pressure option is keeping a personal blog about your daily data work. A platform such as iBlogUp, a writing site where every author gets a personal subdomain and readers can keep up through an RSS feed, gives you a place to try explaining a pipeline incident or a modelling decision to an imagined newcomer, and to see whether anyone actually finds it useful. Treat each post as a letter to one colleague who is smart but new.
The habit transfers directly. Once you can explain a late load to an imagined newcomer without jargon, the Monday note becomes easy.
What does a good summary look like in practice?
Here is a skeleton you can paste into your team wiki:
- Verdict. One sentence: safe, partly safe, or not safe to use.
- What changed. Only what affects numbers she might quote.
- What to do. Wait, use with a caveat, or use as normal.
- What happens next. Who is working on it, and when she will hear again.
- Details. A link for anyone who wants the technical story.
Five lines, a few minutes to write, and a reader who feels looked after.
What about the first week on a new team?
The same method helps a newcomer. Instead of writing a long tour of your data estate, choose the one person who is joining and ask what she will be asked in her first fortnight. If she will field questions about customer counts, explain where that number comes from, which table is the trusted one and which old copy to avoid. Leave the other forty tables for later. She will thank you for the restraint, and she will come back for the rest when she needs it.
How do I know it is working?
Ask her. After a month, check in: Which part did you read? What did you skip? Was there a morning you wished I had said something different? Her answers will tell you more than any dashboard of open rates. You may find she reads only the verdict, which is fine, or that she forwards your note to her director unchanged, which means you have written it well.
Also watch for the reverse signal. If she keeps asking the same follow-up question, put the answer in the note. A repeated question is the reader editing your draft for you.
What is the main thing to remember?
Data work produces outputs for people, and people read one at a time. Picture the specific person, think about her question, her worry and her time, and the summary gets shorter, clearer and kinder almost on its own. The rest of the craft, tooling, tests, schedules, matters because it keeps that one note truthful.
