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.
