Reasons and Excuses

In my role as a consultant and team lead (and in my past role as “the IT guy”), I’ve had to share a good chunk of “that doesn’t work” messages with uers. A key skill set I am always working to refine is communication – in-person, recorded, or email. As I work to bring new consultants up to speed, I find myself trying to quantify some of this internalized learning to make it easier to share and distribute.

I have been thinking a lot recently about reasons and excuses. Or reasons versus excuses, to be exact.

We all know the definitions. But, there is a fine line between the two, and I have been trying to lock down what tips what is said one way or the other.

A reason is something to build on. It’s a piece of information that starts to resolve something. You could say something like “The software isn’t supposed to act that way.”

While an excuse is a show-stopper and a deflection. It passes responsibility to someone other than the speaker. It could be something like “The software isn’t supposed to act that way.”

See the problem?

I think what I have come to is that it’s not the words, it’s not the actual phrase. It’s the intent. And for that, you can’t snag a single sentence out of a conversation or email. You have to build on your experience with the individual, the tone of the conversation, and even sometimes what your face looks like (I have been told that I have a default expression that doesn’t always convey “I’m happy to see you”.)

There is, of course, one very easy tactic to make sure the person you are supporting knows that you are in the long haul with them. Simply follow “The software isn’t supposed to act that way,” with “Let’s see if we can figure out what happened.”

And then do that.