Is one person quietly holding your whole system together?

The Dependency Mapping Guide

A field guide for finding and fixing the single points of failure hiding inside your working systems, before you scale them.

Why This Matters

Most systems don't fail because they were built wrong. They fail because the knowledge required to run them quietly consolidated into one person, and nobody noticed until that person was overloaded, out, or gone. Dependency mapping is how you find that risk while it's still cheap to fix, before a scale decision makes it worse.

The 4-Step Framework

1. Inventory the knowledge. List every recurring task, decision, or troubleshooting step tied to this system. For each one, note who currently handles it.
2. Rate the concentration risk. Score each item 1 to 3: 1 means documented and shared, 2 means known by more than one person but undocumented, 3 means known by exactly one person.
3. Prioritize the 3s. Anything scored a 3 is your highest-risk gap. Start there, not with the easy stuff.
4. Assign an owner and a real deadline. For each 3, name someone, ideally not the current go-to person, to document it or shadow-learn it, with an actual date on the calendar, not "when we get to it."

A 15-Minute Worksheet

Run this with your go-to person and their manager in the room, not the go-to person alone.

Keep It Alive

Dependency risk creeps back in the moment you stop watching for it. Revisit this map every quarter, and any time a system's usage jumps or a team member changes roles.

The Scale-Readiness Checklist

A pre-flight check for rolling this system out to another team, region, or business unit, so scaling doesn't quietly rebuild the same dependency risk somewhere new. Click an item to check it off.

Before You Scale

• Documentation is current and has been used successfully by someone outside the original team
• At least one backup person could run this without the original go-to person
• You've reviewed usage data from the last 90 days, not just from launch
• No single individual is the only point of escalation

As You Scale

• The new team has read, not just received, the documentation before go-live
• A local go-to person is named for the new team, instead of routing back to the original owner
• Support and escalation paths are defined before rollout, not improvised after
• A 30/60/90-day check-in is already scheduled to catch new knowledge gaps early

After You Scale

• This score is re-checked for the new team's instance in 90 days
• Documentation ownership is formally assigned, not left with "whoever originally wrote it"
• Scaling did not double the load on your original go-to person