How To Screw Something Up

Screwing up hurts. A while ago I made a hire I was excited about. It turned out to be a really terrible fit for the team and company culture. It blew up in the team’s face leading to pain, failed projects, and an acrimonious departure. What should you do when something fails, especially something you’re responsible for?

Maybe you led a meeting that devolved in to insults, or a project collapsed in a smoldering pile of open JIRA tickets and frustrated users, or your posh and expensive rebranding ended up looking suspiciously like an armpit someone copied from clip art, or you got caught borrowing money from your company to buy assets that you then lease back to your own company. After discarding the immediate bad ideas that pop in to your head (mash a few keys in your email client and blame whatever name autocompletes, pivot to the blockchain, file for IPO), Bob Sutton on the Dear HBR podcast says you should say three things:

1. I screwed up.
2. Here is what we learned.
3. Here is how we’ll fix it.

The Steps

1. Explicitly say “I screwed up.” In the short term, staying silent about failure can feel more comfortable than drawing attention to it by admitting it. When something fails, people generally already know. Acknowledging it lets people know you’re not okay with the way it ended up. Being open also avoids the shame trap of worrying that everyone will someday find out you failed, which can really amp up existing imposter syndrome. If you’re a leader or manager, taking the blame for failures that happen on your watch is part of the job.
2. Say “Here is what I learned.” You should have learned something when things go wrong. If you learned “someone else did a bad job”, you have not actually learned anything. What could you have done to avoid this knowing what you know now? How could you have coached someone, or prepared better, or eliminated risk, or not gotten caught by those pesky regulators (👺)?
3. Say “Here is how we will fix it.” Your future plan should be more than “next time we’re in the exact same situation, we won’t screw it up.” What can you change now? How have you grown from reflecting on screwing up? Having a clear plan of how to fix a failure transforms it from shame to learning and improvement. Postmortems in technical incidents are an example of this. Instead of just wallowing in the muck and blame of an outage, good postmortems result in some concrete improvement to make to infrastructure, training, code, or processes to make future failures less likely or less costly.

An Example

In my earlier example of a wrong hire and subsequent bad performance, I would talk to the affected people (probably my boss and team in this situation) and say something like this:

“I made a bad hire. It hurt the team’s morale, safety, and productivity. I’ve learned I need to give earlier feedback more clearly when there are performance and behavior problems, and to look out for some red flags in the interview process. For the first three months after a new hire joins I’ll do a performance review. I’ll add the following interview questions to my interviews: etc etc etc”

The Conclusion!

Screwing up hurts, but failure is a great teacher. Learning and improving from failure and demonstrating that to others takes some of the sting out of it. I suspect it lowers the long-term cost of failure by increasing the benefits which can let you try more failure-prone things. That seems great!