The most promotable engineers on a team aren’t the smartest. They’re the ones who never sit and wait to be told what to do next.
Everyone knows the pattern. A ticket stalls because someone needs an answer. They post in a channel, get no reply, and stop. The work sits for two days until a standup surfaces it. Nobody did anything wrong, exactly. But the person who stopped just taught their lead that they need managing. The person who found a way forward taught their lead the opposite. Compound that over a year and it’s the difference between a promotion and a plateau.
Here’s the good news: unblocking yourself is a skill, not a personality trait. You can learn it in a month. And it’s the cheapest career upgrade going, because almost nobody is competing for it.
The book that names it
David Marquet ran the worst-performing submarine in the US fleet, the USS Santa Fe, and turned it into the best. He wrote it up in Turn the Ship Around!, and the core idea is that you push decision-making down to the people doing the work instead of up to the people with the rank.
But he’s blunt about the catch. You can only push control down where two things already exist: competence and clarity. Competence means the person knows their craft well enough to make a good call. Clarity means they understand what the organisation is actually trying to achieve. Take either one away and pushing control down just produces fast, confident mistakes.
That’s the whole model for unblocking yourself. Get good, get clear, then move. Three parts.
Get good, and keep getting better
You earn the right to act without asking by being someone whose calls are usually right. There’s no shortcut around this one.
For most people reading this, that means being deeply competent at software engineering and treating it as a thing you keep sharpening, not a box you ticked when you got hired. Know your stack cold. Read the code around the thing you’re changing, not just the thing itself. Understand why the last decision was made before you overturn it. The engineers who unblock themselves safely are the ones who’ve built enough judgement that their default move is usually the right one.
This is the part people skip because it’s slow and unglamorous. It’s also the part that makes the other two safe.
Get clear on the outcome and the guardrails
Before you can sprint, you need to know two things cold: what the team is actually trying to achieve, and what you’re not allowed to break getting there.
The outcome is the destination. Not the ticket, the outcome. “Ship the checkout flow” is a ticket. “Let a returning customer pay in under thirty seconds without a support call” is an outcome. When you know the outcome, half the blockers dissolve, because you can see which ones actually matter and which are just details you’re allowed to decide yourself.
The guardrails are the non-negotiables. Don’t touch the payments schema without review. Don’t ship anything that breaks the public API. Keep it accessible. Stay inside the security model. Every team has these, and most never write them down, which is why so much time gets lost asking permission for things that were always fine and occasionally shipping things that weren’t. If your guardrails are fuzzy, that’s the single highest-value question you can ask your lead this week.
Then sprint
Once you’re competent and clear, the move is simple: run at the outcome and stay inside the guardrails. Stop asking “can I?” and start saying “I intend to.”
That phrase is straight from Marquet, and it’s the mechanic that changes everything. Instead of “should I roll back the migration?” you say “the migration’s causing lock contention, I intend to roll it back and re-run it off-peak unless you see a problem.” You’ve done the thinking. You’ve made the call. You’ve left a five-second window for someone senior to stop you. Nine times out of ten they won’t, because you were right, and you’ve just moved without a meeting.
Do that fifty times and you stop being someone who drains your manager’s attention and start being someone who gives it back. That is the entire game.
Why almost nobody does it
Because it feels risky, and staying blocked feels safe. If you wait and it goes wrong, it’s not your fault. If you move and it goes wrong, it is. So most people wait.
But that safety is an illusion. The engineer who waits is quietly telling everyone above them that they need supervision, which is the one thing that guarantees they stay exactly where they are. The engineer who moves, within guardrails, on a clear outcome, backed by real competence, is the one who gets handed bigger things. It’s not close.
Get good. Get clear. Then just f**king ship it, inside the lines.
If your team is full of people waiting to be unblocked, the problem is usually fuzzy outcomes and unwritten guardrails, not lazy engineers. We fix that fast.