009: The Ladder of Autonomy
Understanding Task Relevant Maturity and Ladder of Autonomy
I’ve been thinking a lot about autonomy.
Last week, I watched a junior engineer quietly fix a lingering production alert without anyone asking. She had enough confidence to propose the fix, but not quite enough context to push it to production alone. So she went to the senior engineer and asked for context and safety to deploy that fix. It was a moment that made me think once again how important it is to be deliberate about autonomy on a team. To go from hand-holding every small decision to a place where people feel genuine ownership for their work.
Autonomy is deeply connected to feeling trusted—trusted to learn, trusted to explore, and trusted to deliver. Managers who learn how to create a culture of autonomy see performance gains on their teams. But it’s also scary to hand over control when revenue or reputations are on the line. That’s why I love having a Ladder of Autonomy as a mental model. It helps in guiding people from “Tell me what to do” up to “I’ve been doing…” in a structured, healthy way.
Overview
This ladder pulls from several sources – L. David Marquet’s concept of leadership levels (outlined in Turn the Ship Around! and related works) and Andy Grove’s “Task Relevant Maturity” from High Output Management. By merging them, we get a continuum of autonomy, from Level 1 (complete direction needed) to Level 7 (extreme ownership).
Here’s the short version:
The point is you don’t throw someone fresh off the boat into Level 7. You build trust and skill, gradually moving them up the scale.
Level 1: “Tell Me What to Do”
Who?
Someone brand-new to the codebase, the domain, the tech-stack, the problem, or the entire company. Basically, they need direction.
Manager’s Job:
- Provide high support and clarity.
- Reduce ambiguity.
- Be ready to answer every question—no matter how trivial it seems. This is a crucial time to build trust – no question is too small; no detail is too trivial.
Why It Matters:
Early on, clear direction replaces guesswork. That sets a foundation of trust and psychological safety.
Level 2: “I Think…”
Who?
Engineers (often junior) who are starting to form opinions but need confirmation.
Manager’s Job:
- Encourage them to voice ideas. Ask why – gently. “Why do you think that’s the right approach?”
- Validate the thought process, not just the outcome.
- Provide mentorship – be a sounding board, not a micromanager.
Why It Matters:
This is the first step in independence. When people feel safe to say, “I think we should do X,” they’re starting to own their expertise.
Level 3: “I Recommend…”
Who?
Engineers with enough context to research and propose specific solutions by analyzing trade-offs, and comparing approaches.
Manager’s Job:
- As a leader, your role is to check alignment. “Does this solve the right problem? Does it match our priorities?”
- Refine and approve.
- Still offer guidance but shift from directive to consultative.
Why It Matters:
You might override or pivot their recommendation at times, but you generally allow them to propose a direction, and you trust them enough to present it formally.
Level 4: “I Request Permission to…” –
Who?
Engineers who feel strongly about their plan but want to double-check they’re not going off-track. This level typically occurs when the consequences of the action are significant but the individual hasn’t yet built the track record for unilateral decisions. Or it can be a novel, high-stakes scenario.
Manager’s Job:
- Weigh risks together.
- Confirm alignment.
- Usually grant permission unless you see big danger signals.
Why It Matters:
If the consequences are significant, they’ll need a final nod from you. This level reduces the chance of big, costly missteps.
Level 5: “I Intend to…”
Who?
Engineers (often senior) who are comfortable making decisions independently.
This is a huge leap. They’re telling you what they’re going to do. Unless you spot something dangerous or out-of-bounds, your default stance should be “Yes. Excellent. Go for it.”
Manager’s Job:
- Get out of the way, unless something is truly on fire.
- Offer guardrails only if absolutely necessary.
Why It Matters:
They’re stepping into genuine leadership. Instead of asking, they’re informing. A quick review from you can prevent collisions but still give them space to do the work.
Level 6: “I’ve Done…”
Who?
Staff engineers or highly experienced ICs who execute confidently.
Manager’s Job:
- Remove blockers.
- Keep the big picture in sight.
- Make sure their decisions are visible to the team so everyone benefits from the knowledge.
Why It Matters:
At this level, they deliver results proactively. You discover solutions are shipped rather than waiting for approvals.
Level 7: “I’ve Been Doing…”
Who?
Staff+ engineers or domain owners who handle entire swaths of responsibility. At this point, trust is extremely high, and the results speak for themselves.
Manager’s Job:
- Recognize and champion them.
- Encourage them to mentor others.
- Make sure their work aligns with broader org strategy.
- Offer them bigger challenges, more resources, or even more strategic areas to tackle.
Why It Matters:
They’re operating with near-total independence. You find out about their successes through demos, stakeholder feedback, or metrics—and the results speak for themselves.
Task Relevant Maturity: When to Dial Up or Down
Andy Grove’s “Task Relevant Maturity” reminds us that autonomy depends on two factors: competence and context.
A Staff engineer might be at Level 7 with a backend architecture they’ve owned for years, but drop to Level 2 if you throw them into an unfamiliar domain. Autonomy is not a permanent label. It’s contextual, fluid, and must be reassessed when someone takes on a new challenge.
Role-Based Sweet Spots
- Junior Engineers: Typically Levels 1–3
- Mid-Level Engineers: Typically Levels 1–4
- Senior Engineers: Typically Levels 1–5
- Staff Engineers: Typically Levels 1–6
- Principal Engineers: Capable of Levels 1–7
These aren’t hard rules – just guidelines. People accelerate faster at higher career levels, especially if they have relevant domain experience.
Practical Ways to Apply This Model
- Assess Competence and Commitment
- Check both technical ability and motivation.
- Ask questions: “Do they have the domain knowledge? The drive? The resources?”
- Start Low, Move Up Gradually
- If a domain is mission-critical or brand-new, begin with more manager oversight.
- Let them level up to “I recommend” or “I intend to” when they’re ready.
- Communicate Expectations Clearly: "I’m expecting you to come at this with a ‘I recommend…’ mindset." "You have full ownership—make the call and let me know.”
- Celebrate Progress
- When someone moves from “I think…” to “I recommend…,” call it out in front of the team.
- Recognizing these small wins increases confidence and morale.
- Course-Correct Gently
- If someone takes on too much, figure out if the gap is knowledge, motivation, or resources.
- Adjust accordingly without punishing the attempt—foster a safe environment to try again.
Why does all of this matter?
A healthy scale of autonomy transforms a team from a rigid hierarchy to a high-trust squad. Everyone knows how far they can push an idea before needing a nudge or a decision from leadership. You, as a manager, aren’t drained by micromanagement or forced to trust blindly.
Autonomy is powerful, but it can become a free-for-all if not managed properly. Senior folks might overestimate their abilities in brand-new areas. Or a junior might go “rogue” attempting advanced refactors without proper guardrails. That’s why continuous check-ins and context-sharing are essential.
Autonomy is also dynamic. It’s something you re-calibrate whenever roles change or new projects spin up. But if you get this right, you’ll see better productivity, happier engineers, and a culture of ownership that drives exceptional results.
Your Next Challenge
For your next sprint or project, take five minutes to map each team member to a level of autonomy. Are they exactly where they should be? Or is it time to nudge them up—or down—a rung? Communicate these expectations explicitly. You might be surprised by how quickly people embrace new levels of responsibility when it’s done transparently.
Let me know how it goes. And drop me an email about it.
Further Reading
Old School Burke
For insights on how ownership mindset changes behaviors.
Jason Yip
More on L. David Marquet’s approach.
Fredrik Scheide
Another excellent perspective on giving teams freedom.
Old School Burke Newsletter
Join the newsletter to receive the latest updates in your inbox.
