accountability-map

accountability-map — roles, outcomes, one owner each

Title tells you what someone is called. Role tells you what someone is responsible for. Map the roles. The map is the contract.

What a role looks like

Each role has 3-5 outcomes the role exists to produce. Outcomes — what the role delivers. Not tasks — how it's delivered.

• Good — "Customer issues resolved within 4 business hours." "Pipeline of qualified leads sufficient to hit quarterly target." "Codebase shippable on any business day."
• Bad — "Answer support tickets." "Run marketing campaigns." "Write code."

The first set are outcomes you can hold someone to. The second set are activities you'll argue about forever.

One owner per outcome

Two owners means no owner. When two people fight over an outcome, the map is unclear. When no one steps up for an outcome, no owner was named. Both are the map's fault, not the people's.

One person can hold multiple roles. Don't conflate person and role — a small team has more roles than people, and that's fine if the roles are named.

The mapping exercise

1. List the roles. Not the people. The roles the business needs filled.
2. Write 3-5 outcomes per role. What the role exists to produce. Outcomes, not activities.
3. Assign one owner per role. A name. One.
4. Cross-check. Any outcome with two owners? Any role with no outcomes? Any outcome no role owns? Any person holding so many roles that the math doesn't work? Fix it.

Do this on a wall, a whiteboard, or a single doc. Not in five tools. The map is one artifact.

When to re-map

• A new function appears (sales, ops, support — someone has to own it).
• A founder is doing everything and the team can't tell which hat is on.
• Two people keep colliding on the same work.
• A hire is coming in and the role they're filling isn't crisp.
• The business doubles — old map breaks at the seams.

Anti-patterns

• Titles instead of roles — "VP of Stuff" obscures what the person is actually accountable for.
• Shared ownership — "everyone is kind of responsible for customer success." No they aren't.
• Outcomes as tasks — task lists masquerading as accountability. Rewrite each as the result the task is supposed to produce.
• Roles defined by tools used — "owns Salesforce" is not a role; it's a login.
• Map that lives nowhere — if the map isn't in one place the team can point to, the map doesn't exist.

Triggers

Team is bumping into each other. Ownership of a new function is unclear. Hiring a new role. Scaling and seams are appearing. "Who owns this?"

Pairs with people-fit (once the role is mapped, check whether the owner has get-it, want-it, capacity).