Don't Apologize … Analyze
Tell them why "this won't happen again"
On a team of 200 developers, breaking the build was a bad thing. You blocked testing, self-hosting, and further development. Everyone tried to be careful, but inevitably, amongst hundreds of check-ins, someone would break the build. The original solution was some shaming device. One team had a “fruit of questionable freshness” that was passed around from breaker to breaker. This had the added “benefit” of making breaks in the build later in the product cycle more of a punishment, because the fruit sitting on your desk would be increasingly questionable in its freshness. Whoever had the fruit of questionable freshness would actively be hoping for another build break so that they could unload their desk trophy.
That was fun, and had a bit of a “family ribbing each other” nature to it. But it wasn’t all that productive. The team members were all living in fear of getting some badge of shame if they broke the build. So it was a very welcome change when, over time, this shaming approach was replaced with an explaining approach.
Our software development practices have steadily moved in the direction of becoming software engineering practices. When we started viewing ourselves and our work more through an engineering lens, we got more structured … and more professional. One valuable maturation was our adopting of engineering’s Root Cause Analysis (RCA) approach. When a bad bug was discovered and repaired, management could request a root cause analysis of the bug.
The person who repaired the bug would then perform this analysis, guided by a form that they had to fill out detailing the problem statement, the timeline, the root cause of the problem, the immediate corrective action taken, and then the mitigation plan to reduce the likelihood of recurrence.
We weren’t shaming the person. The person was educating themselves in the process, and then educating management with the report. The motivation behind the RCA approach was to collectively get better by learning from our mistakes. And it worked great for that.
Outside of software engineering, this lesson is still valuable. Telling someone you’re sorry may be kind, but it’s far less meaningful than explaining why it happened and the steps you’ve taken to have it not happen again.
“You can stuff your sorries in a sack, mister”1
As a kid, I loved saying “sorry.” I used that word so often that at one point my father scolded me, “Stop saying sorry all the time.” To which I reflexively replied, “Sorry.” Obviously, that encounter didn’t immediately cure me. But it did happen at a good point in my life, and with my father’s typical deft timing, it left a mental mark. I thought it was a good thing to say “sorry.” But here I was being reprimanded for using it. After the defensiveness wore off, I thought about the “all the time” part of Pop’s message, and realized it wasn’t that sorry was a bad statement, it was that I was overusing it, thereby diluting the effectiveness of any of my apologies.
At work, in a management role, I experienced the same frustration as my dad had felt with me. I found apologies from my reports to be very empty. Not because they weren’t sincere, but because, in our professional setting, I couldn’t do anything with them. So I tried to model a better behavior. I showed my team that I was human by screwing up, and then showed them a healthier way to move forward from the mistake. I would apologize first, and then I would talk about the changes I made in my own approach to prevent it from happening again.
The shorthand for this approach is called “Don’t apologize … analyze.” To be clear, it’s not that you don’t say the word “sorry” anymore, it’s just that you focus your attention on the lessons learned and the changes to be made.
Making mistakes, professionally
We’re all professionals, so we should behave professionally. When you make a mistake, don’t hide from your team. Don’t avoid calls or text threads with them. Don’t lower the blinds and close your door. Recognize that it was a mistake, and do a 5-minute informal RCA on the experience. Then share that with your team.
It’s understandable to have an internal shaming response to your mistake. But push through that. When you do it repeatedly, you will find this shaming voice gets quieter. This is an Actor/Observer2 moment, where the Observer Self healthily distances themselves from the Actor Self. You ask yourself the question, “What was I thinking?”, not pejoratively but objectively. You are detached enough from the event to not have the amygdala kick in and raise a defensive wall. You take yourself less seriously, in a very good way.
The ick feeling you get from messing up is good … in moderation. A healthy amount of ick generates productive guilt, that will drive you to want to change to avoid that situation from happening again. Productive guilt results in you Working the Problem3. Too much ick will lead to paralyzing guilt, which will just drive you to curl up in the fetal position, being no help to yourself or to any of your team.
Still there’s the stigma
It’s one thing for you as the leader to embrace this objective analysis for yourself, and another thing to have the team comfortably adopt it for themselves. Framing makes all the difference. In the documentation of our RCA process, as well as at the start of every RCA meeting, we said the following: “Thank you all for taking the time to do this RCA analysis. You’re not on the hot seat today. You’re not in trouble. You are here to share how we can improve as a team. Thank you for taking this seriously.”
It’s not about trying to embarrass or shame people. It’s about the potential for improvement. We are learning as we go. We all make mistakes. In fact, mistakes are better learning opportunities than successes. Analyzing why a failure happened improves critical thinking and problem-solving. We become more aware of gaps in our knowledge base. You are better for the RCA, and the team is better for the RCA.
#alwayslearning!