Family C: Systems

Everything so far survives exactly as long as the person does.

A term that has been defined well, a process that has been running the same way for three years, a formula that decides something correctly forty times a week: all of that can live entirely inside one human being, work perfectly, and vanish on a Friday. The organization will not experience this as a loss. It will experience it as the new person being slow, for about eighteen months, and then it will stop noticing because nobody who remembers the before state is still holding the queue.

This family is the answer to that, and it has three isms because there are three separate questions and the creed used to run them together.

The first is where knowledge sits. Something known by one person and recorded nowhere is a fact with a single copy, and the way you find those is not by asking people what they know, which produces nothing usable, but by watching which questions have exactly one possible recipient. Every organization generates that signal all day and none of them collect it.

The second is which direction information moves. A fact sitting in a system that nobody knows to look for has not been recorded in any useful sense, and the failure lands hardest on the people who do not know what they do not know, which is the people who most need it. That is the strongest argument in this family and it leads directly into the largest revision in this book, because the obvious fix, which is to send everything to everybody, spends a resource that turns out to be the binding constraint.

The third is who does the work. Every fact a system can derive is a fact a person does not have to supply, and every fact a person does not have to supply is one they no longer look at.

Those three sit together because they are the same trade viewed from three angles. In each case something is being moved out of a person and into a structure, and in each case the move is genuinely good and takes something with it that nobody counted, because the thing taken had no name and therefore no baseline.

There is one more thing these three share, and it is why they are grouped rather than scattered. All three cross a boundary between a person and a structure, and in every case the crossing is made by an artifact: a document, a notification, a derived field. The artifact is never the thing itself. It is a representation that works on somebody who already has enough context to read it and fails on somebody who does not, which is exactly the person it was built for.

That is the family's hardest problem and none of the three chapters solves it. What they offer instead is a way of judging an artifact that does not assume the problem away: could a competent stranger act correctly from this alone, with no access to its author. Not understand it. Act correctly.

That is the pattern this family should leave behind. Not a warning against building systems, which would be a strange thing to find in this book. A caution about the accounting. Every chapter here ends up arguing that the automation was correct and that the business case for it was incomplete, in the same specific way each time: the gain was measurable and named, the loss was neither, and an organization that counts only what it can count will make this trade repeatedly and correctly and still end up somewhere it did not intend to go.