Everyone makes mistakes from time to time. It is part of life and part of business. The only question is how you react to the mistake. Do you deny the mistake or do you admit to it and use it as a learning experience? It amazes me how many business (and political) leaders first try denying the mistake before they change their story and finally admit to it.
One of the true signs of a leader is how they handle mistakes. This applies to mistakes made by yourself, your team, or your organization. The following three steps will get you there.
Step 1. Admit the mistake
This crucial first step allows you to step up and take responsibility for the mistake. If you or your organization makes a mistake, it is always best to quickly admit it to. Many leaders spend a lot of energy trying to brush the mistake under the carpet or blame someone else. This strategy of hiding or not admitting to mistakes pretty much always backfires and makes the situation worse as you begin to lose trust. Instead do the opposite and take responsibility as soon as it’s clear that you made a mistake. Doing so will actually build trust as people will understand that you are taking responsibility for your (or your firm’s) actions. Remember that your boss, your employees, your peers, and your customers are watching.
In taking responsibility, don’t blame others as the reason you failed. If necessary, issue an apology but keep it short and to the point. The faster you get through this step, the better as it will cause others to start looking at the solution instead of focusing who is at fault.
Step 2: Analyze the root causes
Figure out what really happened that caused the problem to occur in the first place. Don’t just look at the symptoms but also evaluate what were the underlying reasons that caused this to happen. You need to keep asking “why” until you have a clear understanding. For example, if this was this a lapse of judgment or a communications error, ask why did this happen? Does this person have the proper training? If your team delivered something that was poor quality, ask why did this happen? Did you have the proper quality checkpoints in-place? Were the teams properly briefed? Remember to always look for the core problems, which may not be obvious at first.
Step 3: Make changes
Figure out what needs to be changed and make those changes immediately ensuring that this never happens again. Put a plan into action and put a deadline around it.
Use this as an opportunity for learning and coaching. Coach the person on your team who made the mistake focusing on what they could do different the next time.
A Real Life Example
A couple of years ago my team screwed up on an email blast for a major CPG client. Our team was testing an email newsletter that they coded and during the test, it was supposed to be sent only to a small group of internal reviewers to review the email. Our developer accidentally sent the test email to a larger distribution list containing thousands of real customers. To make matters worse, we only found out when our client called us. Obviously they were not happy with us.
The situation was a disaster. This was a client had lost trust in our ability to deliver because of the failures of our predecessors and with this crisis, we were concerned that they would use this as reason to end our multi-million dollar a year relationship. The first step that we did was a quick analysis of the situation where we realized that this was our fault. We immediately told the client that and that we will get back to them within four hours with details of what happened and an action plan.
We then moved onto step two where we analyzed what went wrong. At the surface, the problem was first diagnosed as being caused by the developer selecting the wrong email distribution list. We discovered a number of failures that caused this to happen (which happens quite often). However after asking “why did this happen” many times, we realized that although the developer made a mistake, there were other major underlying reasons behind this.
First the development technical environment was not setup correctly as the developer was working directly in the live production environment, instead of a safe testing environment. Second before any emails are sent out to more than a handful of people, we should have been using an automated checkpoint that requires a second person to approve the email (this is already built into the software but we failed to use this safeguard). Third when the developer realized that a mistake was made, they panicked. They should have immediately notified the email vendor who could have stopped the emails on the back-end but instead they tried to delete the request to submit the email on the email vendor’s system, which only made manners worse because it made it impossible for the email vendor to now help. Forth, the team lacked real training on the vendor’s email platform. Fifth, as soon as the developer realized that something was wrong, they should have immediately raised the issue to senior management.
Once we had this information, we moved to step three where we shared with our client our 30-day plan for correcting all of these areas.