Properly Handling Failures

“Remember the two benefits of failure. First, if you do fail, you learn what doesn’t work; and second, the failure gives you the opportunity to try a new approach” — Roger Von Oech

Every developer has written a bug at least once in their careers. It’s almost a rite of passage to debug faulty code and turn it into something that works. Most of the time these bugs are caught before they ever reach the eyes of your customers but every so often a bug gets through to production. How you handle these bugs can be the difference between a successful program or business and a failed one.

One of the most important things you can do when you screw up is to be transparent. Let your users know what happened, why it happened, what you’re doing to fix it and how you’re going to prevent it from happening in the future. While this doesn’t fully restore your user’s faith in your development team and the product it goes a long way to repairing the broken bridges.

Constant updates help your users know the progress that you’re making to recover from failure and can give them an idea of when everything will be back to normal (if the problem is more than a simple fix).

You made the mistake, you should apologize . If you broke someone’s phone you would apologize and this is no different. By apologizing you’re admitting that you’ve done something wrong and are sorry about breaking something that people use. Apologizing isn’t hard, a simple sorry is enough, but make sure you actually apologize and not just pseudo-apologize.

This one is pretty straightforward. The longer an issue exists the more likely you’re going to lose customers. If the problem exists for more than a couple of hours you should look into compensating your users with either a discount or something else of value. This, in combination with an apology and transparency, should help you keep your users through your failures .

The best thing you can do after failing is to learn from it.

“The only real mistake is the one from which we learn nothing.” — Henry Ford

This is where postmortems come in. By documenting your failures you make it easier to learn from and easier to prevent in the future. You’re building out a repository of information that new developers can lean on when deploying new code. This also helps you prevent similar issues from happening in the future.

There are many different ways to handle failures in startups, companies and individual programs or websites. I’ve outlined the points that I think are important but feel free to comment below on other things that companies should do when something breaks.