On Apologies 7
Recently, Seth Godin posted a short blog post, titled, Apologies, ranked, which points out several ways of apologizing. When you work in a service industry, it becomes very important to develop good apology skills. Let’s be honest for a moment. Not everything works out for the best in every customer experience. Sometimes it’s their fault and many times… it’s our fault.
In response to Seth’s post, Marc Chung has written up a similar post that adapts this to software bugs, titled, Seth on Fixing Bugs.
It’s worth a read and definitely relates to the communication issues that we keep talking about within the Dialogue-Driven Development community and how that can translate to a healthy testing process with BDD.
Thoughts?
Enjoying the content? Be sure to subscribe to my RSS feed.
My (new) manager told us that we were to not accept responsibility for problems or mistakes, that it is always the fault of some /thing/, be it a gadget or a piece of software. I personally think that is utter BS and does nothing but continue the myth that IT is filled with stuck-up, arrogant fools. But that’s just me.
Eliminating Apologies Apologies Are Abused Why We Make So Many Apologies What’s Wrong With Apologies People hate apologies Whose mistake is it, anyway? Apologies don’t work Eliminating Apologies Making apologies unnecessary Positive feedback Aren’t There Exceptions? Improving Apologies: The Last Resort The End of Apologies
[Sorry, the first version came out wrong.]
“My (new) manager told us that we were to not accept responsibility for problems or mistakes, that it is always the fault of some /thing/, be it a gadget or a piece of software.”
What a disaster….. that’s like how I was once told that you should never admit any fault in a traffic accident, and leave that to the insurance companies and their lawyers.
Never admitting to mistakes breeds mistrust and a collapse in a working relationship.
In my response to Marc’s comments several days ago, let’s not forget that we do need to consider business and user priorities when evaluating bugs. The best response to an issue isn’t always to fix it.
Robby,
I didn’t mention it in my post, but it’s also important to ask if a bug should be fixed. I hope I don’t receive too much flack for that statement :-). Thanks for the link.
—Marc
Didn’t Dilbert say something like “An engineer’s career was a success if he was never blamed for a major failure”?
Humor aside, there’s a big psychological / ego thing involved in admitting to a mistake. Some folks just can’t do it, it threatens who they are in their own minds. It takes maturity to step up and say “I made an error”. Personally, I have had >1 opportunity to do this over the last 30 years or so :-)