Measure Your Leadership by Your Absence

If you want to know how well you lead, leave. Take a week off, close Slack, and see what your team does without you. If the work keeps moving and decisions keep getting made, you’ve built a team that owns its work. If everything queues up until you’re back, you’ve built a team that waits for you, and that tells you more about your leadership than any engagement survey will.

The vacation test

Most of the signals leaders use to grade themselves are noisy. A velocity chart reflects the backlog as much as the team. Feedback in one-on-ones comes from people whose reviews you write. Your absence is one of the few honest measurements you can take, because nobody performs for a manager who isn’t there.

A failed test looks like this when you get back:

• Pull requests sat for days because you’re the only required approver on the repo.
• A design doc stayed in draft with a comment that says “waiting on you.”
• An incident ran long because the on-call engineer didn’t feel they could roll back without asking first.
• A thread full of good ideas ended with “let’s pick this up when they’re back.”

Nobody in that list did anything wrong. They followed the habits the team taught them, and you’re the one who set those habits.

Decisions wait on context

When a team can’t decide without you, check what they’re missing before you question their judgment. Usually it’s context. You know why the roadmap is in that order, which customer is close to churning, what came out of the planning meeting they weren’t invited to, and how you’d trade a Friday ship date against doing the migration properly. If all of that lives only in your head, every decision has to route through you to pick it up.

I wrote about code that hides decisions in conventions and defaults in Explicit Is Better Than Implicit. Teams fail the same way. When the rules for who decides what are implicit, people either guess or wait, and the careful ones wait.

So write it down: the goals and the order they’re ranked in, the constraints that are actually fixed, the tradeoffs you’d make and why. Then list the decisions that belong to the team outright, and keep the list of ones that still need you short.

Jeff Bezos’s split between one-way doors and two-way doors helps here. A one-way door is hard to walk back through: a public API, a multi-year vendor contract. A two-way door you can reverse if you were wrong. Most of an engineering team’s daily decisions are two-way doors, like which library to use or how to split a large change into reviewable pieces. None of those should wait for you.

Empowerment includes the mistakes

Saying “you own this” is easy. The test comes the first time someone makes a call you wouldn’t have made. If you quietly reverse it, or reopen it at the next meeting, the team learns the real rule: they own the decision until you disagree with it. After that they check with you first, and you’re the bottleneck again.

Some of their calls will be worse than yours. Some will be better, because they’re closer to the code and the customer than you are. For two-way doors, let both kinds stand. Talk about the outcome afterward the way a good retro would: what we expected, what happened, what we’d change. When a call goes badly and the person who made it is upset, listen before you start fixing; the plan for what to change sticks better when it’s theirs.

Letting go is easier when a bad call has a bounded cost. Good tests, small changes, and fast rollback turn most mistakes into a lost afternoon. It’s the same trade I described for agents in Humans Out of the Loop: build the guardrails that earn trust, then step out of the approval path on purpose.

Step back on purpose

You don’t have to start with two weeks in another time zone. Start small and watch what happens.

• Skip a recurring meeting and read the notes afterward.
• Let a question in the team channel sit for a few hours instead of answering it in two minutes.
• Hand off a decision, say out loud that it’s theirs, and then leave it alone.
• Add more approvers to any repo where you’re the only one.

Then take the real time off and unplug. When you get back, look at what stalled and ask why. If they were missing context, you have more writing to do. If they were missing authority, you never said clearly enough that the call was theirs. If they were missing a skill, someone needs coaching, pairing, or a smaller version of the problem first. Every one of those answers points back at work you can do.

A team that runs fine without you frees you for the work only you can do: hiring, setting direction, and the one-way doors. Go take the week off and find out where you stand.