We were in the middle of a major merger. Two public companies. Thirteen weeks to integrate both websites and back-end systems and prove to the market we could execute. Vendors had already committed promotional dollars to the launch date. The pressure was real.

My team put together the launch plan and walked me through it. I pushed on every assumption. That's what you do. They had answers for everything.

One question stuck with me. We were about to serve audio content we'd never served before. High volume. New format. Running over infrastructure that had never seen this load. I asked whether they'd modeled the bandwidth. Fiber lines in 1998 didn’t scale on demand. You can't call your carrier on a Friday night and ask for more capacity.

"We modeled it," they told me. "We're fine."

I wasn't convinced. I let them proceed anyway.

Launch day arrived. The software worked. The database held. First hour: smooth.

Then the errors started. Small at first, then escalating as traffic climbed. The entire technology team got pulled into the network operations center. Head of database. Head of software. Head of systems architecture. Head of network. All of them staring at monitors. All of them pointing fingers at each other. Every system looked fine in isolation. The problem wasn't showing up in any single place.

I wasn't in the room. I was running interference with my bosses and our partners. I checked in once and asked again about bandwidth. "Looks fine," they said.

Two hours later, it wasn't fine. It was bandwidth. They'd already reached our carrier, found spare capacity on standby lines, and had everything back up within twenty minutes. Five hours of total downtime. Then it was over.

That evening I was heading out through the back of the building. An old loading dock that served as the unofficial smoking area. The head of network was out there. He called over to me.

"I just want to thank you for letting me do it my way," he said. "And for letting me make the mistake, figure it out and fix it myself."

Two Kinds of Mistakes

Here's the framework I use with leaders: don't prevent scraped knees. Prevent bus crashes.

A scraped knee hurts. You might carry the scar for years. That's the point. The pain is proportional to the lesson.

A bus crash can lead to catastrophic loss. The project. The company. The relationship. Something that can't be recovered.

The leader's job isn't to eliminate mistakes. It's to know the difference between those two things.

Looking back at that launch, I can see why the only right move was to let them try.

If I'd overridden them and done it my way, I become the bad boss. The micromanager. The executive who couldn't trust his own team.
If I'd overridden them and I was wrong, the only thing we’d have learned is that I was a controlling leader. And if I was right, I would have made them look bad at their jobs.
The only outcome that served everyone was to let them take their best shot. They either succeeded, validating their approach, or they failed, fixed it, and learned something they'll never forget.

That's not idealism. That's just math.

I've watched the alternative play out dozens of times in coaching. A leader overrides a call. They were probably right. The team delivers on time. Everyone moves on.
Six months later that same leader is sitting across from me wondering why nobody brings them hard problems anymore. Why the team waits to be told what to do. Why nothing seems to happen without them in the room.
The answer is almost always in a moment exactly like that one. When they stepped in and the team learned that the answer was always going to be the boss's.

Many leaders think they're coaching when they're really rescuing. Coaching helps someone think through a problem. Rescuing removes the problem before they have to. The difference matters because one builds judgment. The other builds dependency.

Why Leaders Keep Stepping In

The harder part is internal. When you've been through a version of something before, watching someone walk into it is genuinely uncomfortable. Intervention feels responsible. It feels like leadership.

Usually it's not. It's discomfort.

Over time, a leader who constantly steps in, who answers before people can think, who redirects before people can struggle, trains people out of ownership. The team learns that accountability and hard decisions belong to the boss. The leader ends up responsible for more. The team ends up responsible for less.

I see it most in leaders who earned their seat by being the sharpest person in every room and haven't revisited that role since.

Letting people try doesn't mean stepping back blindly. The team on that launch had a rollback plan. We could have pulled it at any point. The freedom to fail safely is not the same as the freedom to fail catastrophically.

The question I ask isn't: is someone about to make a mistake?

Of course they are. So am I. So are you.

The question is: what happens if they do?

If the answer is frustration, lost time, a hard lesson, a relationship that needs repair. That's a scraped knee. Let it happen. If the answer is something the company can't recover from. That's a bus. Step in.

Leadership isn't protecting people from difficulty.
Leadership also isn’t protecting yourself from discomfort.
Leadership is creating an environment where people can fall down without getting run over.

The question isn't whether someone is about to make a mistake.
It's what kind.

Hear this story and others in the Tech Leader’s Playbook episode, “Why Startup Founders Must Build Teams That Thrive Without Them.”