A question I often get from direct reports is roughly:

I watch you set people up to take action on their own, even if it seems like they’re going to fail. I want to get better at this as a manager, how do I do it?

I love this question because it’s a critical moment of growth for all managers and leaders. As we have (hopefully) all learned from Andy Grove, your impact as a manager is the total of your impact plus the total of all your reports, and in my experience, there’s no stronger way to help teams succeed than being comfortable with potential failure.

I used to be terrible at this. Early on at Linden I would solve problems by working all-nighters, writing initial implementations with bullshit passive-aggressive names (‘StupidSpaceServer’ was a classic.) Fortunately, I was lucky to work with and for a series of great leaders like Philip and Schrep who — in the very best of ways — gave me no end of rope to hang myself with but who would then react to failure not with anger or frustration but with an immediate desire to celebrate what we had learned. It didn’t really click until Facebook, but once it did I was a far more effective manager and leader.

The management 101 stuff

First, let’s all agree that nobody wants to fail. I sure as hell don’t. I’ve never had teams or leaders working for me who woke up in the morning excited to fail.

Worse, we all hate preventable failure — especially when we know how to solve the problem ourselves. So the high performing IC who’s now learning to be a manager starts exerting too much control, too much oversight, in an effort to prevent failure.

This causes a host of problems.

First, nobody enjoys being micromanaged. Creative problem solvers really hate it. So, you start pissing off your reports.

Second, you never learn what your people are good at or where their weak spots are. How can you possibly set them up for success if you’re just guessing all the time?

Third, and most in violation with Grove’s book, is that you can’t scale as a manager if you’re trying to remote control other people.

So, great. You’ve pissed people off, missed an opportunity to learn, and can’t scale. And even knowing that, how do we get past the fear of failure? How do we enable our amazing people to actually do what they’re great at?

You need to do four things: first, get over yourself. Second, trust but verify. Third, control the blast radius. Finally, fourth, practice.

Getting over yourself

Guess what? If you trust people to do hard things, especially hard, unknown things, there will come a time when you fail. In front of a customer. In front of your boss. In front of your peers.

It’s not awesome. It’s also not the end of the world. Do it enough times and you’ll be the one who needs to change, but failures will happen and the sooner you can handle it, the sooner you get over yourself, the sooner your people and organization will be able to act fearlessly.

Trust but verify

Knowing failure isn’t the end of the world doesn’t mean you should let it happen. Worse, if you just let your reports go wildly off the deep end even if they are building new capabilities — and you’re learning where their strengths and weaknesses are — their failures might be doing more damage than the learning is worth.

So, you have to trust but verify. Or, more strongly, trust and verify. Don’t let projects just vanish, check back in progress, push for short-term updates and outcomes.

More than that, do the hard work. Read every piece of employee feedback during the hardest periods of change. Once your org isn’t tiny, run 360s to help you and your team understand where gaps are. Do the skip level meetings — and encourage people to skip level you — so you’re not blind to problems.

Blast radius

The good thing — at least for engineers — is that we already think in terms of the blast radius for technical failures. O11y, tests, release processes, feature flags, all help us manage technical failures. What’s in place to help detect your organizational zero days, to detect when the failure cases are actually a lot larger than you anticipated? Sometimes it’s as easy as adding a milestone in a week or two.

The weaker your organizational systems are, the more you can choose to rely on shorter time horizons and smaller absolute risks. That way, even if you are slow to detect the failure the downsides are modest.

Answer the damn question

OK, sure — none of this actually answers the original question. Because even knowing all of this, most managers still really struggle with how to let go. How do you get good at this?

And that’s the fourth part: practice. Wherever and however you can, grant some trust to your teams. There will be times it bites you, but in the long run both you and your leaders will be better managers.

And it matters, because there’s no other path that actually works.

You can work around it, just try to juggle more, or layer on a million layers of process, but ultimately you need everyone in the org to have the space and opportunity to learn. Which means failures.

So, accept it.

And when a plan of yours isn’t working, listen and learn.

And finally, be like Mike

Schrep, in this case. We all made mistakes at various times at Facebook. Hell, I shipped the Facebook Phone. Even in those moments, his focus was always “what can we learn.”