Speaking Technically: Failing Upwards
I once spent ten hours patching code in the wrong branch, and accidentally released a half-finished mess to QA.
I once made changes in a dev environment, without putting them in source control- only to have the dev environment wiped and re-built.
I once added a new feature to a legacy code-base, littered with dead branches and undocumented functionality. Developers before me had just tapped against one method and watched the entire program come crashing apart in a thousand twinkling shards of glass. I made a huge change, and ran it…
… and it worked. The first time.
Oh no, what did I screw up?
There’s a lot of failure in IT. It’s baked into our jobs. We build test environments that attempt to mirror our production environments, every programming language has some sort of exception handling, we constantly take backups, snapshot our VMs, and write back-out plans.
Solving an IT problem is a series of experiments. I try one thing, and see if it works. When (not if) it doesn’t, I cycle through until I get the result I want. Then I start over on the next problem.
IT is failure: embrace it
Our job is, in essence, to fail gracefully. When we talk about our jobs, though, you often miss it. At The Daily WTF, where we catalog catastrophic failures in the IT industry, only a small fraction of our submissions are “true confessions” where we own up to our failures.
We’re conditioned to be perfect, by society-at-large and the industry itself. Focus on success, sweep failures aside. The problem here is that we drain our technical stories of life. Characters that succeed all the time aren’t exciting, and stories that just stack one success atop the other come off as dull bragging. We lose the learning opportunities that come from failure.
In Star Wars, once the Death Star is introduced, we know the heroes are going to destroy it. As the film nears its climax, a squadron of small fighters needs to make an extremely tricky shot or the Rebel base will be destroyed. Deep down, there’s no suspense here- we know that the good guys are going to win. So what happens?
A chain of failures. Rebel fighters die in droves. One pilot nearly makes the shot, only to declare, “It just impacted on the side!” Darth Vader takes out Luke’s escorts. And just when everything is as bad as it can get, Han Solo shows up, Luke deactivates his computer, uses the Force, and boom- problem solved.
By stacking the failures against our heroes, we make the path to the end interesting. Even though we know it works out in the end, it’s the path there that keeps the audience engaged. We get to watch the characters struggle, grow and change.
A veteran is just someone who’s made more mistakes than a beginner. Anything you do in IT is going to involve going down a few blind alleys and making mistakes. Work these details into your stories. Revealing bumps in the road will help hold the audience’s interest, and injects a sense of real honesty into the story. That vulnerability helps the audience bond with you, the storyteller.
If you’re still feeling shy about admitting mistakes, keep a few things in mind. Everyone in the audience can call up a litany of embarassing mistakes of their own. We learn through failure, and we don’t need to hide that. You’re helping your audience by showing them what not to do. They can avoid your mistakes. Finally, understanding not just the end result, but the path to success makes the lesson more valuable and memorable for your audience.
Storytelling enhances every aspect of your job: debugging, requirements gathering, interviewing, learning new tools and platforms, knowledge transfer, and more! If you’d like to transform the way you communicate, sign up for my upcoming workshop with master storyteller Kevin Allison.
October 19th
1–4PM
Rehearsal Studios at CUBE PGH, 5877 Commerce St, Pittsburgh PA 15206
With less than two weeks left, seats are filling up fast. Grab yours now!
Sign up today.
Other “Speaking Technically” articles: Personification, Driving Change, Detail Oriented
