Collective Knowledge
The team’s ability to move fast depends on how widely knowledge is distributed, not how deep any one person goes.
A codebase area only one engineer understands, a product direction only PM and leadership know — these are not signs of expertise. They are risk. If that person is out for a week, the team slows down. If they leave, the team is exposed. The knowledge was never the problem. The concentration was.
The Two Kinds of Silos
Technical silos. One engineer built an area, shipped it, and moved on. Nobody else has been in that code since. This is the default outcome if nothing interrupts it. It happens without anyone deciding it should.
Context silos. Product direction, why decisions were made, what was explored and killed before Define — concentrated at PM and lead level. Engineers who lack this context make technically correct decisions that are strategically wrong. They optimize locally because they cannot see the broader picture.
Both are usually accidental. Nobody decides to hoard. It happens because knowledge transfer takes effort and that effort never feels urgent, until someone leaves, someone gets sick, or someone needs to touch an area they have never been in.
The Norm
If you are the only person who knows something important to how the team operates or what we have built, that is a risk you own until you fix it.
This is not about writing documentation constantly. It is about two habits:
When you close a project, produce the knowledge artifact. One short document covering what was built, the key decisions, and what someone would need to know to work in this area confidently. PM and PE both contribute. See Learn for the format. This is not optional.
When you notice you are a bottleneck, do something about it. If every question about an area routes through you, that is the signal. Walk a teammate through it before they need help, not after. If context about a product decision lives only in your head, write the one paragraph that captures it.
PM’s Responsibility for Context
Status is not context. The weekly PM update communicates what is in progress and what is shipping. That is not enough.
Context is: why we made this trade-off, what we tried and cut in Discover, what is coming next quarter and why that order matters, what a client decision means for the roadmap. Engineers who have this context make better decisions in Build, catch problems in Define, and need less hand-holding on judgment calls.
PM should treat “every engineer has enough context to make a good decision without asking me” as a success condition, not “engineers trust me to make the calls.” The weekly update is the right channel. Include the why behind decisions, not just the what. One sentence of reasoning is enough. It compounds over time.
What Not to Do
Don’t build a wiki nobody reads. Don’t add a standing knowledge-sharing meeting. Those decay fast because they solve a felt problem once and then become overhead.
The Learn artifact and the “I am a bottleneck, I own fixing it” norm are enough structure. The rest is culture. If leadership treats knowledge distribution as a first-class responsibility, it propagates.
Related: Communicate Up, Learn, Code Review