Form
Knowledge map matrix (domain x person with knowledge levels) plus artifact list per domain, criticality evaluation (traffic lights), risk list, and transfer plan with owner and date.
RunsheetKnowledge Modeling
Knowledge Mapping
ComplexityMedium
Time1-3 h
Participants3-12
FormatWorkshop
MaturityEstablished
01
Preparation
What needs to be ready before start
Materials
Whiteboard or Miro board with matrix (knowledge domain x person); sticky notes for artifacts (documentation, wikis); criticality marker pens (traffic lights); list of relevant systems or tasks; timer.
People / roles
A facilitator who keeps domains separated; three to twelve team members; one scribe for the knowledge map and transfer plan; optional lead for criticality scoring when needed.
Pre-read
Scope (team, area, product); list of relevant knowledge domains pre-collected (e.g. Auth System, Billing, Onboarding pipeline, vendor relationships); trigger (team growth, imminent departure risk, onboarding wave).
Time needed
1-3 h
Setup
Prepare matrix with columns for domains and rows for people. Use symbols for knowledge levels (for example P = primary, S = secondary, L = learning, blank = unknown). Keep a separate criticality marker.
02
Core question
The one question this method answers
Where is knowledge located, who is the sole holder, and which gaps or single points of failure must be closed before a critical period?
03
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Scope and domains | 20-30 min | Finalize knowledge domains. Tune granularity so each domain is recognizable as a coherent knowledge area, not too broad and not too fine. Name critical tasks per domain briefly. | "Frontend" as a domain is too broad. "React routing in app X" is actionable. Tune granularity iteratively. |
2Phase 2: Capture knowledge owners | 20-30 min | Each person self-assesses each domain (P, S, L, blank). Then add peer assessment per person. Clarify larger discrepancies quickly. | Self- and peer assessment diverge often. Record both and take the average, or clarify together. |
3Phase 3: Add artifacts and docs | 15-20 min | For each domain, note which written artifacts exist (runbook, wiki, ADR, Notion page). Add links or paths. Flag missing documentation. | Knowledge without documentation is person-bound knowledge. Record both as risks even when the person is available. |
4Phase 4: Assess criticality | 20-30 min | Mark each domain with a traffic light: red (single point of failure, no documentation), yellow (two owners or partial documentation), green (three+ owners and documentation). Mark top risks. | Three-owner rule is a guideline. For very large or safety-critical systems, require more. |
5Phase 5: Transfer plan | 15-30 min | Create specific transfer actions for each red risk: pair working, documentation sprint, shadowing, ADR. Assign owner and date. Set re-review cadence, typically quarterly. | Transfer plans without dates are wishes. Better three binding actions than ten unbound ideas. |
04
Artifact
What comes out at the end
Versioning / ownership
Create one entry per iteration with date. Refresh every 3-6 months or when people leave. Review action status regularly.
Tool alternatives
- Miro with knowledge-map frame
- Notion database with person and domain columns
- Google Sheet as matrix
- Confluence page in team space
knowledge-mapping-working-template.md
Compact working template for Knowledge Mapping with context, input, output artifacts, and next step.
Knowledge Mapping Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Knowledge Map:
- Critical Knowledge Areas:
- Transfer Plan:
Open questions
- ...
Next step
Owner, date, success signal.
05
Example output
Concrete filled scenario, fictional example
knowledge-mapping-beispiel.md
Concrete filled scenario, fictional example
Knowledge Map — Activate Team (24.05.2026)
Scope: Onboarding pipeline, activation tracking, auth interface, billing integration.
Matrix excerpt:
| Domain | Anna | Ben | Lisa | Marcus | Tobias | Documentation | Criticality |
|---|---|---|---|---|---|---|---|
| Onboarding pipeline | S | P | L | — | S | Partial runbook | yellow |
| Activation tracking | P | S | P | — | — | Dashboard documentation | green |
| Auth interface | — | P | — | — | — | — | red |
| Billing integration | S | — | — | — | P | ADR exists | yellow |
Top risks:
- Auth interface: single point of failure with Ben, no documentation.
- Billing: two owners, but ADR without current operations documentation.
Transfer plan:
- Auth interface: pair working Ben + Anna for 2 weeks while writing ADR and runbook. Due 14.06, owner: @ben.
- Billing: Tobias creates operations runbook. Due 30.06, owner: @tobias.
- Re-review: in Q3 retro (late September).
06
Pitfalls
Recognize symptoms and steer against them
Trap
Domains too broad
Symptom
Domain "Frontend" has six people marked P, but no one can independently handle all critical questions.
What to do
Split domains more finely. Practical test: can one person execute one critical task in this domain alone?
Trap
Self-assessment too high or too low
Symptom
Anna marks P while team marks L, or vice versa.
What to do
Capture both perspectives. Clarify larger gaps in a 5-minute check. Use concrete task questions such as "Who would review pull request 123?"
Trap
Documentation wishful thinking
Symptom
Documentation is marked as present but is outdated or hard to find.
What to do
Documentation markers require current links and as-of dates. Anything older than 12 months is considered stale unless explicitly reviewed.
Trap
Transfer plan without time budget
Symptom
Pair working or documentation sprint is approved but no protected capacity exists.
What to do
Treat transfer as a committed backlog item with a blocked time slot. Team lead secures the capacity.
Trap
Method becomes one-off
Symptom
Map is created and never updated, while knowledge distribution changes over time.
What to do
Fix refresh every 3-6 months. On personnel changes, update immediately.
07
Stop criteria
Done signals checkable in under a minute
Team has fewer than 3 members and single points of failure are structurally unavoidable.
Domains were not collected in advance and workshop becomes brainstorming.
Workshop shorter than 45 minutes, making all five phases impossible.
No willingness to assign time-budgeted transfer plans.
Knowledge topic is mainly tacit domain knowledge with poor documentation accessibility; coaching is needed instead of mapping.
An urgent handover is already in progress and map arrives too late; prioritize direct transfer instead.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.