Standardization Over Heroics

I’ve been thinking a lot lately about how every IT team has that one person. You know the one. The person who can fix the thing no one else understands. The one who gets called when the integration breaks or when some legacy system starts behaving like it’s possessed.

They don’t need documentation. They are the documentation.

And for a while, that feels like a strength.

I’ve worked with teams where those people were celebrated. “We’re lucky to have them.” “They always save us.” And honestly, that’s true. They do save you. They step in at 10 p.m. They untangle dependencies no one else can see. They keep the lights on.

But the more I’ve watched organizations operate under constant pressure to do more with less, the more I’ve realized something uncomfortable: heroics don’t scale.

In fact, they’re usually a symptom.

When teams are stretched thin, documentation becomes optional. Standards become “nice to have.” Naming conventions drift. Configurations vary slightly from team to team because someone needed to move fast and didn’t have time to align. A workaround becomes permanent because there wasn’t space to redesign the system properly.

And none of that feels catastrophic in the moment. It feels practical. Efficient, even.

Until the day the hero is out sick. Or leaves. Or just finally says, “I can’t keep carrying this.”

That’s when you realize how much of your operational stability lived inside someone’s head.

I don’t think most organizations choose hero culture intentionally. It grows quietly. It grows when there’s no time to standardize. When automation feels like a future project. When alignment meetings feel slower than just getting it done yourself.

It’s faster in the short term to fix something than to formalize how it should be fixed every time.

But over time, that speed compounds into complexity.

I’ve seen environments where no two teams provision access the same way. Where one business unit names resources differently than another. Where security policies technically exist, but enforcement varies depending on who set them up. And it works… until it doesn’t. Troubleshooting takes longer. Audits get tense. Automation becomes harder because nothing is predictable enough to automate cleanly.

The irony is that the more heroic your team becomes, the more fragile the system usually is.

What I’ve come to appreciate is that standardization isn’t about control. It’s about reducing the number of things that require a hero in the first place.

When environments are predictable, onboarding gets easier. When policies are applied consistently, security reviews become routine instead of stressful. When naming conventions are agreed upon, reporting doesn’t require interpretation. When documentation exists, knowledge survives turnover.

None of that is flashy. It doesn’t earn applause. No one writes LinkedIn posts about how smooth the provisioning process was today.

But it’s the kind of quiet maturity that lets a team breathe.

In a world where IT is constantly asked to deliver more with less, depending on exceptional effort isn’t sustainable. Designing systems that work without exceptional effort is.

I still believe in strong people. I love working with talented engineers who can see around corners. But I’d rather build an environment where their insight goes toward improving the system, not constantly rescuing it.

Heroics make great stories, but standardization makes it possible to sleep at night.

And if we’re honest, most IT teams don’t need more heroes. They need fewer reasons to need one in the first place.