The knowledge that leaves the building

In a conversation this week about a facility that has been operated and rebuilt for decades, the sharpest problem in the room was not technical. Scans exist. Models exist. Drawings exist. What is not written down anywhere is why the third valve is where it is, which route was abandoned in 2011, and what the person who has been there longest checks first when something sounds wrong.

That knowledge is not documented because documenting it has never had a place to live. It is not a chapter in a manual. It is an annotation on a location.

The method is unglamorous. Thirty minutes per key person, with the reality of the site between you, and one opening question: show me on the map what you work with. Where is it physically? Which systems do you use to work with it? What are your biggest problems in a normal week, and who do they hit? What should be done in the next two to three years, from where you sit?

After five such conversations there is a shared picture that people recognise, because they built it. After ten, the organisation owns something it previously rented from individuals.

Then it compounds. Every meeting note, decision and incident hangs on the node it concerns. A new colleague asks the site rather than asking a colleague who may be on holiday. The question "what did this person work on" has an answer inside the organisation instead of inside a calendar.

The minimum viable twin. Start where a decision is already being made badly or slowly. Anchor that one thing. Prove it in days, not quarters. Everything else is scope you have not earned yet.

If your continuity plan depends on one person answering the phone, that is not a documentation problem. It is a design problem, and it has a design answer.