Micromanagement Is a Coaching Crime
An engineering manager tells me he reviews every pull request personally. Every one. A team of eleven, and he's the last set of eyes on every line of code before it ships. He says it like it's a badge of diligence. It's a confession.
I asked him what happens when he's on holiday. He didn't have a good answer.
The engineering version of this failure is everywhere
Micromanagement in engineering doesn't look like standing over someone's shoulder. It looks like requiring sign-off for changes not needing it. It looks like a deploy pipeline unable to run without one specific person clicking approve. It looks like an incident channel where nobody acts until the senior engineer weighs in, even at 2am, even for a rollback anyone on the team is qualified to make.
Ask around your own org: how many decisions genuinely require you, versus how many require you only because you never built the guardrails letting someone else make them safely? Different problems, different fixes. Most leaders treat them as one and the same.
Garry Ridge ran WD-40 for 25 years without this problem
Garry Ridge was Chairman and CEO of WD-40 Company for 25 years, scaling it to operations in 176 countries. His stated philosophy: leaders don't manage people, they help them get to where they need to be. Not a slogan. A structural choice about where control lives in an organization.
The mechanism he built the company around is what he calls learning moments. When something goes wrong, the question isn't who's to blame. It's what did the team learn, and how does the org get smarter because of this instead of more afraid. Ridge talks about leaders "creating the weather" in a company: the emotional climate deciding whether people surface problems early or hide them until they're unfixable.
This distinction matters more in engineering than almost anywhere else in a business. A team hiding problems because their manager punishes mistakes is a team where the outage report arrives an hour late, and where the fix ships without proper review because nobody wanted to escalate to the person who reviews everything personally.
Ridge's book carries the title "Any Dumb Ass Can Do a Multi-Billion Dollar Brand." Read past the joke and the argument is serious: building something big isn't a matter of hoarding genius at the top. It's a matter of building systems ordinary, capable people run without a single irreplaceable expert standing over every decision. He later spent years teaching corporate culture as an adjunct professor at the University of San Diego, turning the same principle into a repeatable framework instead of a personality trait unique to him.
Why the controlling manager becomes the outage
Here's the part engineering leaders miss. Micromanagement in software doesn't only slow a team down. It builds a single point of failure into your org chart, and it's you.
If every deploy needs your approval, your vacation is a deploy freeze. If every architecture decision routes through you, your calendar becomes the bottleneck on every project the company runs. You've built the exact failure mode you'd flag immediately in a system design review... a service with no redundancy, all traffic routed through one node, and this node is a human who sleeps, gets sick, and eventually leaves.
Ridge's answer wasn't looser standards. It was clarity over control: aligned expectations, defined guardrails, and trust in people who understand the guardrails not needing someone checking their work line by line. In engineering terms, this is exactly what your CI pipeline, your test suite, your linting rules, and your on-call runbooks are for. They're the guardrails letting you stop being the approval gate. Built properly, they catch what needs catching without a personal read of every diff.
There's a real objection here, and it deserves an honest answer: what about quality? Dropping personal review across the board sounds like dropping standards. It isn't, if you're precise about where scrutiny still belongs. Anything touching authentication, payments, or customer data deserves a second set of eyes, always. Anything routine... a copy change, a config tweak, a well-tested refactor... doesn't need the same person who approves the risky stuff also gatekeeping the safe stuff. Tier your review by risk, not by habit. Most managers who review everything are applying payments-team scrutiny to typo fixes, and wondering why their team ships slowly.
What coaching looks like instead of controlling
The shift isn't from "high standards" to "low standards." It's from standards enforced by one person's attention to standards enforced by the system, with people trusted to operate inside it.
Concretely:
- Replace personal approval gates with automated ones. If you're the required reviewer on every PR because you don't trust the test suite, fix the test suite. It's the real problem, and it's a one-time investment instead of a permanent tax on your calendar.
- Run blameless retros after incidents, every time. Not "who broke prod." What did the system allow, and what guardrail closes this gap. Ridge's learning moments framework exists because blame makes people hide the next problem instead of surfacing it.
- Give someone else the keys to a decision you currently gatekeep, this week. Pick the smallest one. A rollback authority. A deploy window. Notice what breaks. Usually nothing does, and you've proven to yourself the gate wasn't needed.
None of this lowers the bar. It moves the bar into the system so it holds even when you're not standing next to it.
The question worth asking your own team
Disappear for two weeks with no laptop, no Slack. What stops working? Whatever the answer is, it isn't resilience. It's the thing you built wrong.
Coaching means a team getting better whether or not you're in the room. Micromanagement means a team stopping the moment you leave it. Which one have you built?