Intent, not permission

"Can I deploy this?"

You'll hear some version of that sentence a hundred times a week across a growing org, and it's the sound of authority sitting in the wrong place.

Most of the time, the person asking already knows the answer. Watched the test run. Checked the dashboard. Knows whether Support's been warned. None of that is actually in doubt. They're asking because asking is the norm here, and somewhere along the way "check with someone first" got confused with "do the job responsibly."

There's a different sentence available, and it isn't a question.

"I intend to deploy this once the current test run completes. Health checks are passing, rollback's staged, Support is notified."

Read that again slowly. Nobody's asking permission. It states the action, the reasoning behind it, and the safety checks that make the reasoning trustworthy, all in one breath. If someone in the room knows something the speaker doesn't, there's a natural moment to say so, right then, before anything happens instead of after. Nobody has to grant anything. The default flips from "wait for approval" to "act, and give the room one clean chance to catch what you missed."

That's the whole mechanism. It's not a magic phrase, and saying it out loud doesn't make it true on its own. It only works when two other things are already in place, and most leaders who try this and get burned skipped straight past both.

Clarity and competency, not confidence

Clarity means understanding the mission well enough to make a call that actually serves it. Not the task sitting in front of you. The thing the task is for.

Someone who knows "ship the export feature by the fifteenth" is following an instruction. Someone who knows why customers are asking, what a bad version of it costs the business, and exactly where the line sits between "acceptable trade-off" and "don't ship this without me" can have an intent of their own. You build that by explaining the why every single time, not just the first time. Say the boundaries and the nonnegotiables out loud, plainly, more than once. Invite disagreement often enough that people believe you mean it. Specify the outcome. Stay out of the method.

Competency is a different thing, and it's cheaper to fake. It's the real ability to do the work and exercise judgment under pressure (technical skill, sure, but also knowing what an actual risk looks like versus an imagined one, and being able to explain a call clearly enough that somebody else could check it). You build this through pairing, through incidents worked together, through reviews that ask "why this and not that" before the risky action, not after the failed one. It takes protected time, not whatever's left over once the first tight sprint eats it. That holds a genuinely uncomfortable line. Good-faith mistakes are the cost of building the skill, and you treat them that way. Carelessness that keeps repeating doesn't get relabeled as a learning opportunity a third time. That's a different conversation, and you have it directly, not disguised as coaching because coaching feels kinder in the moment.

I used to think competency was the harder of the two to build. It isn't, or at least it wasn't for most of the people I've watched struggle with this. They weren't short on skill. They were short on context nobody had bothered handing them, and I mistook the hesitation for a competency gap when it was actually a clarity gap wearing a competency costume. Fixing the wrong one wastes months.

Autonomy isn't a trait, it's a measurement

The mistake in the other direction is treating autonomy like something you hand over once and you're done, the way you'd hand someone a badge.

It's not fixed to the person. It's fixed to the decision.

The same senior engineer can hold full intent-based autonomy in a system they've shipped in for two years and need much closer direction the first month they touch a regulatory reporting pipeline they've never seen. Nothing about their judgment changed overnight. Same person, different Tuesday. What changed is how much clarity and competency they're carrying into that specific decision, and getting this wrong in either direction is where the whole thing breaks. Leaving someone under-supported in unfamiliar territory and calling it empowerment does real damage (arguably more than the over-control version, because it's so much easier to justify to yourself in the moment).

Before you hand a decision over, ask five things. Do they understand the outcome, and why it matters? Do they have the skill and context for this specific case, not just in general? What does it actually cost if they're wrong? Is this reversible, or is it one of the rare ones that needs to stay slow? And what specific guardrail would let them own more of it next time?

That last question is the one most leaders skip. It's also the one that actually moves someone forward. "Not yet," with no stated path back, is just a wall.

What you're actually doing

Some days this looks like coaching. Other days it's teaching one specific skill, or just telling someone exactly what to do, flat out, because the stakes are high and the context genuinely isn't there yet. Pretending otherwise, to protect the theory of the thing, would be worse than being direct about it.

All three are the same job, aimed at the same target: growing the person's ability to make the next decision without you standing there. Not this decision. The next one, and the one after that, made by somebody who no longer needs to ask.

This is what makes it safe to move someone into "decide and act, tell me after" instead of reckless. The level was always the right destination. Intent is just the habit that makes getting there something other than a hope.

I first saw intent and competency laid out side by side in a leadership guide a former colleague wrote at CircleCI.

There's one honest test for whether any of this is actually working, and it has nothing to do with how fast decisions move this quarter. Is the team producing more people who can decide, or more people who wait? Can it run for two weeks without you and not visibly wobble? Does authority sit next to whoever actually has the information, or does it sit next to whoever has the title?

Most organizations can answer that last question about themselves. Few like the answer.