Accountability without micromanagement

Most managers oscillate between two failure modes: over-involvement (checking constantly, approving everything, re-doing work) and abandonment (delegating and disappearing, surprised when things go wrong). Good accountability is neither. It's a structured agreement about what, when, and how, with the manager stepping in only when the system signals trouble.

The accountability equation

For any piece of work, four things must be clear:

1. What outcome is expected (not what activity)
2. By when (with milestones, not just a final date)
3. How progress will be visible (what gets reported, how often)
4. What triggers escalation (what would cause the manager to intervene)

Get those right, and the delegated work runs itself. The manager is on call, not on the ball.

Outcomes, not activities

"Manage the launch" is an activity. "Launch with < 10 P1 bugs, > 80% feature adoption within 30 days, no compliance issues" is an outcome. The manager specifies outcomes. The operator picks the activities.

When you find yourself specifying activities, it's a sign you don't trust the operator or you haven't thought carefully about what you actually want.

Milestones, not final dates

"Deliver Q2 plan by June 30" is useless. By June 29 you'll find out it didn't happen. Break it:

• Week 1, draft v1 with 3 candidate approaches
• Week 2, stakeholder review + feedback
• Week 4, v2 with recommended approach
• Week 6, board review version

Each milestone is a decision point. If milestone 2 is off-track, you know 5 weeks earlier than you otherwise would.

Visibility, not surveillance

The difference between accountability and micromanagement is the frequency and format of visibility:

• Healthy visibility: weekly written update (what got done, what's next, what's blocked)
• Healthy visibility: shared dashboard with the outcome metric
• Healthy visibility: pre-scheduled 30-minute check-in
• Unhealthy surveillance: ad-hoc Slack DMs asking "how's it going?"
• Unhealthy surveillance: watching every commit/ticket in real time
• Unhealthy surveillance: requiring approval for every sub-decision

The escalation trigger

The single most important tool: pre-agreed conditions under which the operator must escalate. Without this, either they escalate too much (micromanagement) or not enough (surprise failures).

Example triggers (for a product launch):
- Any P1 bug found in QA
- Any slip in launch date of more than 1 week
- Any customer-facing issue during beta
- Any budget overrun > 10%
- Any scope change from the original spec

Anything else, handle it.

The manager's job, with this in place

1. Help set the outcome and milestones clearly at kickoff
2. Review the weekly update; intervene only if a milestone is at risk
3. Respond fast when an escalation comes, operator needs a yes/no quickly
4. Remove blockers the operator can't remove themselves
5. Evaluate performance against the outcome, not the activity

When to intervene

Even with the structure, managers still need judgment on when to step in:

• Step in: repeated missed milestones, a critical stakeholder in distress, a decision about to be made that has irreversible consequences
• Stay out: the operator's approach differs from yours but is still on track, small mistakes the operator can learn from, decisions that can be reversed

The cost of intervening too early is real, you teach the operator that you don't trust them, and that any setback brings you in. They stop trying to solve hard things.

What good looks like

• Every major piece of delegated work has a written outcome, milestones, and escalation triggers
• Weekly updates are brief, structured, and consistent
• Managers know about serious problems before they blow up, because of pre-agreed triggers
• Operators feel trusted to execute without constant check-ins
• Performance conversations focus on outcomes achieved, not activities undertaken

Related: One-on-ones · Performance reviews · Radical candor