Brandt Welker

← Essays

Systems

Hecker's Rules

Mike Hecker flew the A-6 for the Navy and later helped run NASA's exploration program. He had four rules for working for someone, and I still lean on them more than almost anything else I picked up.

·5 min read

Mike Hecker was a guy I met at NASA and later worked for. He went to Annapolis and flew the A-6 Intruder, the Navy’s all-weather attack jet, back when that meant finding a target at night, low, in bad weather, with a bombardier sitting next to you. When he stopped flying he didn’t stop planning missions. He spent years running the Navy’s mission-planning programs and finished his Navy career as a captain at Pax River, in charge of the systems that plan strikes for aircraft and cruise missiles. Then Craig Steidle brought him over to NASA to help run the exploration program.

A laminated card titled "Mike's Laws of Leadership" listing four rules: Follow the chain of command... If your boss doesn't know you're talking to his boss, don't be surprised when your popularity goes down. Run until apprehended... But keep the chain of command informed. Don't always agree with "The Boss..." But when a decision is made, get on with life. Manage your time... It's never a question of what to do. It's a question of what not to do.

That background matters. His rules sound like they came from someone who’d spent a career where a surprise could get people killed and a plan nobody followed was worse than no plan. He had four of them, and he repeated them often enough that you could recite them back to him. I’ve worked for a lot of people since, and I still lean on those four more than almost anything else I picked up.

1. Follow the chain of command. “If your boss doesn’t know you’re talking to his boss, don’t be surprised when your popularity goes down.”

He didn’t want to gatekeep his boss or slow anybody down. He also didn’t want to get called upstairs and asked about something he’d never heard of, then have to defend it or walk it back. And it’s worse than an awkward meeting. Your boss spends credibility on your behalf every time he walks into a room above him, and the fastest way to burn it is to make him look like he doesn’t know what’s going on in his own shop. Notice whose popularity Mike said goes down. Yours. An end-run reads as disloyalty even when you meant well, and people remember that a lot longer than whatever you were trying to get done.

2. Run until apprehended, but keep the chain of command informed.

This is the other half of the first rule. Mike didn’t want people waiting on permission for things they already knew how to do. The default was to move fast and keep moving until somebody stopped you. The second half of the rule is the catch: running doesn’t mean going dark. Read together, I think the first two rules are really one rule: no surprises. Your boss doesn’t need to approve everything you do, but he should never hear about it first from someone else. Hold up that end and you get a lot of room to run.

3. Don’t always agree with “The Boss,” but when a decision is made, get on with life.

Mike wanted pushback on plans and decisions, and he wanted it before the decision, while it was still cheap to change course. I think of it as testing a plan against its constraints, finding where it’ll break before anyone has committed to it. At some point, though, a decision gets made, sometimes one you argued against, and then you execute it as if it had been your idea. Intel under Andy Grove called this disagree and commit, and Jeff Bezos brought the phrase back in his 2016 shareholder letter. I like Mike’s version better because “get on with life” admits you lost the argument and tells you to stop relitigating it anyway. I’ve watched people reopen settled decisions for months, and all it does is make everyone pay for the same argument twice.

This is also where I think the rules can break. Disagree-then-commit only works if the boss actually listens during the disagree part. If he doesn’t, rule three turns into plain compliance, and Mike’s four rules don’t say much about what to do then.

4. Manage your time. It’s never a question of what to do. It’s a question of what not to do.

There are always a million things to do, and nearly all of them look important when they land on your desk. The real job is deciding which ones you’re going to let go. That lines up with the way Elon Musk talks about engineering: the best part is no part, and the first move on a design is to question each requirement and try to delete it. Mike was doing the same thing to a calendar. A lot of what fills a week is work nobody would miss if it stopped, and as far as I can tell the only way to find out which work that is, is to stop doing it.


Mike had one more that I’ve borrowed for talks over the years, and I’ve started calling it Hecker’s law: don’t over-engineer the solution, it will become complex all by itself. It’s rule four applied to the work instead of the week. I’ve seen plenty of teams add the clever extra layer on day one, and the system got complicated anyway, just in directions nobody planned.

None of these rules are complicated, and I think that’s why they’ve held up for me. Most of them come down to not surprising the people around you and not wasting their time. I’ve found that covers a lot of what it takes to work for someone well, and most of what it takes to have people work for you.