Walk into almost any engineering organisation today and you will find the same documentation story. There is a large wiki, a few well-loved pages, a graveyard of stale ones, and a quiet, widespread agreement that people mostly ask a colleague instead of reading. The interesting shift in the last few years is not a new tool. It is a change in how careful teams frame the job: from “document everything” to “write this page for a named person”. Here is a status check on that habit: what is driving it, and what a practical team can do with it without buying anything.
Where documentation practice stands
The encyclopedia model is still dominant. Teams create a space, assign sections, and try to cover the system the way a reference book would. It feels responsible, and for some material, such as API references and policies, it is the right shape. But for everything involving a human making a decision or learning a new area, encyclopedic pages have a poor track record. Readers arrive with a specific problem, scan a long page for ten seconds, and leave to ask someone. Most practitioners will recognise that pattern without needing a survey to confirm it, and I will not pretend to quote a figure for it.
The drivers behind the shift
Three pressures are pushing teams toward person-sized writing. The first is remote and hybrid work, which removed the habit of leaning over to ask a neighbour; documents now carry more of the teaching load. The second is churn in tooling, which makes comprehensive pages age quickly, while a short note for one reader is cheap to refresh. The third is a broader movement toward plain language in technical communication, which holds that clarity is a measurable courtesy rather than a stylistic nicety. None of these is new on its own. Together they have made the question “who exactly is this for?” harder to avoid.
What a named-reader page looks like in practice
Take a machine learning team handing a trained model to a business analyst who will use its predictions in a weekly report. The encyclopedic version describes the architecture, the data pipeline and the evaluation methodology. The named-reader version opens with the analyst’s question: “Can I trust this number on Monday morning?” It explains what the output means, when it tends to be off, how to tell and whom to call. It runs a page and a half. Our full roadmap for data scientists and engineers working on model operations covers the wider landscape; the analyst’s page is the small piece that sits at the end of it.
The same trend in operations teams
Operations groups are applying the idea to runbooks, status messages and training. A message written for the executive who fields customer calls reads differently from one written for the engineer in the incident channel, and good teams now keep both. Training follows the pattern too. A short learning plan aimed at one trainee, such as a service-desk analyst moving toward automation work, tends to be completed more often than a catalogue of modules; for a worked example of structured training, see our write-up on the training a modern IT professional needs for automated operations.
Why the shift is slower than it should be
Habit is the main obstacle. Writing for everyone is comfortable because it cannot be wrong in a single way; any complaint can be answered with “it is in there somewhere”. A named-reader page can be wrong visibly, which is uncomfortable but useful. A second obstacle is ownership: encyclopedic spaces assign pages to systems, while person-sized notes need an owner who understands the reader. A third is metrics. Page views reward long, searchable pages, and they say little about whether the reader was helped. Organisations that measure the wrong thing keep getting the wrong writing.
Practical moves for an ordinary team
You do not need a programme. Try three small things. First, add a line at the top of every new document that names its reader and the decision it supports. Second, when someone asks a question twice, write the answer for the person who asked rather than adding a section to the main wiki. Third, retire one long page per month by replacing it with two short ones aimed at different readers. After a quarter you will have a better feel for which pages earn their keep.
What consultants and trainers are seeing
From the advisory side, the most common request is no longer “write us a policy” but “help our new leads understand what is expected of them in their first month”. That is a one-person question. Engagements that start from it tend to produce shorter, more practical material, and the clients’ staff actually open it. Whether this is a lasting trend or a phase is hard to say; the sample any single firm sees is small and biased toward teams already open to change. Treat the direction as plausible rather than proven.
Where writers are putting this work
Beyond internal wikis, a growing number of practitioners keep a public notebook of what they have learned. Platforms differ; one example is iBlogUp, where authors post stories to a subdomain that is theirs and followers can subscribe by feed. It describes itself as free, so verify that on its site. Public writing is a handy test bed, because the discipline of choosing a reader is the same whether the audience is a colleague or a stranger.
Risks and limits worth naming
The approach has real limits. Some material genuinely needs to be comprehensive: safety procedures, legal obligations, API contracts. Do not trade those for friendly short notes. There is also a risk of fragmentation, with many small pages and no map. Solve it with a simple index that groups pages by reader rather than by system. And there is a human risk: choosing the wrong person, such as the loudest stakeholder, and writing for them at the expense of those who actually need help. Check your choice against the questions that really arrive.
An example of the cost of skipping it
Picture a platform group that publishes a forty-section guide to its deployment process. A product engineer, new to the company, opens it on a Thursday because a release is due on Friday. She needs to know whether she can ship a small change without asking anyone. The answer exists, split across three sections and a footnote. She asks in chat instead, and a senior engineer spends ten minutes answering a question the guide technically covers. Repeat this across a year and the hidden cost is easy to imagine, even if no one logs it. A page titled for her, with her question as its first line, would have settled the matter in under a minute.
Where this is heading
Expect the next few years to look less like a revolution than like a slow tidying. The tooling will keep changing, but the useful question will stay the same: who is this for, what are they worried about and how long will they give it? Teams that ask it by default will find their documentation shrinking and their onboarding speeding up. Teams that skip it will keep building wikis that people search once, distrust and abandon.
If you want a quick temperature check, pick three pages your team links to most often and read each opening paragraph. Can you tell who it is for? If not, you have your first rewrite. Choose the person, say it out loud, and begin.