How do I apply the idea that the team's knowledge graph?

The most direct way to practice is through a focused exercise: Build a transactive memory map for your team. Create a matrix with system components, processes, or knowledge domains as rows and team members as columns. For each cell, use a simple rating: E (expert — deep knowledge, can solve novel problems), K (knowledgeable — can handle routine issues), F (familiar — knows enough to ask the right questions), or blank (no significant knowledge). Fill in your own row first, then ask each team member to fill in theirs. Compare the results. Look for three patterns: (1) Single points of failure — domains where only one person is rated E. (2) Knowledge deserts — domains where no one is rated above F. (3) Perception gaps — cases where your rating of someone else's expertise differs significantly from their self-rating. Share the completed map with the team and discuss: 'Where are we most vulnerable if someone leaves?'

Common pitfall: Building the map once and never maintaining it. A transactive memory system is a living representation that must evolve as people learn new skills, systems change, and team members join or leave. A static expertise map from six months ago is worse than no map — it creates false confidence in routing that no longer works. The person listed as the auth expert may have moved to a different team. The system listed under 'legacy — minimal maintenance' may have become critical after a product pivot. The second failure is confusing documentation with transactive memory. Documentation tells you what the system does. Transactive memory tells you who can help you when the documentation is insufficient — which is precisely when you need help most.

This practice connects to Phase 81 (Team Cognition) — building it as a repeatable habit compounds over time.