Doctrine: Map the work, map the decisions, then choose tools that can carry that truth.
Decision Map
A Decision Map shows where judgment routes when uncertainty hits—revealing bottlenecks, missing ownership, and why decisions keep returning to the founder.
Definition
A Decision Map is a map of who has judgment at each decision point, and where decisions route when rules run out.
Key takeaway
If decisions still land on your desk, you don’t have a delegation problem—you have a decision-routing design problem.
In plain English: Make decision rights explicit so uncertainty has a home that isn’t you.
Why this matters
- Most founders delegate tasks but keep judgment.
- Uncertainty is the real workload; when it’s ownerless, it escalates to the founder.
- Clear boundaries + permission reduce “checking” and constant Slack pings.
What to do next (3 steps)
- List recurring decisions that interrupt you (especially the “small” ones).
- Define the decision owner and the boundaries (what they can decide without you).
- Define the escalation rule (when it should come to you—and when it should not).
FAQ
- What is a Decision Map?
- A Decision Map defines who owns judgment at each decision point and where uncertainty routes.
- Why doesn’t task delegation free up the founder?
- Because tasks were delegated but decision rights were not.
- How do I stop being the bottleneck?
- Design explicit decision ownership and escalation rules so uncertainty stops routing back to you.
Keywords: decision rights, delegation, ownership, judgment, bottleneck