Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Dev Report mobile

How We Use the 5 Whys to Learn from F*ck Ups at OfferZen

8 March 2019 , by Robyn Luyt

Most people can identify at least one stubborn or recurring problem that keeps cropping up in their business. These problems are scary because they can result in a massive loss of reputation or customers. Instead of a 'quick fix', the 5 Whys is an effective tool to cut through the symptoms and reach the root cause of the problem. Here's a step by step guide, downloadable cheat sheet and template to help you do an effective 5 Whys with your team.


At OfferZen, we choose to assume that every team member is genuinely awesome, competent, and smart. This doesn't mean that failures don't happen - they do. But, when they do, we think of them as 'system failures' rather than assigning blame to team members which doesn't actually solve the problem.

A system failure is a bug in our processes, systems or ways of working that prevents smart and competent team members from performing at their best.

We believe that good systems are anti-fragile which means that they become more robust as a result of failure. So, in order to learn from our failures and build robust systems, we use the 5 Whys approach, developed by Toyota co-founder, Sakichi Toyoda, to identify the root cause of a problem by asking 'Why?' at least five times. Not only does the 5 Whys help us peel away the symptoms of a problem, but it also helps us:

  • Address mistakes as soon as they happen rather than months down the line,
  • Ensure that every team member has a chance to share their experience, and
  • Make sure that we develop solutions that prevent us from being on the back foot in the future.

But, this doesn't mean we have a 5 Whys meeting for every single failure or mistake at OfferZen. In fact, we make the distinction between a 'good failure' and a 'f*ck up':

  • Good failures: In a startup, we need to fail fast and hard. We regularly run experiments with the explicit purpose to prove or disprove our hypotheses. Even if a hypothesis 'fails', we have still gained insights and learnings, so it's a valuable failure.
  • A 'f*ck up': This is a 'big bad failure'. These are 'big' because they have the potential to pose significant risk to our reputation, mission or customers, and they're 'bad' because they don't prove or disprove a hypothesis that we set up beforehand.

Disclaimer: Based on some feedback we received, we've decided to use 'big mistakes' to refer to what we actually call 'f*ck ups' at OfferZen for the rest of this article.

A 'big mistake' is where the 5 Whys comes in. Here's a decision tree on how we make this distinction:


Needless to say, looking in detail at why a bad failure happened is not a trivial undertaking, so doing a 5 Whys can be hard, especially when the stakes are high. That's why we've put together a downloadable cheat sheet and a template to help you do one with your team. The rest of this article will take you through the steps we follow to pull them off at OfferZen.

Step 1: Deal with fallout immediately

When a 'big mistake' happens, the first thing we do is deal with the immediate fallout. This could mean phoning the affected customer, sending out an email to our newsletter subscribers or fixing the bug in our website.

Tip: Don't panic! When a 'big mistake' happens, set up a 'mission control' task team to deal with the fallout efficiently and effectively.

Step 2: Set up a 5 Whys with your team

Once we've dealt with the fallout, we get all the affected team members together in a room with a whiteboard preferably within one day of the 'big mistake'. It's important that this happens as soon as possible so that the chain of events is still fresh in everyone's memories.

We also choose a team member to facilitate this session. They are responsible for writing all the information on the whiteboard and guiding everyone involved in the 'big mistake' through the events and problem finding. We've found that it works well if the facilitator is not directly involved in the 'big mistake'. This way they are more able to see through the noise and identify underlying issues when the people involved get stuck on the details.

Tip: Ask each affected team member to prep for the session by listing the sequence of events leading up to the 'big mistake' without any judgement.

Step 3: Identify the main 'big mistake'

The first step of the actual 5 Whys meeting is drafting a 'big mistake' statement. This is a one-sentence description of the actual 'big mistake'. Examples of a 'big mistake' statement could include:

  • The marketing team sent an email to all of our newsletter subscribers containing 'FIRST_NAME' instead of the actual name.
  • Our website went down for 5 minutes at 3:13pm on Sunday.
  • Our spend on LinkedIn timed out over the period of 14 December to 17 December 2018.

We've found that drafting good a 'big mistake' statement is really tough because it's hard to identify the biggest problem in what is often a series of mistakes. The 'big mistake' statement needs to accurately describe the specific 'big mistake', rather than symptoms of the 'big mistake'. If it doesn't do this, we run the risk of missing the major system failure. To check if our 'big mistake' statement is useful, we ask:

  • Does it include the specifics of the 'what', 'who' and 'when'?
  • Is it a one-folded problem instead of two-folded problem?
  • Would asking why this happened lead us to the core of the 'big mistake'?

Take a look at these two examples:

A 'bad' 'big mistake' statement: The team spent a lot of time creating a terrible case study.

This is 'bad' because it contains two-folded problem. Is the problem that the team spent a lot of time creating the case study, or that the case study was terrible? If the focus is on time, it is likely that the 5 Whys will lead to misdiagnosing the major problem as a communication issue.

A good 'big mistake' statement: The content and marketing team created a terrible case study.

This is good, because it is a one-folded problem i.e. that the case study was low-quality. It is also clearer which teams were involved in the 'big mistake'.

Tip: You can draft more than one 'big mistake' statement at this point, because you will return to pick the most accurate one later.

Step 4: Put together a sequence of events

After we've reached some consensus on what the 'big mistake' actually was, we gather all the relevant facts. This usually involves drawing a timeline of the events that led up to the 'big mistake' on the whiteboard. It's important to have all these facts, because they will determine the path along which the 'big mistake' is analysed.

To get the facts, we ask about:

  • Sequence: What was the process? Who was involved, where and when?
  • Ownership: Who was going to do what? Were there any gaps?
  • Expectations: What did each stakeholder expect? Was there a misalignment of expectations?
  • Feedback and awareness: How did team members get feedback on their decisions during the process? Did anyone raise any red flags?
  • Social dynamic: What social factors were at play during decision-making? For example: was someone late, absent or tired and so didn't have all the facts or make a key observation?

Once we have all the facts, we revisit the 'big mistake' statement to make sure that it accurately describes the 'big mistake' in a way that we all understand and agree on.

Tip: Remember to take a picture of the timeline on the whiteboard before erasing it, because you'll need it for the 5 Whys write up later.

Step 5: Starting with the main problem, ask 'Why?' five times

Next, we want to get down to the bottom of the 'big mistake' statement. To do this, the facilitator draws the table shown below on the whiteboard, and writes the 'big mistake' statement at the top and again in the top left cell.


To fill in the two left columns, we ask 'Why did…?' followed by the statement in the far left column. We then add 'Because…' to find the cause of the problem in the middle column. This 'Because statement' then becomes the next statement for the 'Why did…?' column.

For example:

Why did…? Because... Solution
The marketing team send an email with 'FIRST_NAME' instead of actual names? [Name] sent out a mail with misconfigured variables. …..
[Name] send out a mail with misconfigured variables? ….. …..

We then repeat this process by asking 'Why?' five times. Each time we ask 'Why?', we reach a more fundamental problem that caused the 'big mistake'. And, despite its name, it's possible to ask 'Why?' more than five times. We typically stop asking 'Why?' when it produces no more useful responses and we can go no further.

Tip: Try to move on quickly from one question to the next, so that you have the full picture before you jump to any conclusions.

Step 6: Identify solutions to each problem

Once we feel we've identified the root cause, we start looking for solutions to each problem. We also assign a team member to each solution who takes responsibility for implementing it. We do this so that we don't run the risk of having tons of great solutions that are never put into practice. Ideally, all affected teams should have at least one solution to action.

Take a look at the table below as an example of solutions:

Why did…? Because... Solution
The marketing team send an email with 'FIRST_NAME' instead of actual names? [Team member name] sent out a mail with misconfigured variables. Don't use incorrect mail merge tags [Team member name]
[Team member name] send out a mail with misconfigured variables? Because none of the testers spotted it and told [team member name] it was broken Make sure that the testers know that the correct names should be in the mail. [Team member name]

Tip: Your solutions should stop the problem from arising again.To do this, focus on improving tools, processes and systems that act as countermeasures rather than quick fixes.

Step 7: Schedule a follow-up check-in

Finally, once we have come up with solutions and assigned a team member to each of these, the facilitator does a 5 Whys write-up using this template. The facilitator also sets up a meeting two weeks later to check-in on solution progress with teams. This is done so that teams are kept accountable and solutions can be scaled across teams if needed.

The 5 Whys write up, of the timeline, problems and solutions, is also shared with other OfferZen teams on a relevant Slack channel. We do this for transparency, but have also found that it can help other teams tackle similar 'big mistake'.

Tip: The two-week check-in doesn't have to be face-to-face but can also happen over Slack, email or video call.

Have you used the 5 Whys before? Let us know how it helped you or your team in the comments below!

Useful resources:

5 Whys downloadable cheat sheet
Downloadable template for a 5 Whys write up

Recent posts

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.