How my client taught me to be a better consultant by showing me how to own my mistakes.
I have a client who runs a marketing and customer engagement strategy consulting company that focuses on delivering brand loyalty programs for retail shopping chains. One of the largest of such programs is for an international brick-and-mortar retail chain, covering both their online and in-store loyalty and rewards tracking. On the back end of that is a custom system that we’ve built and extended over the course of about 9 years. It’s a high-volume, high transaction system, and it’s absolutely mission critical for that chain, and for my client. On top of that, we’ve also handled all the operations and deployments of the system for all that time as well.
Needless to say, over the course of the last decade, we’ve made mistakes. Some big, some small, ranging from “we forgot to get in that feature you asked for” to “we had a bug that is giving everybody twice the coffee buying credit they should be, and they’re earning free coffee twice as fast as they ought to.” One of the great things about working for this client is that he’s in turn a consultant to his clients. He understands the kinds of things that can happen on our side of the table. One of the hardest things about working for him though is…he’s a consultant to his clients. He understands what good customer service is, and he expects it. He’s no bully – but he’s got high expectations, and he expects a true partnership mentality from the people he works with.
Early on, the project went through a period of not doing well – we didn’t have our ducks in a row, we didn’t anticipate the load of transactions that were coming through it, we didn’t have good rollback and retry capabilities built in, etc. We had to do a lot of apologizing and explaining of “issues” to our client. Finally, one day, after listening to us bumble our way through an explanation, he interrupted us on the phone and said, “Look – if you’re going to tell me bad news, this is how you do it.” And then he laid out what we now call the 5-Phase Consulting Apology.
No project goes smoothly all the time. There are always issues. There are always challenges. Sometimes, it’s on the client. Sometimes, it’s on us. When it is on us, the best thing you can do is get ahead of it. Bad news does not get any better with age. Attempting a cover up or a quick scramble to hide the mess rarely works.
That said, there’s a good way and a bad way to admit a mistake. Part of it is establishing the right tone – a.k.a, how you communicate it. (see Managing the Emotional Pendulum for what I’m talking about.) The other part is what you convey. The 5-phase apology is a framework for helping you make sure you cover the “what” completely.
The 5-phase apology is pretty simple (after all, it’s just 5 steps). And here they are:
- Get on with it. Just admit the issue: “I messed up.”
- Explain exactly what happened.
- Explain the impact of what happened.
- Explain what you’re doing to contain or mitigate it.
- Explain what you’re doing so that this issue never happens again..
1. Get On with it – “I messed up.”
This is the most important step of the five. A frank admission up front disarms the other party. If they already know there’s a problem, this takes some of the wind out of their sails if they’re irate. If they don’t know about the problem yet, this makes them aware that there is one, but also makes it clear to them that you own it. Nothing quite puts people’s guard down like a frank admission of ownership of a mistake. It can look as simple as this:
“Bob, there’s something I need to let you know about this morning. After reviewing the application logs, I realized that I made a pretty bad mistake on the last deployment.”
2. Explain What Happened
This is the most important step of the five. After admitting accountability for a bad outcome, you need to move to laying out exactly what happened. When you do this, you don’t want to focus on the technical or code aspects, unless you’re talking to another software developer. “We applied a unit of work pattern and forgot to apply Dispose semantics on the class, so transactions weren’t ever getting closed” is a terrible explanation of what’s wrong. “Our last deployment has a bug in it, and the result of that bug is that for the last two days, no customers have been getting credit for their coffee purchases.” is a good explanations of what’s wrong.
3. Explain the Impact
This is the most important step of the five. You need to make sure the client is completely aware of the full impact of the problem. For example,
“There have been 2,345 coffee purchases made since yesterday. We’ve confirmed that none of them got credited to the customers for their reward points. So far nobody has called in to customer service complaining about a missed reward, but it’s possible that you might see an increase in support calls starting today because of this.”
4. Explain the Mitigation Plan
This is the most important step of the five. You need to lay out a clear plan for how you’re going to mitigate and contain the impact, keep it from propagating, and get things back to “good” again. For example,
“We’ve identified the bug in our code and have established a reproducible scenario in our test environment. We’re prepared to deploy that this evening as an emergency patch. With that correction in place, future coffee purchases will all get credited as expected. We’ve also identified all the purchases the didn’t get their credit, and have a small script we can apply to have those purchases get re-run for credit. This will bring everybody’s coffee credits up to 100% accuracy. If we can execute both of those tonight, we should be able to contain and correct this issue before any customers take notice of it.”
5. Explain the Long Term Plan
This is the most important step of the five. It’s not enough to lay out how you’re going to “fix the glitch.” You also need to make sure the client is 100% confident that you are never, ever, EVER going to make this mistake again. This step is also a great time to work on the emotion pendulum and reiterate your commitment to them as a client, and to their success. For example,
“Bob, the last thing I want is for you to ever worry about this again. I’m doing two things to ensure that these kinds of issues don’t ever trouble you again. First off, we’re extending our test suite to include processing of anonymized versions of the last two days’ worth of transactions, and testing the results against known expected outcomes. Any changes we make in purchase processing will show up there, so we’ll know before we launch if we’ve got any bugs left to work out. Secondly, I’m adding in additional monitoring of spend credits into the production system. If anything slips through our testing, this monitoring will alert us if any spend credit issuance rates per 100 purchases changes, up or down, by more than 10% from the last two month’s average. This alert will give us a chance to investigate and identify the source of any possible problems within hours of a deployment, instead of waiting for someone to happen to read through the purchase logs, or even worse, to have to hear it from a customer. Do we have your support to implement those improvements in the next deployment?”
Most of us are conflict averse and afraid of being “in trouble.” These tendencies work against us in client relationships because we come to see the client as an authority figure who must be appeased, vs. a partner with whom we must establish trust. When we fall into the “they’re going to be mad at me” mindset, we communicate mistakes by hedging, trying to minimize the impact, and trying to spin a positive outlook on it:
“Hey, Bob, just wanted you to know that we did catch a small bug from the last launch. It’s not really a big deal, just a small one-liner in the code that we missed. I’m going to put the fix in tonight, you shouldn’t even notice it. The good news is, we caught it, so that shows you that our process works!”
That kind of “not-an-assessment” happens all too frequently, and causes stakeholders to actually diminish trust, diminish confidence, and lower the likelihood that they’re going to give us more room to operate autonomously in the future. In most cases, they’ll press for more detail, you’ll have to go through the five phases above in an interrogation form, and they’ll be left with the impression that you tried to pull a cover-up on them (because you did!) and that they’re going to need to watch you more closely in the future (which they probably should!)
If you find yourself having to break out the 5-phase apology frequently on a project, you’ve either got a) A client with ridiculously high expectations, or b) a quality issue in your project. Apologies at this level of severity should be rare. If they’re not, your project’s not executing well, and you need to take a deeper examination of the whole system. What that tends to mean is that these incidents aren’t isolated incidents – they are in fact symptoms themselves of an underlying system-level problem. Rooting those out will have to be a topic for another day.
Any time you need to deliver bad news to a client, whether it’s a production bug that slipped by, a feature that didn’t make it in, a schedule miss, a technology decision that didn’t pan out – the 5-Phase Apology is a powerful tool to lay out the issue while still maintaining a leadership position and controlling the client’s confidence in our ability to meet their expectations in the future. Combine it with awareness and control of the emotional pendulum, and you’ve got a strong one-two combination punch to keep difficult situations from spinning out of control.