Name the Reader
Last month I asked whether anybody is actually reading what a software team now produces. I offered a test for any practice: who consumes this, and what decision does it change? A test is useful, but it leaves a fair question hanging. What do you do on Monday morning?
This post is my answer, confined to one practice. It is short on purpose, because it is one idea: a report with no named reader is noise, and a few small changes make the reports that remain more likely to be read and acted on. These are practices I have found useful and believe in.
The Void I Keep Seeing
A word on how far to trust all of this, which I will say once. The void below is an observation, not a finding. Much of it is second-hand, from conversations with friends and colleagues across the industry and accounts I have seen online, none of which I can verify. I take the shape of the story, not its detail, and I could not find research on it. The studies I came across on AI-written user stories look at their quality, not at whether anyone reads them. The habits that follow are practices, not proven results.
The story goes like this. Some teams follow their agile framework closely, to the letter and out of habit. When AI arrives, the framework still demands its artefacts:
- Tickets and refinement notes.
- Stand-up summaries.
- Sprint reports and retrospective write-ups.
- Status updates.
AI makes each of them almost free to produce. So the ritual carries on and the volume grows. What I keep hearing is that the people involved rarely read, check or challenge what has been generated.
I want to be fair to what is being criticised. The original Agile Manifesto asked for trust, responsiveness and working software. Its principles say:
- Build projects around motivated individuals, and “trust them to get the job done”.
- Working software is the primary measure of progress.
None of that asks for a sprint report nobody reads. Martin Fowler, one of the Manifesto’s signatories, put the objection bluntly in a 2018 keynote: “The Agile Industrial Complex imposing methods on people is an absolute travesty”. He added, “To be fair, I’m part of it, right?”
My complaint is with dogma, and with artefacts produced to satisfy a process, not with any particular framework. I have written about how practice drifts from intent in Are We Rearranging AI Deck Chairs? and in the estimation and PI Planning posts, so I will not repeat it. What is new is what happens once the drifted artefacts cost nothing to make.
What happens is a void. Nobody can say who decided something, or who understood it. The artefacts record that a decision was made, but no person stands behind it in any sense that matters. That costs two things:
- Accountability. In Documentation as Decision History I argued that a decision needs clear attribution: who made it, and who was consulted. A generated refinement note can record a decision in perfect form without anyone having made it. When something goes wrong, there is a trail of tidy documents and nobody who can explain why.
- Creative control. If what the process generates sets the next step and nobody challenges it, the work is shaped by what the process produces and not by people exercising judgement. The team’s direction drifts towards whatever the process and the model produce between them. I made a similar argument in Brushes and Algorithms, about keeping humans in charge of creative direction, in a very different setting.
I should own my part in this. In Beyond Code I recommended using AI to turn meeting notes into status updates, and I still think that is fine when a named author stands behind the result and a named reader has agreed to act on it. The trouble starts when neither exists. The rest of this post is about those two names, and three small habits that go with them.
Name the Reader
The first habit is the one the post is named for. Every report has a named author and a named reader.
- The author is the person who stands behind it. That does not mean they typed every word. It means they have read it, they would defend it unaided, and they can be asked about it.
- The reader is the person who has agreed to act on it, which is a stronger thing than being on a distribution list.
No named reader, no report. If you cannot find anyone willing to be its reader, that is useful information about the report.
This works because of the economics. Herbert Simon put it in 1971, in “Designing Organizations for an Information-Rich World”: “A wealth of information creates a poverty of attention”. Information uses up the attention of whoever receives it. When a report costs nothing to produce, the real price is paid by the reader, and a named reader is the simplest way I know of making the sender account for it. A named author does the same job from the other side. Between them they close the void above: somebody’s name is on the thing, and somebody has agreed to act on it.
Here is a hypothetical, not a real case. A delivery lead drafts a weekly update with AI and sends it to everyone who might care. Before the next one, she asks the programme director, “Will you act on this?” The director says she only needs to know when a date is at risk, and that she would decide whether to move it. The update now has a reader and a reason to exist.
Ask for Something
The second habit is that every report asks for something. At the top, it says whether it needs:
- A decision.
- An answer to a question.
- A risk accepted.
If it needs none of these, it should not be sent.
This works because it makes the author find out why the report exists before the reader spends any attention on it. Another hypothetical: an update that opens with “Decision needed by Thursday: whether to delay the pilot to fix the import fault” can be answered in a minute. One that opens with a list of completed tickets cannot, and often turns out to be asking for nothing. Finding that out is the point.
Action Is the Evidence
The third habit is about how you know a report has been read. My answer is that action is the evidence. The reader does one of four things:
- Decides.
- Asks a question.
- Accepts a risk.
- Says that no action is needed.
Any of these counts, including the last, which is a real answer and costs one sentence.
Opens and read receipts do not count. One small illustration, from email only: since 2021 Apple’s Mail Privacy Protection has been designed to keep senders from knowing when an email is opened, which is one reason an open is an unreliable signal. That says nothing about how people read at work. My concern is with the habit itself: tracking opens tends to make reading performative, with people opening things so they are seen to have opened them.
A report that draws no response over several cycles should be rewritten or retired. Silence is information too.
Written to Be Read, or Kept as Evidence
The fourth habit separates two kinds of writing that are often confused. Most documentation is evidence and context. It exists so that:
- Someone can check a decision later.
- A new colleague or an agent can find the background.
- There is something to point to.
It is not something people are expected to read. That is a good job, and it is the one I argued for in the decision history post: keep the trail so nobody has to reconstruct it.
The trouble starts when the kept-as-evidence material is handed to a human as though it were meant to be read. Nobody reads it, so it fails at the one thing it was sent to do, and because it costs nothing to generate, more of it keeps arriving.
The page a human is expected to read should be short and written by a human who stands behind it, with the detail underneath available for anyone who wants to check. The author has done the reading and the choosing. The reader gets the result and can go deeper if they doubt it. A hypothetical: a sprint review arrives with a forty-page pack generated overnight. If the page that matters is one a person wrote and will answer for, and the forty pages are there to be checked against, each does its own job.
The Manifesto prefers “working software over comprehensive documentation”, while noting that there is value in the items on the right. I read that as permission to keep the evidence while being honest about which pages are meant to be read.
Questions to Ask This Week
- Pick one report your team sends regularly. Who is its named reader, and when did they last say yes, no, or that no action was needed?
- Could its author explain it unaided and say why it says what it says?
- Does it open with what it needs: a decision, an answer or a risk accepted? If it needs none, who would miss it?
- Which documents in your team are kept as evidence, and which are meant to be read? Have the two been mixed up?
- The last time something your process generated shaped a decision, whose judgement was in it?
A Second Pair of Eyes
If it would help to have someone look at this with you, I am happy to talk.
I help teams and leaders work out how to operate now, through process and communication consulting and through mentoring. The first step is a free 15 to 30 minute introductory conversation about the problem you are seeing, where I give you my initial thoughts and proposals. There is no obligation to go any further.
If it makes sense to continue, there are two usual shapes. One is a fixed-price audit of one or two weeks, depending on team size, which looks at process and communication: which feedback loops are broken, which artefacts have no readers, and which practices are doing real work and which are habit. The other is a monthly retainer for ongoing mentoring and advisory work. Even a lightweight second opinion tends to be valuable.
If any of this sounds like your team, get in touch.
A report costs almost nothing to write now. A reader’s attention is still expensive, and it is worth asking who a report is for before you send it.
About the Author
Tim Huegdon is the founder of Wyrd Technology, a consultancy that helps engineering teams and leaders work out how to operate in the AI era, through process and communication consulting and mentoring. With over 25 years of experience building and maintaining software and software engineering teams.