Knowledge Transfer
Most of what a project knows is not written anywhere. It is in four people’s heads, and in about six weeks those four people will be on different projects with the details already blurring. Knowledge transfer is the deliberate act of moving a small, well-chosen part of that out before it goes.
In short
- The biggest store of project knowledge is in people’s heads, and it is the only one that expires.
- Don’t document everything. Move the handful of things a future team would otherwise pay to rediscover.
- Findability beats completeness. Something searchable and rough beats something thorough and lost.
- The most reliable transfer mechanism isn’t a document — it’s a person from this project on the next one.
Three places knowledge lives
What’s worth moving
“Document everything” produces nothing, because it has no finish line and no priority. A better filter: what would a competent stranger have to rediscover, at what cost? That ranks the candidates quickly.
| Kind of knowledge | Example | Cost of rediscovering it |
|---|---|---|
| Rejected options | “We tried the queue-based design; it couldn’t meet the latency requirement.” | Weeks. Somebody will try it again. |
| Real durations | “Vendor security review: 5 weeks, not 2.” | A whole late project. |
| Who to call | “For the payment API, ask Kenji — support tickets take a week.” | Days, repeatedly. |
| Fragile spots | “The nightly job assumes UTC. Don’t change the server timezone.” | An outage. |
| Reusable artefacts | The migration script, the test checklist, the estimate template. | Rebuilt from scratch. |
| Architecture already in the code | What the system does, described again in prose | Low — and it goes stale |
The last row is the trap. Documentation that restates something already visible in the artefact is the easiest to write, the most likely to be produced under pressure, and the first thing to become wrong. The valuable material is all of the why variety, because the why is precisely what the artefact cannot contain.
Making it findable
A perfect document nobody can find has the same value as no document. Three rules do most of the work:
- Store it with the project. A future person will search the project’s name, because that’s the one word they know. Personal drives, chat channels and slide decks all fail this test.
- Name things the way someone would search. “Vendor security review — actual timings” is findable; “Notes v3 final” is not.
- Have an obvious starting point. One pinned page that says what this project was, where the deliverable is, who owns it now, and the three things worth reading. Everything else can be messy behind that.
That last one is worth more than it sounds. Most project archives fail not because the material is absent but because a newcomer has no way to tell which of forty pages matters.
The transfers that actually work
Written material is the weakest form of knowledge transfer and the one people reach for first. In rough order of effectiveness:
1. A person moves with the work
One member of this project joining the next one carries more context than any document. If the next project is similar, this is worth arranging deliberately rather than by accident.
2. Doing it together once
The receiving team performs the task while the original team watches and says nothing unless asked. An hour of this finds every gap that a runbook review would miss.
3. Answering real questions
A short window where someone can be asked anything — the 30 days from 7.1. The questions that arrive are also the specification for what should have been written down.
4. Written material
Last, and still necessary — it is the only one that works when nobody involved is available. Which is exactly the situation it needs to be written for.
Where it usually fails
- Scheduled for after the end. Knowledge transfer planned for “after delivery” happens after people have been reassigned, which is to say not at all. It belongs in the plan with a date, like any other work.
- Written for the author. Documentation full of the team’s shorthand reads as complete to them and as noise to anyone else. Have somebody outside the project read it before you file it.
- One heroic document. A forty-page write-up produced in the last week, accurate on the day it was written and never opened. Four short findable pages beat it every time.
- Nothing pulls it. Material only gets read if some habit causes someone to look. Without a “read the last two similar projects” step at kickoff, the archive is a write-only medium.
The habit that makes all of this pay
Everything above is the supply side. The demand side is one practice, and it is where the return actually comes from: at the start of every project, read the retrospectives and notes from the two most similar past projects.
Ten minutes. It converts other people’s written lessons into your risk register, your estimates and your plan — which is the only reason any of it was worth writing. An organisation that files diligently and never reads has built an expensive archive; one that reads first has built a compounding advantage.
How this looks in AB
In AB Projects, Wiki pages, tasks and comments all live with the project rather than scattered across drives, which handles most of the findability problem by default: the next team can search the project’s name and find the actual context, not just the deliverable. Pinned Wiki pages make the “start here” set obvious, which is the one page that decides whether the rest gets read.
Archiving keeps everything readable while preventing edits, so a finished project stays a reliable reference. And where continuity matters, project members can be carried over to the next project as observers — the tool-shaped version of the most effective transfer mechanism on this page.
Two habits worth adding by hand:
- Write the “why not” comments as you go. When an approach is rejected, one comment on the relevant task — “considered X, rejected because Y” — costs thirty seconds and is the single most valuable artefact a project produces.
- Make the pinned page the last thing you do. Project name, what it was for, where the deliverable lives, who owns it now, and links to the three pages worth reading. Ten minutes, at the moment when everyone still knows the answers.
Terms used on this page
- Knowledge transfer
- Deliberately moving what a project learned out of individual heads and into a form a future team can find and use. More →
- Tacit knowledge
- What people know without having written it down — judgement, context, who to ask. The largest and most perishable store a project has. More →
- Runbook
- Written instructions for the routine operations of a system, assuming no prior context. The most reused document a project produces. More →
- Decision record
- A short note of what was decided, what was rejected and why. Cheap when written at the time and impossible to reconstruct afterwards. More →
- Lessons learned
- The reusable conclusions from a project, recorded where a future team will find them. Only valuable if something causes someone to look. More →
- Bus factor
- How many people would have to become unavailable before critical knowledge is lost. A bus factor of one is a single point of dependency with a friendlier name. More →
Related reading
4.1 Building a Project Team
Single points of dependency during the project — the same problem, caught earlier.
10.1 Continuous Learning
Turning one project’s lessons into a practice that improves over years.
8.0 Case Studies
What other projects learned, in the form this chapter argues lessons should take.