The 5 why method to nail a perfect narrative for your engineering project
Did you write some code today? Fixed some bugs, prevented a future outage, cleaned up dead code, or completed a new feature for the sprint. But why?
The ‘5 why’ technique for finding defects is commonly used in outage postmortems. Interestingly enough, it is a useful tool for explaining your work to your peers, your manager, your skip, and so on. Storytelling the impact of your work is one of the best ways to stay excited about work and as an additional benefit, accelerate your career.
Each why has an answer to it.
- I wrote code because I had to fix the bug,
- the bug needed to be fixed because it was causing a 1% failure rate for all users using the app
- the 1% error needed a fix because we found that any user experience error resulted in a 5% churn of the user by not renewing the subscription.
- 5% churn was a big deal because it had a direct impact on the long term value of a user aka dollars
- Dollars, because, profit!
Not all answers will be relevant to everyone. Depending on the level of the person you are speaking to, you can pick the depth of the ‘why’, which I call why-depth. Your peer engineer may be interested in the 1% failure rate and its technical reasons. Your CPO likely cares more about the 5% churn impacting the LTV metric.
As guidance pick the why-depth of L-3. If you are talking to an L5 engineer, the why-depth is 5-3 = 2. In this case that would be the ‘1% failure rate’ story. Do not pick a narrative that is too disconnected for the level to maximize the impact of your narrative.
Always know why you do what you do.