← All postsHow-to

Knowledge capture: writing things down before the person leaves

Knowledge capture fails as a documentation project and works as a habit attached to real work. Where to start, what to skip, and why the expert is the wrong person to write it.

How-toK

Knowledge capture usually begins when somebody resigns, which is the worst possible moment: the person has two weeks, no incentive, and the knowledge is now a negotiating position rather than a shared asset. Done as a habit it costs almost nothing. Done as a project it produces a folder of documents written in a hurry that nobody opens, and the organisation concludes documentation does not work.

Start with what breaks

  • Anything only one person can do. Write that down first — the list is usually shorter and more alarming than people expect.
  • The recurring question. If somebody is asked the same thing monthly, that answer is the highest-value page you can write.
  • The non-obvious workaround: the step that exists because of a reason nobody remembers, which is what gets removed and then reinstated after an incident.
  • Anything with an external dependency — a supplier contact, an account, a renewal that only one person watches.
  • Not everything else. Comprehensive documentation is how the effort dies.

The expert is the wrong author

People who know something well are the worst at explaining it, because they cannot see what they are assuming. The productive pattern is the opposite: the person who does not know writes it, the expert corrects it. That also produces a document pitched at the right level, and it tests comprehension in the only way that matters — somebody who did not previously know now does, and the gaps appear immediately rather than at the next handover.

Capture at the moment of doing, not afterwards. Somebody working through an unfamiliar process is the ideal author for the first five minutes of it, and that window closes as soon as they become competent.

Knowledge capture as a habit rather than a project

  1. Make writing it part of the task: resolve the unusual problem, then spend five minutes recording what you did.
  2. Keep one page per thing, with the date and the author, so a reader can judge how stale it is.
  3. Link rather than duplicate; the same procedure written three times decays in three directions.
  4. Review the single-point-of-failure list quarterly, because it changes with every departure and hire.
  5. Pair on anything only one person can do, which captures the knowledge and removes the dependency at once.

When somebody does leave

Ask for the list of things they think only they know, then have somebody else attempt each one with them watching. That finds the real gaps in an afternoon, where interviews produce a reassuring document and no transferred capability. And write down what they are worried about on their way out — departing people are unusually honest, and they tend to name the risk everybody else has normalised.

Ettex Notes suits the habit form: one page per thing, dated and authored, searchable without a structure anybody has to maintain. Where the material becomes a procedure other people follow, it graduates into a standard operating procedure rather than staying a note.

Frequently asked

Who should write documentation?

The person learning it, corrected by the person who knows. Experts cannot see their own assumptions, which is exactly what a newcomer stumbles over.

How much should be documented?

Start with what only one person can do and what gets asked repeatedly. Attempting comprehensive coverage is the most reliable way to end up with nothing.

When is the best time to capture knowledge?

While somebody is doing the thing, especially the first time. A notice period is the worst time and unfortunately the most common one.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.