Most teams have a person who ends up writing things down. Not because it is their role, but because they are the one who notices that the decision made in Tuesday’s call is already being remembered three different ways by Thursday.
This function is real, it is load-bearing, and it is almost never staffed deliberately.
Not documentation
The confusion is with technical writing, which is a different job. Technical writing produces artefacts for people outside the team: API references, guides, release notes. It is externally facing and it is usually resourced.
What I am describing is internal. It is the short document that says what we decided, what we rejected, and what we were worried about. It is the paragraph at the top of a pull request explaining why this approach rather than the obvious one. It is the note that turns a two-hour argument into four sentences everyone can point at.
None of it ships. All of it determines whether the same argument happens again in five months.
The cost of not having one
Teams without this function have a recognisable set of symptoms.
Decisions get relitigated, because nobody can produce the reasoning that settled it the first time. New members take much longer to become effective, because the context exists only in conversations they were not in. And the team develops a strong oral tradition, which works beautifully until the two people who hold it are on leave in the same week.
The failure is gradual and it is never attributed to its cause. It shows up as the team feeling slower without anyone being able to say why.
Why it is hard to assign
Writing well about technical work requires understanding the work, which means it cannot be delegated to someone outside the team. It also takes real time, which competes directly with the output the team is measured on.
So it falls to whoever finds the ambiguity most uncomfortable, and it is done in the gaps. That person is usually good at it and usually not recognised for it, because the value is a thing that did not happen.
What actually works
The teams that handle this well do a small number of things consistently.
They write decisions down at the moment of decision, in a few sentences, in a place that will still exist in two years. They keep the format short enough that it is not a project. And they treat the writing as part of the work rather than as reporting on the work, which means it happens during rather than after.
Some of them name the role explicitly and rotate it. That helps more than it sounds like it should, mostly because it converts an invisible favour into a visible responsibility.
The output is never impressive. It is a folder of short documents that mostly nobody reads, until the week that somebody does and it saves them three days.
