Six re-entries between the decision and the code

You can run that count on your own last feature in forty minutes, and I am going to show you how. More usefully, you will be able to name what goes at each step, because this is not a mist that evaporates at random: it is always the same four things, and always in the same order.

Three parts, in the direction of travel. What happens between the two dates. What is lost at each step. And why fifteen years of wikis changed none of it.

What happens between the two dates

The chain, as it exists in just about every product team I know:

• ↓The meeting. Forty minutes, four people, one decision.
• ↓The notes, taken during it, or just after, from memory.
• ↓The Slack summary, for the people who were not there.
• ↓The ticket.
• ↓The spec or the PRD, because a ticket is never enough.
• ↓The UX document, then the implementation plan.

Six manual transcriptions. Not copy-and-paste: six rewrites, each one done by reading the previous one.

This is what I call a re-entry, as opposed to a transformation. The distinction is the subject of the last part, because it only means something once you have seen what the chain costs.

What is lost, at each step

The why goes first. It falls between the notes and the Slack summary. The justification takes three sentences to write and interests nobody on the day: everyone was there, everyone knows. Three weeks later, only the what is left.

The alternatives follow. Three ways of doing it had come up, two were ruled out for good reasons, and the summary keeps only the survivor. Six months later somebody proposes a dead option again and the team reruns the whole debate without knowing it is rerunning it. I have watched that happen twice on the same subject.

“That will not work for multi-space accounts,” said at minute 26 by the only person in the room who knew. A ticket has no field for that. You rediscover it in QA.

The source goes last, and it is the worst one. By the time you reach the spec, nothing links the requirement to the sentence that produced it. When somebody asks eight months later on what basis this was decided, all that is left is the memory of four people. Four memories of a forty-minute meeting make four different meetings.

What bothers me is that nobody did bad work. Each person did what was asked of them: they summarised. To summarise is to discard — that is the definition of the word. The problem is not that we summarise badly. It is that we summarise six times in a row.

Why fifteen years of wikis changed none of it

The usual answer to all this is knowledge management. A better wiki. A naming convention. A PRD template everyone commits to filling in. A Slack channel reserved for decisions.

I have been that person. I wrote the PRD template, with the mandatory sections and the worked example at the top. It lasted five weeks.

It never holds, and it is not a discipline problem. A wiki is a warehouse: it assumes information arrives well formed at its door and only has to be put in the right place. It never arrives well formed. It arrives as forty minutes of people talking over each other, as Slack threads, as sales feedback slipped into a DM, as a thirteen-second voice note. Filing costs almost nothing. Shaping is what costs, and shaping is exactly what no wiki does.

Knowledge management answers “where do I put this?”. The real question is “who transforms this, and into what?”.

Re-entering and transforming

Which leaves the distinction promised earlier. It comes last because it only makes sense once you have seen the cost: two things that get confused constantly because from the outside they look alike.

To re-enter is to reproduce by hand information that already exists somewhere else, in another format. It creates nothing. It costs time, it introduces drift, it breaks the link to the source. The six steps at the top are six re-entries.

To transform is a real passage from one state to another, deterministic, that keeps its origin. A transcript becomes a list of attributed statements. That list becomes a set of candidate features. A feature becomes a technical scope. At every passage, the output knows where it came from.

The practical difference fits in one sentence: a re-entry cannot be replayed. If you find a mistake at step 5, you cannot go back to step 2 and rerun it — six people would have to redo their work. A transformation can.

A more unpleasant consequence: as long as the chain is made of re-entries, automating it is pointless. You will get a machine that summarises a summary of a summary, with the same losses, faster. That is in fact what most automatic meeting-notes tools do. They replace step 2 and leave the other five alone. The gain is real and it is tiny.

What is left once the re-entries are removed

Almost nothing for a human to do. Almost.

The decisions are left. Is this candidate feature real, or did the system take an offhand sentence seriously? Are we doing it? Is this the right scope? Does this UX constraint pass?

Those are the only moments where a human brings something no machine brings. Extracting, deduplicating, reformatting, propagating, linking: we do it by hand for historical reasons, not because it is human work.

Hence the criterion I am most interested in right now:

The number of human touchpoints in a chain should equal the number of decisions to be made.

In a normal product team it is six or seven for a single decision. That is the ratio to watch. Not time spent in meetings, not velocity, not backlog size. How many times somebody touches the information without deciding anything.

The objection, and it is a good one

“A machine that extracts features from my meetings is going to make things up.”

Yes. Regularly. I have watched a system turn “you could imagine that, one day, maybe” into a perfectly formed candidate feature, technical scope and definition of done included. It was immaculate. It should never have existed, and it took me twenty seconds to notice — which means somebody less attentive would have let it through.

That is why the conclusion is not “let us automate the chain”. It is: automate the transformations, keep the human decisions — all of the decisions and nothing but them.

Two conditions, non-negotiable. Gates first: nothing reaches a workspace or a repository without a person having approved it. Traceability second: every item produced carries its source — the meeting, the timestamp, the exact sentence — so that whoever decides decides on the evidence and not on how much they trust the system.

A machine that decides is a machine you cannot audit.

I am not neutral on this. It is the thesis of Calliops and the reason I started it.

The exercise

Take your last shipped feature. Walk back from the ticket to the meeting where it was decided. Count the re-entries, then at each jump ask yourself which of the four went: the why, the alternatives, the constraints, the source.

Mine was six, and by the fifth the why had already gone. Only the what was left.

Tell me your number.