Owning Failure

In my morning reading, I came across this article entitled, 9 Beliefs of Remarkably Successful People. The article was good overall, but one point in particular struck me.

“Failure is something I accomplish; it doesn’t just happen to me.”

I found that striking because we live in a working world where people…

• Take credit for other people’s successes.
• Fire up the blamethrower to save face. (AKA back over someone with a bus.)
• Rarely give appropriate credit to whom credit is due.
• Often take credit that they don’t deserve.
• Wordcraft their resumes by overstating their roles, responsibilities, or achievements.
• Avoid responsibility for all but routine work, and even then want a policy or process to blame if trouble happens.
• Lie about what they said they would or wouldn’t do when things go wrong.
• Pull other people under the water with them when their ship is sinking.
• Claim ignorance of the overall situation when their actions cause an unexpected problem.

…in the terminology of the defunct American TV series “House”, everybody lies. And yeah, I know they do, but here’s the thing. If you’re a network engineer, there’s not a lot of room for this sort of nonsense. Networks are the lifeblood of corporations, governments, societies, and the world at large. Networks are the enabler of the global economy. Really. They’re that important. It’s not hyperbole…and if you disagree, take your average residential citizen, take away their wireless Internet, cell phone, tablet, and cable or satellite TV. Ask them to pay for goods with cash. You’re wearing riot gear, right? The world as we know it doesn’t exist without networks. Internet? A network (duh). Cell phone? A network. Cable TV? A network. Satellite TV? A network. Paying with a card swipe? A network. Sure, I’m talking about networks with different characteristics and demands, designed for unique purposes and doing a variety of things. But networks connect us all to different goods and services as well as each other. Networks have become such a deep and abiding part of our modern world, that life is unthinkable without them.

The most effective networking team members develop a trust in each other, of necessity. If the network stops forwarding traffic, experiences a security breach, or is undergoing unusual stress, you’ve got to know you can trust everyone to come quickly to the table and help resolve the issue, even if that means confessing to a screw-up. If you’re not able to own your own failure, then you can’t be trusted. And I don’t want to work with you anymore.

If you haven’t failed at something in computer networking, you aren’t trying hard enough. Seriously. Putting new features or a new design into production requires ambition and risk-taking. Certification exams are challenging. Implementing new features just out of beta is hard. Building a new configuration template that will get deployed to hundreds of devices can consequently expose a shortcoming hundreds of times over. But when you fail, you have to own it. You have to step-up, understand what went wrong, learn from the experience, and move on as a wiser network engineer. Or perhaps I should say, “move up,” because often your greatest growth happens while sailing the failboat. Many of the commands in my templates have a story behind them. A security issue. A topology loop that could have been prevented. A redundancy design that didn’t work as expected. A configuration lost. I’ve made all of those mistakes. Yeah, I even typed “debug ip packet” on a busy WAN router once and dropped 1500 people off the network when the CPU spiked. But I only did it once.

Owning failure is not easy. I find failure excruciatingly embarrassing. I’m an introvert, and a big network issue that catches a lot of attention can put me in the spotlight in a bad way. Early in my career, mistakes were of the ignorant kind. Now, they’re more often along the lines of a keyboard accident because I’m tired or in a hurry, or not anticipating a certain circumstance that affects a design. Those failures are rare these days for me, but they happen. There’s always more to know and learn from. Despite the discomfort that a failure brings, I’ve learned it’s best to just own the failure. Yes, I mistyped that interface range command that accidentally clobbered 20 ports instead of 2. No, it wasn’t a mysterious outage. No, the switch didn’t experience temporary insanity. No, we didn’t have a spanning-tree convergence event that caused a temporary forwarding interruption. Here’s what really happened, and here’s how we prevent it from happening in the future. Yeah, it sucks to have to be that transparent, but then the rest of the IT team knows what actually happened and how the issue was fixed. Cause & effect. Trust is restored in the network, and hopefully in the people that operate it.

Now, being willing to own failure isn’t an excuse for stupidity. “Hey, I typed ‘no router ospf 10′ on the core switch again! Oops! Glad we have 2 of them. Ha ha, silly me.” No, no, no. Owning idiocy is different from owning failure. Being bold and ambitious won’t overcome having no idea what you’re doing. So don’t think that admitting when you screw up is some sort of license to go crazy and turn a production network into your personal science lab. After all, failure is still failure. If you fail powerfully enough, you might get fired from your job for it. And probably should.

Take away one big point from my rambling: when you fail, you got yourself there. Almost all of the time, excuses are just that…excuses. You did what it took to fail. You did not do what it took to succeed. Whether a success or a failure, an outcome is the result of actions you took. Therefore, own your failures. The honesty will make you a better network engineer.