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. A couple of days ago a company emailed me with one such bug and it demonstrated a company that knew how to handle failure.

As you can see from above, BugHerd, a fantastic issue tracking tool had a rather large failure. When you sign up for their service they present you with the option to install the above Javascript on your website so you can get started tracking issues. When people signed up a few days ago that Javascript didn’t work. This meant that users who signed up (myself included) couldn’t use their product through the preferred method.

Obviously this would be extremely confusing for someone trying out their product. I signed up and didn’t understand why the tracking code wasn’t working. BugHeard handled it well and I want to pinpoint a couple of ways on how to fail gracefully.

Be Transparent

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 users faith in your development team and product it goes a long ways 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). Personally I wish BugHeard had given a few more details on what happened and why the Javascript was changed but at least they came forward and said what was wrong.

Apologize

You made the mistake, you should apologize. If you broke someones 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 (like what BugHeard did), but make sure you actually apologize and not just pseudo-apologize.

Fix it Quickly

This one is pretty straight forward. The longer an issue exists the more likely you’re going to lose customers. BugHeard fixed their problem in hours and it really shouldn’t take any longer than that. 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.

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.