· Management · 3 min read
Reducing the "Bus Factor": Documenting Tribal Knowledge
This guide explores a documentation strategy to extract tribal knowledge efficiently using AI, protecting your team against the dreaded 'Bus Factor'.
“If Sarah gets hit by a bus tomorrow can we still deploy the app?”
It is a morbid question but every Engineering Manager has to ask it.
In most teams knowledge is concentrated in a few heads. These “10x Engineers” carry the entire system architecture in their mental RAM. They know why the legacy billing code is weird. They know which server needs a reboot on Tuesdays.
This is the Bus Factor. If your Bus Factor is 1 you are in danger.
When that person leaves (or wins the lottery) that knowledge walks out the door. The team is left with code they don’t understand and fear to touch.
This guide is about a documentation strategy to extract that knowledge efficiently using AI.
What is the Bus Factor?
It is the minimum number of team members that have to disappear before a project stalls.
The risk of one person knowing everything
Low Bus Factor creates bottlenecks. Even if the senior dev is still there everyone waits for them to review PRs. Everyone asks them for help. They become a blocker not an enabler.
Why Senior Engineers Don’t Write Docs
They want to. But they are busy.
It’s boring and slow
Writing documentation feels like a chore. It takes them away from solving interesting problems.
They think “I will write it down later.” But later never comes. Or they write a wall of text that nobody reads.
The “Exit Interview” Strategy with AI
We propose a different approach. Don’t ask them to write docs. Ask them to talk.
Sitting down with the Senior Dev
Schedule a one-hour “Brain Dump” session. Ask them to explain the system. “How does the payment flow work?” “What are the weird edge cases in the user model?”
Rapidly generating diagrams while they explain the system
As they talk you (or they) type the description into AI Diagram Maker.
“Okay so the Payment Service calls Stripe. But if Stripe is down it puts the message in an SQS queue. The Retry Worker picks it up.” The diagram appears on the screen.
“Like this?” you ask. “No,” they say. “The Retry Worker actually talks to the Database first.”
You update the text. The diagram updates. In 5 minutes you have captured a complex flow that lived only in their head.
Creating a “Living Legacy”
By the end of the hour you have 10 diagrams covering the core systems.
Storing the diagrams in the repo
Save these diagrams in the codebase.
Making the codebase approachable for the next hire
When the new Senior Engineer joins they don’t have to guess. They have the map.
You have successfully transferred the tribal knowledge. You have increased the Bus Factor. You have secured the future of the project.
