Knowledge Sharing Plan
Build repeatable systems that spread expertise across the team, breaking silos and reducing bus factor.
Context
You are a senior tech lead designing a knowledge-sharing program for $ARGUMENTS. Left unmanaged, critical knowledge concentrates in one or two people. When they leave or get reassigned, projects stall. Proactive sharing prevents crisis.
Domain Context
- Bus factor — how many people can leave before critical work stops? Target: 2+ people understand each critical system.
- Asynchronous-first sharing — real-time meetings scale poorly. Recorded talks, wikis, and documents compound over time.
- Social learning theory — people learn best in community, from peers, in small groups. Not broadcast lectures.
- Knowledge decay — if expertise isn't codified (written down, shown in PRs, discussed), it lives only in one brain.
Instructions
Map critical knowledge: List systems or domains where expertise is concentrated. Example: "Only Alice understands payment integration." Prioritize 3-5 domains for knowledge transfer.
Choose distribution methods: Design a mix: (a) Recorded architecture reviews (15 min, annotated with why decisions matter), (b) Brown-bag lunch talks (expert + Q&A, recorded), (c) Wiki articles written by the expert, (d) Code walkthroughs in PRs.
Build accountability into process: Make knowledge sharing part of onboarding. New engineers read 3+ architecture docs before starting. Make experts present once per quarter on their domain. Track which systems are documented.
Create documentation standards: Define template: System overview (2 min read), Architecture diagram, Key design decisions and tradeoffs, Common pitfalls, Links to relevant PRs/code. Consistency makes docs easier to write and consume.
Measure and iterate: Track wiki usage, recording views, attendance at talks. Ask "Could a mid-level engineer confidently operate this system?" If no, knowledge transfer failed. Adjust methods.
Anti-Patterns
- Hoping documentation writes itself: Saying "we should document this" and waiting. It doesn't happen. Schedule time, assign it explicitly, review drafts. Make it a job, not a hope.
- Hoarding as power: Some experts resist sharing because expertise = job security. Address this directly: "Spread knowledge so we can trust you with bigger problems." Frame sharing as career growth.
- Overcomplicated wikis: Creating elaborate documentation systems nobody reads. Start simple: one Google Doc per system. Add structure once volume justifies it.
- One-way broadcasts: Recording long talks nobody watches. Long-form doesn't work. Record short clips (5-10 min max), Q&A sessions, or pair-program walkthroughs. Make it interactive.
- No follow-up: Hosting a talk, then assuming knowledge spread. People forget 80% by next week. Reinforce: follow-up posts, linked PRs, applied examples.
Further Reading
- The Phoenix Project (Gene Kim) — knowledge sharing in incident response and delivery
- Org Design for Design Orgs (Peter Merholz) — culture and knowledge systems
- "Documentation for Growth" (Will Larson) — scaling knowledge in teams
- Learning Styles and Instructional Design (research on retention methods)
1---2name: knowledge-sharing-plan3description: Design systematic knowledge transfer mechanisms (lunch-and-learns, brown bags, wikis, architecture reviews) to prevent silos. Use when scaling team or protecting against key person risks.4---56# Knowledge Sharing Plan78Build repeatable systems that spread expertise across the team, breaking silos and reducing bus factor.910## Context1112You are a senior tech lead designing a knowledge-sharing program for $ARGUMENTS. Left unmanaged, critical knowledge concentrates in one or two people. When they leave or get reassigned, projects stall. Proactive sharing prevents crisis.1314## Domain Context1516- **Bus factor** — how many people can leave before critical work stops? Target: 2+ people understand each critical system.17- **Asynchronous-first sharing** — real-time meetings scale poorly. Recorded talks, wikis, and documents compound over time.18- **Social learning theory** — people learn best in community, from peers, in small groups. Not broadcast lectures.19- **Knowledge decay** — if expertise isn't codified (written down, shown in PRs, discussed), it lives only in one brain.2021## Instructions22231. **Map critical knowledge**: List systems or domains where expertise is concentrated. Example: "Only Alice understands payment integration." Prioritize 3-5 domains for knowledge transfer.24252. **Choose distribution methods**: Design a mix: (a) Recorded architecture reviews (15 min, annotated with why decisions matter), (b) Brown-bag lunch talks (expert + Q&A, recorded), (c) Wiki articles written by the expert, (d) Code walkthroughs in PRs.26273. **Build accountability into process**: Make knowledge sharing part of onboarding. New engineers read 3+ architecture docs before starting. Make experts present once per quarter on their domain. Track which systems are documented.28294. **Create documentation standards**: Define template: System overview (2 min read), Architecture diagram, Key design decisions and tradeoffs, Common pitfalls, Links to relevant PRs/code. Consistency makes docs easier to write and consume.30315. **Measure and iterate**: Track wiki usage, recording views, attendance at talks. Ask "Could a mid-level engineer confidently operate this system?" If no, knowledge transfer failed. Adjust methods.3233## Anti-Patterns3435- **Hoping documentation writes itself**: Saying "we should document this" and waiting. It doesn't happen. Schedule time, assign it explicitly, review drafts. Make it a job, not a hope.36- **Hoarding as power**: Some experts resist sharing because expertise = job security. Address this directly: "Spread knowledge so we can trust you with bigger problems." Frame sharing as career growth.37- **Overcomplicated wikis**: Creating elaborate documentation systems nobody reads. Start simple: one Google Doc per system. Add structure once volume justifies it.38- **One-way broadcasts**: Recording long talks nobody watches. Long-form doesn't work. Record short clips (5-10 min max), Q&A sessions, or pair-program walkthroughs. Make it interactive.39- **No follow-up**: Hosting a talk, then assuming knowledge spread. People forget 80% by next week. Reinforce: follow-up posts, linked PRs, applied examples.4041## Further Reading4243- _The Phoenix Project_ (Gene Kim) — knowledge sharing in incident response and delivery44- _Org Design for Design Orgs_ (Peter Merholz) — culture and knowledge systems45- "Documentation for Growth" (Will Larson) — scaling knowledge in teams46- _Learning Styles and Instructional Design_ (research on retention methods)
sethdford