How to report screw-ups without losing trust
Every once in a while you (or your team) will screw up.
The best thing you can do, when you inevitably screw up, is to own up to it and take responsibility.
Reporting and communicating on this can very easily be lost in the chaos of the day, so here’s a template to help you not forget the most important things.
Never let the rush and thrill of things going wrong and then fixing them get in the way of good communication.
This communication is exactly how people will remember how you handled the situation because this is the only thing that they will read.
They will not know about the sleepless nights you spent on this bug, but they will remember the tone, voice, and content of what you posted, so it better be good.
Here’s the template:
Template
- Summary
- Sketch the context: Give a one-line summary of the context. (Ex. After launching project X we observed that)
- Frame the problem and solution: Here you write down the problem/bug that you found and how you fixed it. (Ex. We drilled down the problem to be X and we resolved it by doing Y)
- Discuss the impact on the end-users: Now talk about the impact this had on end-users. (Ex. The impact on end-users was that users of segment X got wrong growth predictions in time period Y resulting in Z, because of this…)
- Next steps: Finally talk about the next steps the team is going to take. Either how to fix it or how to ensure that it will never happen again.
- Details
- Write down the details about how you found the bug: For those interested here is a detailed breakdown of how we spotted, found, and fixed the bug.
Why this works?
- It starts with the bottom line up first for business leaders.
- You always want to start with a summary that gives only the most important parts of the story: context, problem, solution, next steps. This is incredibly helpful for business leaders and executives that just want to know what happened on a high-level.
- It talks about the end-user impact.
- Always always always talk about the actual impact this bug had on users. If you don’t, then the very first question you will get lobbed at you is “what was the impact on our users?” I guarantee you this. And if there is no impact on end-users, is it even worth writing this?
- It has technical details in the back for engineers.
- You were probably stressed, but trust me, when end users are on the line business leaders are probably even more stressed. Executives and other business leaders don’t care about the nitty gritty detail, but they do care about the problem, solution and the impact it has had on real users. That being said, engineers do care about the details, so put those in the back for the interested people to read.
Comments