The Problem With Your Explanation

I just got off a call with a service provider that left me mad. Earlier this year, I contracted his weed-killer services to rid my backyard of weeds. He uses a chemical process that he guaranteed would keep my backyard weed-free for at least six months. It’s been three months, two applications, and a couple of hundred bucks now, and my backyard looks just as wild as it did when I first contracted his services. On our call, weed-killer guy launches into a lecture peppered with phrases like, “Remember when we spoke I told you…”, “Let me explain how this chemical works…”, “its not a single event, its a process, and it only works if we stick with it…”. I understood that he wanted to retain my business, but I couldn’t help suspecting that his first instinct was to convince me of his competency. Even if doing so involved making me seem unreasonable for expecting fewer weeds in my backyard.

I’ve participated in similar conversations at work. Both as an engineer and as a client to engineers. Unfortunately engineers are notorious for taking this approach to dealing with client issues. I understand why we do it. I also know that, just like weed-killer guy, we are doing it all wrong.

When our clients express dissatisfaction with our work, our first response is to mend our image of ourselves. Rarely is it to acknowledge that the client expected more from us and is having a bad experience as a consequence.

No one who has had a bad experience really wants to hear an explanation of why it happened. An acknowledgement that it was a rotten experience, yes. Perhaps an assurance that it will be fixed, if that’s within our abilities, definitely. Outside of an explicit request for an explanation, the “What had happened was…” response is not only unnecessary, it’s downright counterproductive.

Here’s how a typically engineer-client interaction might play out:

1. Product: I just learned that customers cannot update their credit cards after signing up for our service. Our support team is getting inundated with tickets about this issue and I fear we’ll see some bad press after all the publicity this launch got us.
2. Eng: I told you guys that our downstream payment processor doesn’t give us the details of a user’s account for at least 24 hours after we establish it. We don’t have enough information to issue an update within that time window. If we tried, we would end up with duplicate account information.
3. Product: But the current user experience is untenable. The promotion we run last night got us thousands of new users, many were not expecting us to charge a one year subscription upfront. Their cards got declined and they can’t give us a different card if they wanted to.
4. Eng: Why didn’t they read the details of the promotion? We made it clear that we would charge them for a year upfront instead of the recurring monthly charge. Wasn’t that the whole point of the discount?

If this seems typical to you, even expected, don’t worry, I suspect its par for the course for most engineers. Here’s an alternative exchange:

1. Product: I just learned that customers cannot update their credit cards after signing up for our service. Our support team is getting inundated with tickets about this issue and I fear we’ll see some bad press after all the publicity this launch got us.
2. Eng: That sounds terrible. I imagined this could happen but I assumed most users would understand the terms of our promotion and sign up expecting a full-year subscription charge. Do you have thoughts on what we can do to get things back on track?
3. Product: Couldn’t we just allow credit cards to be updated within 24hours? It’s an unreasonable requirement. I never understood it and our customers don’t either.
4. Eng: There are downstream requirements that drove that decision. Of course, now it’s clear that the UX implications are not desirable. I can think of a few ways we can alleviate user concern: First, our users are not aware that we intend to charge them a full year’s subscription vs our normally monthly rate. We should make that clearer upfront during sign up. Second, we should take advantage of the fact that we send custom card-decline notifications and delay that email until after the 24hr window. Finally, we should include a notice on our billing page so that customers that visit within the 24hr window are told upfront that billing updates are unavailable but that they can check back in a few hours. This way, they do not have to write in only to learn that there’s nothing we can do on our end. These are all near term bandaids, of course. But they can be done quickly, allowing me to do some research into what other integrators have done to handle this issue. I will also give our payment processor a call to see if there’s anything we’re missing that could help.
5. Product: Can we simply switch payment processors? We can’t be the first product charging subscriptions, what do our competitors do?
6. Eng: We considered several processors before we settled on these guys. This is a major drawback, but each processor will have its issues. Besides, switching to a new service provider is not something we can do quickly, and not without risks. Let’s consider that a last resort if our short-term solutions and research efforts don’t alleviate the problem.

The engineer in both scenarios comes across as technically competent, however, the alternative scenario engineer sounds a lot more mature. The real difference here is that she — our smarter engineer is woman ok? she recognizes that the product manager (also a woman — why not?), is frustrated (maybe even disappointed?). Our alternative engineer is confident enough in her abilities and can discern that issues with her work don’t reflect incompetence, and she doesn’t need to defend her work. Instead, she spends her effort acknowledging that high ticket volumes and unhappy end users are neither intended nor desired outcomes. Second, that she has more context than the product manager and is in a better position to help turn things around.

Note that our alternative scenario engineer is equally unwilling to promise solutions that she knows the infrastructure cannot offer. In the real world there just aren’t always quick eng fixes.

As an engineer, a leader, and mentor to other engineers, I often need this reminder:

1. I can acknowledge a client’s dissatisfaction with my work without feeling less competent.
2. The client comes to me not just because of an issue but in spite of it. If I can empathize with the concern, I have an opportunity to turn this to my advantage.
3. An explanation is a powerful accountability tool, but isn’t appropriate at the moment my client lodges a complaint. A follow up post-mortem can be an even more powerful demonstration of competency and professionalism later.

So to weed-killer guy, myself, and engineers just like us: The problem with your explanation is not the explanation, or even how you delivered it. The problem with your explanation is that it just wasn’t called for.

And, I still have weeds in my backyard that need taking care of :(