Track Each Person’s Autonomy Stage Task by Task

This is the full playbook from “Grant Autonomy in Stages, Based on Evidence.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Use this tracker for every direct report, broken out by task category rather than by person. The same engineer will correctly sit at different stages for different kinds of work. This exercise usually fails when leaders assign a single rating to the whole person.

1. List the task categories that matter for the role. Not a generic list: the specific categories where a bad decision has a real cost. Production deployments, architecture decisions for one service, customer-facing incident communication, hiring or performance input, cross-team dependency negotiation. Three to six per role is enough. More than that and the team abandons the tracker within a quarter.
2. Assign a current stage to each category, on evidence you can name. The four stages are Supervised Execution, Checked Execution, Independent Execution with Reporting, and Full Autonomy. Name the evidence for each: a count of reviewed instances, an incident history, a pattern. If you can’t name it, you’re guessing rather than assessing. Don’t assign a stage until you’ve collected it.
3. Set a review cadence for each stage and put it in your calendar. Supervised Execution: every instance, no exceptions. Checked Execution: a fixed recurring review, weekly or every two weeks, matched to how often the task occurs. Independent Execution with Reporting: you read what the person sends and look for nothing more. Full Autonomy: you review on request, or when something surfaces. A cadence that isn’t in a calendar becomes “whenever I remember,” which the team experiences as no review at all.
4. Tell the person their current stage and what moves them to the next one. Don’t let them infer it. State the stage, state the evidence behind it, state what has to become true to move up. This conversation is the whole mechanism; everything else in the playbook exists to make those five minutes specific instead of vague.
5. Review every stage each quarter, and review one immediately after an incident that touches its category. A stage isn’t permanent in either direction. You can review an engineer who holds Full Autonomy after a bad outcome, and that review isn’t punishment: the evidence changed, so the stage has to reflect it. Don’t let a stage stay low through inattention either. A person still in Checked Execution eighteen months after the evidence supported more is under-coached, and that shows up as attrition before it shows up in any metric.

Try this with AI.

“Interrogate my staged-autonomy tracker one row at a time. For each stage I’ve assigned, ask what evidence supports it and what would have to become true to move up. Stop me the moment I answer with a feeling.”

The tracker was never about the document. It forces a specific, falsifiable answer to a question few CTOs have ever put in writing for anyone on their team: what exactly has this person done to earn the rope I’m currently giving them, and is that amount correct, or just the amount I settled on the day I stopped paying attention?

All of the playbooks are listed on the playbooks page.