I told Gillian Jones-Williams my old story when she came on our podcast. First management job. I figured my programming skills made me the natural person to run the team. The harder I tried to stay at the keyboard, the worse I did as a leader. I've written about the left turn before.

Gillian wasn't surprised. She's run a learning and development firm for nearly 30 years, and she named the habit in one phrase. Experienced managers, "particularly engineers," manage with a long-handled screwdriver. They know the work so well, in her words, "they're not focusing on enabling the people, they're focusing on telling them what to do."

I loved the picture. A manager across the room, one long arm over your shoulder, giving the screw one last turn.

Then I went reading and found the same tool in an article about generals. Their handle runs 5,000 miles.

An oversized screwdriver stretching across an open-plan office from a glass-walled room to one programmer's laptop, the programmer's hands lifted off the keyboard

The Generals Got There First

In 2009 Peter Singer published Tactical Generals at Brookings. He quotes retired Air Force lieutenant colonel Dan Kuehl on the "5,000-mile-long screwdriver." Owning one, Kuehl argues, gives a general no reason to use it.

Singer's examples read like a bad week in any engineering org:

  • A four-star general told him, proudly and unprompted, how he spent two hours watching Predator footage, ordered the strike, then picked the size of the bomb.
  • A battalion commander in Iraq had four generals, 12 stars between them, telling him where to position his units during a battle.
  • A brigadier general, four layers up the chain, radioed a captain mid-hunt with orders on where to put individual soldiers.

Singer also quotes Chuck Kamps, a professor at the Air Command and Staff College: "It's like crack [cocaine] for generals."

This didn't start with drones. Singer traces it back to the Crimean War, when generals in England started sending daily plans down the telegraph. Radio pushed it further. During the 1975 Mayaguez rescue, the commander on the scene got so many orders from Washington he turned the radios off. Every new channel stretched the handle. Rumsfeld's network enthusiasts expected the network to decentralize command. Singer reports the opposite.

The tool never created the urge. The tool removed the distance holding the urge back.

A uniformed general in a distant command post reaching toward a video screen with a long screwdriver while a small squad on the hills looks up

Your Version Runs Through GitHub

I've written about approval queues and the manager who reviews every pull request. Those managers built a gate, and you see a gate from a mile off. The screwdriver hides better, because nobody has to wait for you. You reach in whenever you feel like it.

Look at what we've handed ex-engineers in the last decade:

  • The repo feed. You read every commit. You leave a note on a variable name in a draft at nine at night.
  • The dashboard. Lead time ticks up on Tuesday. By Tuesday lunchtime someone has a DM asking what happened.
  • The incident channel. You join, nobody asked you to, and you type the fix. Everyone stops thinking and waits for your next message.
  • The coding agent. This one's new. You last shipped production code years ago. Now you point an agent at your team's branch on Sunday night and "tidy it up" in ten minutes.

The agent worries me most, since it removes the last brake. Rusty skills used to keep old engineers' hands off the code. I've already asked why some leaders give an AI model more room than their own team. Now those same leaders hold a power driver.

I'm not sure about this part: I found no study measuring how often managers use coding agents to rework their team's code. Treat this as my read of where the tools point, without a number behind it.

What the Reach Costs

Ethan Bernstein ran a field experiment at the second-largest mobile phone factory in the world, in China. He hung curtains around four of the 32 line-shifts, which blocked the view from outside the team. Defect-free output on the curtained lines rose by as much as 10-15% after the first week. They kept their lead over the 28 control line-shifts for the remaining five months.

Why? His embedded observers saw workers using faster methods they'd hide whenever someone watched. Bernstein calls this the transparency paradox. Watch people closely and they spend effort concealing their best ideas from you.

It's a factory, so don't copy the number. I do recognize the behavior. Engineers keep branches private until they look polished. Experiments move to a personal repo. Hard questions stop appearing in the channel you read. Your feed looks clean, and you learn less from it every month.

The second cost hits your own judgment. During Operation Anaconda in 2002, Singer reports, American commanders watched live video of al-Qaeda fighters crossing a mountain and still took them for Americans, because the plan put Americans there. The division's fire-support coordinator warned about video seducing commanders into forgetting everything outside the frame.

A dashboard does the same. It shows you what someone instrumented. I made the case for reading these signals in aggregate, never person by person, and the screwdriver breaks both rules.

The third cost is the one Singer nails in a single question: "While this general was doing a job normally entrusted to junior officers, who was doing his job?"

Your team's strategy, your hiring plan, the conversation you keep postponing with the person who's struggling. Nobody below you holds those. When you spend Sunday night in someone's branch, those jobs stay empty.

A small engineering team working happily at a whiteboard inside a tall fabric curtain while a manager's silhouette walks past holding a screwdriver at their side

Why We Reach

Singer calls it the Super Bowl effect. Generals spent their careers preparing for battle and remember their field days as their best. They don't want to miss the big game because a promotion moved them to the stands.

I recognize this one. Before management, I was the engineer people came to when something was on fire. A production incident is the big game. It's fast, everyone's watching, and I knew how to win it. For years I called this diligence, and my team called it "waiting on Ken."

Debra and I see the result in our research. 99.5% of people we surveyed said they'd had one or more types of bad boss, and 80% said they'd had a Micromanager. I doubt many of those bosses thought they were doing anything except helping.

Keep the Expertise. Drop the Handle.

I won't tell you to forget what you know. The evidence runs the other way.

Artz, Goodall and Oswald used US and British data and found a boss's technical competence was the single strongest predictor of a worker's job satisfaction. A study of 62 years of Formula One results found the most successful team leaders disproportionately started as drivers or mechanics.

People want a boss who knows the work. Gillian's complaint isn't about knowing. It's about what you do next.

I'm not sure about this part: neither study separates experts who coach from experts who tighten screws. My claim about the difference comes from Gillian's experience and mine, and I found no research testing it directly.

The US Army, where I served, has spent a long time on this. Its doctrine, ADP 6-0, wants "disciplined initiative" from subordinates, which it defines as "action in the absence of orders, when existing orders no longer fit the situation, or when unforeseen opportunities or threats arise." You don't get this from people who expect a screwdriver through the window at any moment. I covered commander's intent at length in another post. Your knowledge belongs up front, in the intent and in the limits you set, instead of in the last turn of the screw.

Five Ways to Put It Down

1. Write the intent before you read the code. Outcome, limits, and who decides. If you've said those clearly, most of your urges to reach in lose their excuse.

2. Count the layers. Singer's brigadier general sat four layers above the captain. Before you touch anything, name who owns it. If someone sits between you and the person doing the work, talk to the person in between.

3. Slow your dashboards down. Team-level numbers, reviewed weekly. Turn off the repo notifications. Live feeds feed the habit.

4. Turn the fix into a question. You spotted the bug. Good, you're competent. Now ask what they've tried and what they plan next. You keep the knowledge and they keep the screw.

5. Name your exceptions in advance. Data loss, a security breach, someone about to get hurt. Reach in, say out loud you're reaching in, then hand it back. Singer's general had a real argument here... he answered for the strike. You answer for the outage. Being accountable still gives you no reason to hold the tool.

Check Your Own Handle

Open your last week. Count the pull requests you commented on, the channels you jumped into, the charts you asked someone to explain. Mark every one where the owner sat at least one layer below your direct reports.

Then ask yourself Singer's question. While you did those jobs, who did yours?