Improve Knowledge Sharing
12 weeks · 4 milestones
Milestone map
Milestone map
3 milestones
Knowledge sharing fails when knowledge that should be accessible is not — and the team pays for the gap through repeated onboarding questions, siloed expertise, work blocked on single people, or decisions made on stale assumptions. The baseline must identify the dominant knowledge gap category with specific incidents, and commit to a structural knowledge system (not just a repository) before implementation begins. A 'knowledge system your team actually uses' means a structure with a defined workflow for knowledge creation, a discoverable home, and a maintenance ritual — not a wiki that exists but is not consulted.
Proof required
Submit: (1) a knowledge gap audit: 4–6 weeks of incidents where knowledge not being accessible created a cost — for each, name the gap (who had the knowledge, who needed it, why it wasn't accessible), the downstream cost (time to find the answer, rework, blocked work, repeated question), and the frequency; (2) a gap category diagnosis: the dominant type (siloed expertise, undocumented processes, outdated documentation, missing onboarding content) and why it is the most costly; (3) a pre-committed knowledge system design: the specific structural solution — what will be created, where it will live, who owns its maintenance, and how team members will be expected to find and update it — written before implementation.
What gets checked
- Audit incidents are operational costs, not preferences — 'we don't have good documentation' is not an operational cost; 'the new engineer spent 4 days debugging an environment issue that would have been resolved in 30 minutes with documented setup steps' is an operational cost
- Gap category diagnosis reflects the dominant type — if 4 of 5 incidents are siloed expertise (only one person knows how to do X), the diagnosis must be siloed expertise, not 'documentation quality'
- Knowledge system design has a maintenance ritual — a wiki created but never updated becomes stale; the pre-committed design must name who owns updates, how often, and what triggers an update (a new process, a new team member, a changed decision)
Resources
Enroll free to unlock learning resources →Mastery
Google re:Work — Team Learning Practices
Go further: structural conditions for team learning and knowledge sharing at the organisational level.
Unlocks after completing Foundation + Depth