The "five whys" productivity technique

My manager handed it back to me and said "this takes the blame off of you for this mistake and puts it on the testing team. Ask different questions."

So I wrote another one that was 100% focused on me. "Why did this happen? Because the config was wrong." "Why was the config wrong? Because I made a typo." "Why didn't I notice the typo? Because I didn't run the feature after making the change." "Why didn't I try it out? Because the feature is very difficult to invoke or observe." "Why is the feature hard to invoke directly?" "Because <x,y,z>."

What I learned from that is that the problem with Five Whys is that there are many different branches of questions that are worth asking, but that design only allows for exactly one path. Choosing which one is an editorial decision on the part of the author. The outcome of a 5-Whys document is, by its nature, one change. But most of the time, outages at mature tech companies are the result of several different problems coincidentally lining up (if exactly one thing going wrong caused a major problem, that itself is the second problem), and a postmortem process really needs to examine each of the things that went wrong separately.

"Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality."

Does not sound like anything would change. I could chalk up a lot of failures, missed goals or mistakes to this culture of shipping the bare minimum because that's all the time you have. Sometimes it works well, others lead to tech debt that metastasizes because the engineers don't have to use what they built leading to instances like pricing errors that lost significant amounts of money.

Working at Amazon sometimes felt like everyone was gaming the system to hit impossible numbers/deadlines - Goodhart's law at scale.

I find answers like this to be the real downfall of a five whys approach. Is it really true that product managers have "no concern about the code quality"? At best, that seems like a statement that the product managers will not accept, but even worse, it isn't directly actionable.

I'd prefer something like, "Because our teams are not given n days for quality assurance before feature delivery", or "because our estimate of 21 days to deliver was replaced with 14 days without our input".

If it isn't measurable, how can you make the needed changes? "Care more" isn't quantifiable.

You're right, of course. To do causal analysis at all, you have to do it respectfully and well. That's the first step.

When you have the first step down, there are other analysis methods that are not five whys that does this better. One of my favourites is Leveson's causal analysis based on systems theory (CAST).

These dig wider as well as deeper, and offer more interesting questions to ask along the way rather than just "what caused this?"

If you want the 5-whys to not be a joke, you certainly shouldn't be arriving at such strong conclusions without an enormous amount of evidence. There's likely many other explanations.

A serious answer to a "why" question requires enough evidence that it could not be explained in any other way.

If we just want to arrive at strong conclusions that fit in with our priors, so be it, but at least be honest that you don't care about the truth.

Let's take this in a different direction:

> "Why did our code break?" "Because we habitually ship things without thoroughly testing them."

.... or "Because Bob didn't write proper tests for his patch, so the bug it introduced went undetected"

It obviously would suck to be Bob here, but the point is there is no single right answer to any of the whys and each choice along the way will lead us down very different narrative paths.

You can't achieve greater certainly simply by chaining multiple uncertain statements together.

The post in question is a good demonstration of how you can misuse the 5-whys, and it gets well deserved criticism for that. It's obviously not getting anywhere 5 levels deep, so it's asking the wrong questions, and honestly, giving very bad answers that don't lead anywhere: 5-whys require a specific mindset first. Thus, the final "root cause" is very suspect and there's one too many "feel" and "think" in there.

To illustrate, the answer to #2 of "Because I am constantly tempted to check my email, rather than work on important projects." is lacking in substance to answer "why are you getting distracted" (it says the same thing in slightly different words). You can go on-and-on in the same vein. "Because my email notifications pop up and I check them out", "Because when I check my email notifications out, I read the email and now I've lost my context and got immersed into the email topic instead"... That's not helpful at all.

As soon as you get to "I get easily distracted by email", that's already a problem worth solving ("root cause"). And it can have multiple solutions: 1. if you are a blocker for something, move that to an email list of people, a "board" or "forum" discussion; 2. if you are not a blocker, stop notifications and set checkpoints for when you'll read email during the day, and open a side-channel for urgencies if it's ever needed.

If that's not the root cause (it is actually expected of you to be responsive even if you are not a blocker to anything), only then is it worth digging deeper to find problems in the team that make this so.

Of course, I am working with the assumption that being extremely responsive to email is really hurting this person's work (they were not hired to be responsive to emails, eg. as a technical architect to support a development team).

There's a lot of cargo culting around Amazon, but having a strong engineering culture and technical leadership is almost never what companies choose to emulate.

True engineering orgs are quite rare (and will often ship disproportionately compared to their competitors. Just think of pre-merger Boeing for instance).

> I am quite sure that Google/Microsoft/etc do not have this quality in the same degree (or they would not have made many of their obvious mistakes). Not that Amazon doesn't make mistakes; they just make different kinds than a lot of other companies

I'm interested what are the obvious mistakes you are thinking about.

Is comingling inventory among sellers long term thinking?

Could someone elaborate on how that's done?

This is the thing that always gets me when reading things about productivity, how to get more done at work, etc. At first glance, the issue seemed to just be compensation—if you just pay us workers a fair wage we will be happy. But as software engineers we are generally fortunate with high salaries. So, what happens when that compensation comes and you still feel extremely unfulfilled? I don’t think the problem is the depressed workers, it seems like the whole entire system is built to slowly drain the life out of us.

There’s a balancing act between doing things that need to get done and doing things that you want to do. Too much of the former is miserable for you. Too much of the latter is miserable for everybody else.

I’ve had to go to bat for people to work on things that maybe aren’t the absolute most efficient short term use of our resources because working on it will make them either happy or less unhappy. But only rarely can I state it so plainly, so I often wonder what takeaways people are coming to.

Sure, there's a chance that there is no root cause (although, at least in my experience, there usually is a major contributor) or that it's something that's not easy to fix right now, but at least is shows you what issues are brewing below and what you need to put on your roadmap. And, in the best case, you might actually be able to fix a bug higher up the chain directly and resolve future issues.

The appropriate level of abstraction is to find the deepest level at which your choices can have an impact. The purpose of the exercise in general is to make sure we aren't investing energy into solving a problem when that problem may manifest in different ways. To use the article's example, addressing the problem of "I get distracted by emails" is insufficient if the subject will just look for other ways to be responsive, thus reducing productivity. There's a deeper level at which they can impact the chain of events, so we want to discover that.

In your example, there's nothing we could really do about "when God first created Man, He also created Temptation..." or "investors are greedy". But we can impact "investors are only interested in a company scaling at a certain rate", since we can provide feedback about how the current processes impact scaling rates. That would be a good starting point.

> The concept of a "root" cause is silly, because the roots of a plant spread far and wide and have many different ends. In the analogy, if the plant is the "problem", and the root is a "cause", then there are hundreds of different roots (causes) that contribute to the plant (problem). People are always trying to assign a single "root" cause as if there is one. Many causes contribute to systemic failures, and often times fixing any one of the root causes would have delayed the failure for another cycle, without actually addressing the procedural risk. Your technician accidentally skipped a step, sure, but he skipped a step because he was in a rush, and he was in a rush because he was overworked, and he was overworked because of those damn sales targets, and... >If we're interested in "root" causes, then we need to end up with a list of several causes that combine to result in the problem. If we only want a single cause, we should call it a "seed" cause, as defined by "this problem (plant) is guaranteed to happen (grow) every time this cause (seed) occurs (is planted)"

I understand what you're saying here, but I feel like you're focusing on the semantics of the argument rather than on its core message.

Other fields don't immediately critique facts when presented to them. They're asked to update a model before the 12PM call and the get right on it. Five Whys gives them a framework for pausing, thinking, and critiquing their tasks before they set off on them.

I'll note that the engineer's default criticism isn't always positive: sometimes engineers overly-question and end up derailing the actual work. Critique is important, but sometimes executing according to the plan is more important.

(1) The company has either a sales issue or a pitch issue, if reasonable sales targets can't attract investors.

(2) Investors aren't adequately informed on the space and may not be a good fit for the company, if they're only interested in the company if it scales faster.

(3) Alternatively, if investors are short-term greedy, they may be informed on the space but not see a long-term viable path (in which case, silly of them to be investors, but also, analyze why they're long-term bearish).

(4) What other measures could be indicative of success and worth showing to investors, instead of unreasonably high sales projections?

I think it's unknowable, but you have to make a guess.

It's exploration, so you don't know if your time investment will pay off. It's like exploring for natural resources: you may discover a lucrative deposit or you may discover nothing. You can't know without trying.

There's no way to tell in advance whether you should spend more effort looking. There's no formula or rule that can tell you the right amount of searching because that would require information you don't have yet.

> The concept of a "root" cause is silly

The concept of ONE SINGLE root cause is silly, but the lesson of looking for root causes isn't that there's exactly one of them. The lesson is that you shouldn't neglect to look.

Fixing the wrong thing is one type of error you can make. One possible cause of it is not looking at enough things. This error happens often enough that watching out for it is good advice.

1. Create why sessions with key people in the process. Sometimes answers to why are not always apparent. More people contributing can help illuminate

2. If meeting with a group have a facilitator that has done this before.

3. The group needs to have equal say and contribution. No one, including managers and leaders, can overrule or dissuade discource about the answers to why. Everyone's input is equally important.

That said, you're right,maybe there are many sources of the seed coming to the field, and in a 5 why you can recognize that, but target the biggest bang for your buck first.

And in your other example:

> Because the sales targets for the enterprise are unrealistic"

> "Why?"

> "Because the Board of Directors can't attract investors with reasonable sales targets"

> "Why?"

> "Because investors are only interested in a company scaling at a certain rate"

> "Why?"

> "Because investors are greedy"

You're just not asking the correct question.

Yes "the sales targets for the enterprise are unrealistic", but why does that result in the issue that happened?

You would want to come out of it with, even when the sales target are unrealistic, our processes are resiliant to the issue that just occurred. So now ask the Why's that take you to this answer.

Unfortunately, this often means there is no resolution either.

I think that’s the best you can do, but it has problems. One, it becomes a bit of smoke and mirrors for people new to the process. Two, this only works for people who have access and recall of all the near misses and any grumbling in the ranks. Optimists cannot do a 5W justice. Three, I don’t trust any Five Why’s that I’m not present for, because there’s a moment in every RCA meeting where if I don’t judo throw the conversation we end up with some milquetoast bullshit fix that doesn’t fix anything or just makes things worse, and writing code more onerous.

"I feel pressured to do a job that is impossible and it damages my self worth."

Which means GTFO and get a healthier job.

I'm not sure "Why" is the right question to ask all the time. Seems like "If the only tool you have is a hammer, you tend to see every problem as a nail."

In a bigger sense though, the exercise is to force you to take a moment to look beyond band-aid solution, not as an exercise to critique capitalism.

“Why did you make the error?”

Was it a competency issue that training can fix? Resource constraint? Process problem? Do you just suck at your job (I say this in jest, but to highlight that you do want to ask the “why” that explains “why” you made the mistake, and not just stop at “Jacob messed up again”). That’s a broken 5 why process…

A proper root cause might be: “I don’t have enough resources to properly get the job done, and need another developer on the project” or “I’m too time constrained due to overhead meetings to properly perform tests on code”.

I feel the current root cause for why everything is broken is: “Jacob” And you want to stop that immediately.

Now, since going that route I’ve gotten deep into SAFe (Scaled Agile) because I believe that it truly solves so many problems. SAFe recommends using “5 whys” in certain situation and SAFe itself isn’t without valid criticisms either. IMO it’s still by far the best option for a long list of reasons.

Like anything in the wrong hands though, it can be co-opted. Everything revolves around good leadership.

In reality, complex systems are driven by networks of causal effects, where some form reinforcing and balancing feedback loops. There's no start or end to a causal pathway, there's just where we choose to look and what we choose to ignore. There is no root cause, there is a myriad of interlocking factors that together dynamically drive the system in certain directions.

Five whys type analyses tend to end up blaming whatever is convenient or culturally acceptable to blame, and leaves many branches of the causal network underexplored.

Five whys is easy to explain and humans love the narrative point of view promoted by a chain of events, but it's a very inefficient way to explore the causal structure of a system.

Edit: oh, because the link actually has hacker news in the query filter... duh...

On a more constructive note—and I mean this in the best way possible, speaking from experience, not just being a critic for the sake of criticizing—maybe reflect on whether you're "getting distracted" because you're really avoiding the discomfort of not doing marketing because at a more general level you have a tendency to stay in your comfort zone. So work on breaking that habit instead. I know I'm guilty of the very same thing.

* find One Weird Trick to work around your lack of X

* get advice/training from someone who is good at X and do X yourself

* find someone who is good at X and pay them to do X

* decide that even thinking about this problem is painful and go back to doing the stuff you're already good at

In general the first two are gonna cost less money than the third, but will probably cost orders of magnitude more time. The fourth path is obviously not going to change anything but to be quite honest it's mostly the one I take with regards to marketing my own art.

> Why did feature X fail?

Would garner this response:

> Because the universe is deterministic and the fact that this feature would exist and disappoint was determined 13 billion years ago. It really couldn't have gone any other way.

"And of course, being productive means you can spend more time doing things you enjoy: like spending time with family and friends, honing a skill, enjoying a hobby, *or furthering your career.*"

So...be more productive so you can ... be more productive. Nice.

A lot of circular reasons come down to human factors, like juggling three things at once is distracting. Adding on an extra thing doesn’t fix that. Making one or two of the three less distracting doesn’t fix it, but it makes it better, it makes progress, and it establishes precedent for policy changes. It’s an agenda you can hammer on every time something breaks until the problem only happens once in a great while.

It’s the fact that 5 Why’s develop their own epicycles that sticks with management. Of the last five three of them had the same kind of conclusion, I guess we’re spending time on that now.

Nah, any technique that gets people thinking about root cause analysis is worthwhile, but like most lean techniques they require a level of psychological safety in the organization to be effectively used.