how to apologize
I wrote this in the context of company policies at npm, Inc., but since writing, I’ve seen a bunch of examples of profoundly bad apologies, so I’m publishing it here in the hopes that someone out in the world can get a little better at this important life skill.
Sometimes, we’ll do the wrong thing, or make a bad choice, and a Bad Thing will happen that harms someone in some way, making it so that their needs are not met.
In this case, whether they’re a customer, user, employee, teammate, or anything else, the right thing to do is to apologize.
Do not squander this opportunity to express an understanding of another’s needs in crystal clear writing!
Apologies need to have exactly 3 parts:
A Bad Thing happened, and it sucked for you. Here’s a clear explanation of exactly why it sucked for you (what needs you had, and why they were not met.)
It was our fault that the Bad Thing happened. Here’s a clear explanation of what we did that let it happen.
Here is what we are doing to make sure the Bad Thing never happens again, and if possible, to correct the damage done by the Bad Thing.
The bit about how we feel bad, the “I’m sorry” which usually takes center stage of an apology, is often not strictly necessary, and if present, should always come after the three items above.
I tend to steer away from any attempts to make apologies “sincere”, since sincerity is easily faked, and thus abundant and of low value. Strong feelings of regret do not help me know my data is more secure today than it was yesterday. A fig for your “feelings”. Wallowing in sorrow makes it about the apologizer more than the apology.
The first part shows that we understand what the Bad Thing was, and we understand the needs that went unmet as a result of the Bad Thing. This acknowledgement is a fundamental thing that people need when they are wronged. Just getting this right can sometimes repair the relationship, and is already more than most companies and people can manage. But it’s only 1/3 of the apology.
The second part shows that we are not trying to avoid responsibility for the Bad Thing. IANAL, and there may be cases where responsibility comes with some liability. However, in purely emotional interpersonal points, accepting responsibility is generally regarded as a sign of confidence and power. It doesn’t feel that way, but it’s perceived that way.
The third part puts actions to words, and makes us accountable. Never ask for someone to trust you again; an apology is not the place for that. Simply explain what specific actions are being taken (verb, owner, timeline, budget, criteria), and let them make up their own mind. If it actually would prevent the Bad Thing, and if the effect is externally visible, then you’ll either earn their trust or you won’t. But in the moment, you’ll display confidence and strength by being transparent.
Some things that should never occur in an apology:
Before sending/publishing, scan for any of the following, and delete them.
It was kinda your fault that the Bad Thing happened. If you hadn’t been doing some other thing, it wouldn’t have happened.
There was no way anyone could have avoided causing the Bad Thing, so really, it’s not our fault.
We hope the Bad Thing never happens again (but “hoping” is the extent of what we’re doing about it.)
A Bad Thing MIGHT have happened, maybe, I mean, if it did, we apologize, but if not, then we don’t. (For example, “we apologize if this caused you any inconvenience” vs “we apologize for the inconvenience”.)
HOW AWEFUL ARE WE! WOE, WOE UNTO US UNWORTHY SOULS WHO HAVE BESMIRCHED THE GOOD GRACES AND LEGACY OF YOUR TRUST AND GOODWILL! I HEAP DIRT UPON MYSELF, YOUR GRACE! SHAME! SHAME! I KISS THE HEMS OF YOUR GARMENTS, KNOWING THAT I AM UNWORTHY OF ANY – well, you get the idea.
Any expectation, hope, or request for forgiveness. Best to just not mention it. They’ll forgive you or they won’t, but asking makes it no more or less likely, and dilutes the potency of the core apology itself.
Any judgement of any kind. Especially, scan the word “should”, anything implying goodness/badness, degrees of wrongness, etc. It’s not about who’s “at fault”.
When in doubt, anything that isn’t part of the 3 core items should usually be removed. Short focused apologies are better than long verbose ones.
This lines up with the apology strategy I’ve refined over my IT career. The pile of tech will always fail or amplify your boo-boo. Address it quickly and clearly with an explanation and straight up apology. Over time they will forget the problems but remember your sincerity and integrity.