Improve Knowledge Sharing

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)

Common mistakes

• Proposing a tool as the knowledge system — Notion, Confluence, or Coda is not a knowledge system; it is infrastructure; the knowledge system is the workflow (who creates, where it lives, who maintains, how people find it) that the tool supports
• Auditing knowledge quantity (how many docs exist) rather than knowledge accessibility (whether the knowledge needed is findable when it is needed) — a 300-page wiki that nobody reads does not constitute a functioning knowledge system
• Diagnosing the gap as 'people don't write things down' — this is a symptom, not a structural gap; the structural gap is the absence of a workflow that makes writing things down the path of least resistance at the moment knowledge is created

Resources

What a verifier looks for

• Operational cost quality: ask the submitter to describe the most costly knowledge gap incident in the audit — a real incident should produce a specific, detailed description of who was blocked, for how long, and what the downstream cost was
• Tool vs. system distinction: ask the submitter what the maintenance workflow is for the knowledge system — 'we will use Confluence' is not a maintenance workflow; 'the engineer who completes a new process creates the doc, links it from the project page, and the tech lead reviews it before closing the ticket' is a maintenance workflow
• Gap category match: ask why the chosen gap category is the most costly — if there are multiple gap types in the audit, the choice of which to address first should be justified by cost evidence

You'll sign in first, then come straight back here.

Proof required

Submit: (1) an implementation log: start date, what was created, how team members were briefed on when and how to use it, and any resistance encountered; (2) adoption evidence from the 6–8 weeks post-implementation: at minimum 4 entries created or updated by people other than the submitter (with the date, the entry, and the author); at least 2 instances where a team member found an answer in the knowledge system rather than asking a person (provide the question context and how it was resolved); (3) a gap closure check: for the dominant knowledge gap type from M1, how many incidents of that type occurred post-implementation, and was the resolution time shorter when the knowledge system was consulted?

What gets checked

• Adoption evidence is attributed — 'the team uses it' is not evidence; 4 specific entries with dates and authors, showing the system was used by people other than the submitter, constitutes adoption evidence
• Resolution evidence is specific — 'people look things up now' is not resolution evidence; '2026-07-05: new engineer found the environment setup steps in the wiki and completed onboarding in 2 hours instead of the 4 days logged in the M1 audit' is resolution evidence
• Maintenance is active — if the newest entry in the knowledge system is from the submitter and no one else has updated anything in 4 weeks, the system has not been adopted by the team; adoption requires others maintaining it, not just consulting it

Common mistakes

• Counting page views or document access statistics as adoption evidence — access statistics do not show that the knowledge was found, useful, or acted upon; the adoption evidence must show specific instances of knowledge need being met by the system
• Briefing the team once and calling it adoption — a single team briefing about a new wiki does not establish the habit of checking the wiki before asking a person; adoption is evidenced by team members consulting the system without prompting
• Treating outdated entries as acceptable — a knowledge system with stale entries that team members have learned to distrust is worse than no knowledge system (it teaches people not to rely on it); the gap closure check must acknowledge any entries that were found to be outdated during the period

Resources

What a verifier looks for

• Attribution: ask the submitter to name 2 team members who created or updated a knowledge system entry without being asked to do so — if team members are creating entries only after being reminded, adoption is not yet habitual
• Resolution evidence: ask the submitter to describe the best example of a knowledge gap from M1 being resolved by the knowledge system — a specific incident with resolution time comparison is the strongest evidence
• Maintenance currency: ask when the last entry was updated by someone other than the submitter — staleness is an early sign that the maintenance ritual is not functioning

You'll sign in first, then come straight back here.

Proof required

Submit: (1) a before/after summary: the M1 dominant gap type, the incident rate before and after implementation, the adoption fraction (what percentage of relevant knowledge queries went through the system), and 2 specific resolution examples; (2) a lessons-learned document (300 words minimum): what the knowledge system improved, which gap type it did not address, and what you would design differently; (3) documentation of a real-time Q&A session with a named reviewer who has ≥3 years of engineering, product, or operations leadership experience and a verifiable professional profile — the documentation must include specific challenge questions and your responses; the reviewer must not be a direct report.

What gets checked

• Adoption fraction is honest — if only 30% of knowledge queries in the post-implementation period were resolved by the system (the rest still went to the submitter or a team expert), the adoption figure must reflect that
• Lessons-learned names the gap type the knowledge system did not address — if the system improved onboarding documentation but did not address siloed expertise, the lessons-learned must say so
• Q&A shows the reviewer challenged the causal link — a reviewer who asked 'how do you know the knowledge system and not the team growing or headcount changing drove the improvement?' met the adversarial standard

Common mistakes

• Before/after summary using subjective qualitative claims without quantified incident data — 'knowledge sharing feels better now' is not a before/after summary; the summary must use the same incident categories and measurement methodology as M1
• Lessons-learned that only notes what worked — a knowledge system that reduced onboarding friction but did not address siloed expertise is a partial improvement; claiming comprehensive improvement is not credible
• Reviewer who helped design or promote the knowledge system — a reviewer with a vested interest in the system's success does not give an adversarial challenge; the reviewer should be evaluating the evidence independently

Resources

What a verifier looks for

• Adoption fraction: ask the submitter to estimate how many times a team member needed knowledge that was in the system during the post-implementation period, and how many times they found it versus asked a person — the fraction of 'found it' events is the adoption fraction
• Causal link: ask the submitter whether any other changes (new team members, project type, team size) could explain the incident reduction — honest attribution is required
• Gap coverage: ask which gap types from the M1 audit are still present after the knowledge system was implemented — and why the knowledge system did not address them

You'll sign in first, then come straight back here.