Accountable Autonomy: The Leadership Philosophy That Actually Works

There's a persistent misconception in engineering leadership: you have to choose between being hands-on and being hands-off. Micromanage and you stifle your team. Step back too far and things fall apart.

The answer isn't choosing between those two extremes — it's rejecting the premise. What I've built my management approach around is accountable autonomy: not a compromise between micromanagement and neglect, but a third position entirely.

The premise is simple. We hire talented, well-compensated engineers because they are capable of owning outcomes. My job isn't to tell them how to do their work — it's to make sure they know what success looks like, have what they need to get there, and are held to that standard.

Accountable autonomy shows up in specific behaviors every week.

It means setting expectations clearly upfront — not vaguely hoping people figure out what good looks like over time. It means 1:1s that are honest in both directions: what's working, what isn't, where someone is growing, where they're stuck. It means giving credit openly and specifically when someone does great work — recognition matters as much as correction.

It also means trusting people to figure things out while staying genuinely available when they need support. My team should never feel watched — but they should always feel like they can bring me a hard problem and get real engagement, not just delegation back to them.

This is not a soft philosophy.

We pay engineers well. In return, we expect performance at the level we hired for. If someone isn't delivering — if commitments aren't being kept, if the standard isn't being met — we address it quickly and directly. We don't let it sit. We have the conversation, set the expectation, give a reasonable runway, and if improvement doesn't come, we move toward an exit.

I had a senior engineer on one of my teams who was technically capable but consistently missing sprint commitments and deflecting feedback. After giving it some time, I had the direct conversation: here's the pattern I was seeing, here's what needed to change, and here's the timeline. When improvement didn't come, we moved toward a transition. It wasn't comfortable — but the team noticed, and the standard became clearer for everyone.

This isn't harsh — it's respectful. Letting underperformance linger is actually the unkind thing to do. It's unfair to the rest of the team, it signals the standard doesn't matter, and it ultimately doesn't serve the underperformer either. Decisive accountability tells people that their work matters and the standard is real.

As organizations grow, micromanagement collapses under its own weight. A manager can stay close to three engineers — not thirty. The only thing that scales is a culture where people hold themselves to a standard because they believe in it, not because someone is watching.

Accountable autonomy scales because it's built on principles, not proximity. Each layer of the org — manager, lead, IC — knows what they own, has the authority to deliver it, and is held to the outcome. When I'm not in the room, the standard doesn't change.

Stop choosing between trusting your team and holding them accountable. In accountable autonomy, they are the same thing.

That's the highest form of respect you can give a capable engineer — and the foundation of teams worth leading.