The "five whys" productivity technique

https://blog.superhuman.com/five-whys-method/

by alecsandra • 5 years ago

303 162 5 years ago

blog.superhuman.com

maxbaines• 5 years ago

This is a great summary/reminder of a few techniques good to read.

asmos7• 5 years ago

sadly I've always seen this technique used to assign blame

gonzo41• 5 years ago

And, Why do you think that is?

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.

liveoneggs• 5 years ago

Because you single out a person -> ask them for the explanation -> turn the knife four additional times?

allemagne• 5 years ago

Exactly. No methodology can overcome a low enough baseline of trust. Over time, cynicism gets equally distributed and the justification for literally any process or technique becomes vapid corporate kool-aid. You're just left with thinly-disguised attempts to assert power met with toxic resentfulness.

The way I see it, there's a spectrum of trust that goes from one extreme where almost no process works well, and the other extreme where almost any process works well.

So there's the easy discussion of how your technique is supposed to work, and then the hard discussion of how much trust it requires of the people involved.

ivanstojic• 5 years ago

If you’ve never seen the “five whys” technique before, then you are probably unfamiliar with its criticisms as well.

This shows a broad spectrum of proponents and critics of the approach: https://www.google.com/search?q=five+whys+site%3Anews.ycombi...

mgkimsal• 5 years ago

And... the top link I get in google is this hacker news thread...

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

hpoe• 5 years ago

And if you want the non-Google version https://duckduckgo.com/?q=five+whys+site%3Anews.ycombinator....

mynameismon• 5 years ago

Or if you prefer Algolia: https://hn.algolia.com/?q=five+whys

kqr3• 5 years ago

Very brief summary: five whys techniques pretend complex systems are governed by simple chains of events, where each event undisputably causes the next and there's an objective "root cause" that sets the entire chain off.

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.

agentultra• 5 years ago

I like to simplify things and re-purpose an old Twister mat for a game I like to call, "Jump to Conclusions."

"Five Whys," is a variant of this game where you simply roll the dice five times.

If you want to put on a show and dance to let your management and colleagues know you care about quality and are doing something about it, then it's great. If you like false assurances and feeling like you've contributed to a system you cannot fathom or understand it will definitely give you warm tickles. And it makes you sound smart when you put on such an impressive display of initiative and critical thinking.

bee_rider• 5 years ago

It does look more like a random walk through the Why's. Most worthwhile problems have multiple Why's, some of which you can do something about, some which you can't. The examples where Five Why's actually works are ones where the person doing it secretly knows what the problem is, and just picks a path that will terminate on their desired problem, I guess.

But could there still be some value to this sort of exercise? At least it terminates at something. If it is possible to get rid of that convenient or culturally acceptable blame attractor, at least one problem has be exorcised from the organization, right?

spookthesunset• 5 years ago

The other thing with five whys is many times the root cause is beyond your teams control. Unless the entire management chain from the top participates you'll not see the organizational change needed. And even then, upper management might just consider the reasons for the failure as a cost of doing business and won't want to change it.

That being said, the process at least forces the team to look at root causes beyond what is visible on the surface. It's a good start but it isn't perfect either.

smugglerFlynn• 5 years ago

Example presented in the article uses 5 whys for introspective - there is no complex system to analyze, only author’s own reactions. Author already knew deep enough that reading emails is busywork, otherwise answering one of the Whys in that chain would have required research.

What 5 whys helps to do is to structure your existing knowledge. In my experience it is great when you want to analyze your own decisions, or structure team knowledge about particular issue down to a necessary level of detail.

For actual root cause analysis there are better tools, e.g. Ishikawa[1]

1 - https://en.wikipedia.org/wiki/Ishikawa_diagram

imwillofficial• 5 years ago

::reads 5 whys::

::shudders in COE::

Reference: https://wa.aws.amazon.com/wat.concept.coe.en.html

cwilkes• 5 years ago

Link at the bottom is to “the wheel” which I was expecting to be https://en.wikipedia.org/wiki/Breaking_wheel the torture device, instead it is a way to select the weekly component talk.

itsmemattchung• 5 years ago

Loved the five Whys as an ex-Amazonian but could easily see how the framework can snowball into a blame game.

padastra• 5 years ago

Unfortunately, there's many corporate environments where technical staff are managed by non-technical staff. This comment isn't debating the merits of that, but when the manager (or especially their manager) doesn't really intuitively understand the difficulty of your work or how much you've accomplished, they measure by other things like "responsiveness".

This is similar to how patients will rate doctors (lawyers, auto-mechanics, electricians) higher by things like waiting room design, ability to make small-talk, willingness to give antibiotics, etc. which are important but actually do not correlate with better care.

So I've found that optimizing for "responsiveness" is important in and of itself, and much easier than the alternative of "let me make sure non-technical senior management person X spends the time to understand my contributions at a deeper level".

brightball• 5 years ago

Yep. Stuff like this is the reason that I moved from the technical side into management about 4 years ago. Seeing the dangers to my team from managers who don’t understand the challenges and constraints became a situation that I couldn’t take anymore.

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.

Techbrunch• 5 years ago

How to solve why the server crashed using the 5 Whys: https://vooza.com/videos/the-5-whys/

indymike• 5 years ago

Five Whys is just a tool. It really only works if it is used as a tool for finding truth and improving process. It is really dangerous in the hands of people who wish to use a process failure for political gain.

Puts• 5 years ago

I think the most helpful thing with five whys is that it counter acts blame-games within an organisation. Normally when something happens the natural reaction is to blame someone that did something which is counterproductive, it feels good for everybody else but it doesn’t change anything. But five whys is just a method, for it to work there needs to be a true will to actually change and improve things.

hinkley4• 5 years ago

Counteracting blame game comes down to being careful not to ever use certain phrasing common to the enemy. We just had one I threatened to cancel because one of the lead developers was asking how a decision happened and using The Tone.

It’s not a matter of whose hands the hammer is in. Nobody gets to use it at all or everyone will.

mrweasel• 5 years ago

Agreed. In constructive environment with high levels of trust you can often take a shortcut and simply ask: What problem are we actually trying to solve?

BatteryMountain• 5 years ago

Was about to say. Plenty of the examples in this topic seems to want to use it to assign blame and to find the ultimate culprit.. that is not the point. You most likely already know who/what the culprit is, so the 5 why's should be an introspective tool to figure out any unforeseen side effects.

sokoloff• 5 years ago

We would frequently (half-) joke that “the fourth why is ‘because we were lazy’”

quacked• 5 years ago

I've never understood where to stop a root cause analysis, and the "Five Whys" has never helped at all. What's the appropriate level of abstraction? Eventually you get down to:

...

"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"

"Why?"

"Because when God first created Man, He also created Temptation..."

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)".

lowkey_• 5 years ago

That line of thinking is actually really valuable, here's some insights:

(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?

sanedigital• 5 years ago

I think the reason Five Whys seems silly to a lot of engineers (or engineer-minded types) is because we naturally progress through the first few whys on our own. Our entire work is basically: "That didn't work—why? Because this function didn't get called—why? Because this if-else branch went the wrong way—why?"

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.

Sebb767• 5 years ago

I think you're taking the 5 whys to literally. The plan is not to ask why five times and replace the issue text with the fifth answer, but to take a moment to inspect what actually caused the issue instead of directly trying to fix the symptoms.

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.

sh1mmer• 5 years ago

When we used 5Ys at Uber SRE I always like to say that you are looking for a tree of depth 5 but if it's width 1 you've not tried hard enough. "Root cause" or at least the idea there was a single factor that was the defining feature of an issue is hardly ever true.

There is quite often one symptom that is pivotal and cause a critically failure, but generally that symptom itself is a result of multiple inputs.

I'd simply say 5Ys should be a rule of thumb to get folks to be sufficiently inquisitive to keep asking follow-up questions about whatever they are investigating until they've hit around 5 questions per area.

maximedupre• 5 years ago

Yep, I'm on the same boat. I just don't see any resolution that I haven't really thought of by doing this exercise.

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."

ysavir• 5 years ago

What's the appropriate level of abstraction?

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.

tailspin2019• 5 years ago

The appropriate level of abstraction is to find the deepest level at which your choices can have an impact.

This is a brilliant insight and immediately gave me an “aha” moment on how best to use the 5 Whys approach!

SavantIdiot2• 5 years ago

...or this:

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

Which means GTFO and get a healthier job.

larrydag• 5 years ago

A couple of ways to improve the 5 Why process that I've seen done in the manufacturing world.

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.

sidewndr46• 5 years ago

I essentially stop going down a level when I get to somewhere I can't really control. For example, I'd probably stop at your realization that "investors are only interested in a company scaling at a certain rate". I can't make even narrow changes to investment mentality, so there is no way I'll make such a broad one.

Unfortunately, this often means there is no resolution either.

adrianmonk• 5 years ago

What's the appropriate level of abstraction?

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.

mindtricks• 5 years ago

Instead of root cause analysis as blame laying, look at this as more of an identification of diagnostically important reasons. The above example doesn't help anyone. If code was late, would you accept "our developer is incompetent" as a root cause? Of course not. It's possible that they are, but it's also possible that requirements were not clear or that they took toe long to clarify, which led to a reduced amount of time to do actual development.

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.

hinkley4• 5 years ago

At three Why’s the branching factor is down low enough that a quick person can guess what many of them are and compare them with the lunch conversation and water cooler gripes and the capabilities of the team and steer toward something - anything - that is actionable and will materially reduce the class of problem - not just the same problem, but ones with any similarity.

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.

didibus2• 5 years ago

You just did a 5 why lol. Interestingly enough, for the plant it took you a while to arrive at the fact that the seed is the true cause of all those plants growing where you don't want them. Next you'd ask why there were those seeds in the field in the first place, and you might realize they're being blown from some other field by the wind. Now you know what to address.

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.

jacobyoder3• 5 years ago

i'm currently the only developer on a project. i now have ... 3-5 'managers' (depending on how you count) involved in planning/direction. PM on "my" side, PM on "client's" side, PO on "client's side", and... some other 'higher ups' on each side that drop in now and then.

Recently, they've instituted formal RCA process with "5 whys" and... every 'why' ultimately ends up being my fault. Now... they're not saying 'fault' directly, but no matter how you cut it, I forgot to add another test, or I didn't document something clearly enough, or I forgot some error checking, or... I forgot to remind someone of something or... whatever.

"Oh, don't take it personally! It's not just you, we're a team". But.. I'm the only one doing the work that is breaking, and I'm the only one fixing it, and every documented RCA lives on, pointing out that I made mistakes, and each document is delivered to 12 stakeholders every time there's a mistake, and mine is the only name on it attached to the 'root cause'.

"What lessons can we learn from this?" That we can't sustain this pace, and adding more managers is not helping the situation in any way.

I've been saying for a while we're formalizing way too much stuff, and that most of the practices they're bringing in from other places all had the baseline of "more developers than managers" in a team environment. I'm a team of one, and processes designed for teams of 3-5-10 aren't appropriate, imo.

laumars• 5 years ago

I think your closing statement is very apt. Your points about tests et al works when there is a larger team so instead of accusing individuals for errors you’re blaming the process. But I can see that process blaming feeling a little more personal when there’s only one person writing the processes.

jacobyoder3• 5 years ago

Yes. As more management layers/people are added, people are all wanting to be "more professional", and seeing "oh, we did formal written RCAs on production events at my last company, we need to do that here".

I did a 6 month gig at a company a few years ago. Team of... 6-8, with a dedicated PM and a good team lead. Company was around ... 80 or so at the time, and there were a couple other 'dev' teams (I think around 35-40 'dev' folks at all - it was growing so hard to pinpoint numbers).

I saw some of these types of processes there - I didn't always agree with 100% of everything done, but there was a team. 1 lead, one PO/PM, and... 5-6 devs and a couple testers - a self-contained unit. It worked pretty well, all things considered.

I'm currently in a situation where it's completely backwards, but they're trying to implement all the 'correct' and 'professional' techniques. Oh, and I'm part time - ~20 hrs per week. Pretty much everyone is part time, either overall, or part time on this project, and... the wrongness of trying to bring in techniques built for full time larger teams seems to be lost on everyone but me.

mlac2• 5 years ago

You’re not taking the why far enough… You need one more “why” about “why” you made the mistake:

“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.

jacobyoder3• 5 years ago

I've gone further in some of these, but sometimes it gets to "there's not enough time or people to do X".

There's been some cases where "I missed X - there's not enough time to check everything and I missed X". "Well, you should have told us X wasn't checked" or "you should have raised the alarm before". I've been raising it for ... 5-6 months. And the whole point of "I missed something" was... it's a mistake/oversight, not "I intentionally didn't check X".

There are rumors of other developers being interviewed, but no one has come on board. Assuming someone does, I suspect the thinking will be "let's double the previous workload - we have 2 people now".

I'm understanding of the situation, to some degree. Pretty much everyone on the project is 'overworked' in some sense, but they've been hiring and doubling up other positions, just not this one. I've been keeping this pace for 18 months. I scheduled one day off - 2 weeks in advance - because I had to drive someplace. That morning, someone noticed a financial bug that was preventing everything from working. 2 hrs later, from my hotel, I had to connect in and review and fix stuff. It was totally my fault - I missed stuff - but there's just... no getting away from it.

Adding in '5 whys' and other formal review processes on top of this situation borders on insulting.

IAmGraydon• 5 years ago

The five whys also works well on people who hold irrational beliefs. Ask them why they believe what they do a few times and they will often eventually end up at a dead end or an obvious logical fallacy. It may not immediately change their mind, but it will make them question their beliefs, which is a first step.

sjostrom7• 5 years ago

Exactly. If someone's in the meeting in genuinely bad faith, 5-whys isn't going to improve their attitude. But it can help re-frame things for folks that just hadn't taken the time to consider other viewpoints.

criddell• 5 years ago

I think I know some people where this question:

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.

throwaway4132• 5 years ago

I am a fan of linear, critical, singular lists of 5 whys.

I am not a fan of the matrix of whys that some companies have decided to begin implementing because of 1 blog post high up on Google searches that suggests to use matrices to organize multiple root causes.

They don’t need to be combined. I would rather see multiple RCAs each with a singular concrete cause, than a single RCA with a 5x5 matrix of intermingling causes. It makes it harder to address and dig through each issue accurately in context - you’re always reconciling the causes against each other to form a cohesive story, when there’s actually a good chance that there were separate, unrelated causes to your incident.

stevebmark3• 5 years ago

We should stop using the Five Whys for root cause analysis, for this and especially for post mortems. The reasons are obvious. A “root cause” will almost never be exactly 5 whys down, there will almost never be only one root cause, and the reasons are a cyclic graph, not a line. The five whys are also random. They change based on on who does them and which why you randomly start on. If it feels like an awkward and difficult root cause analysis tool, that’s because it is.

hinkley4• 5 years ago

That’s why it comes down to who is steering the conversation. And someone is even if it looks like nobody is.

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.

allenu• 5 years ago

I really like the five whys to get to the truth of what went wrong, but unfortunately, in practice you only take the whys so far.

For instance, where I work, if we have a large enough on-call issue, we have an RCA to figure out what went wrong. We use the five whys there to figure out what we could’ve done better. However, we usually only really go as far as the engineer’s actions that caused the issue. We usually don’t ask, why did the engineer choose to act in that manner instead of the correct one? Usually the takeaway is “We need a process to make sure engineer does right thing” and not “We need to make sure engineers don’t have too much work so that they have time and space to do the right thing.” I find it’s usually the latter is a better course of action but it’s hard to make those statements or requests, or if you do make those requests, management isn’t as open to taking action.

ajkjk16• 5 years ago

As someone who used 5-whys when I worked at Amazon, I love it and the criticisms here don't resonate. It's not about finding one path of causation, or finding everything you can point a finger out. It's about being willing to admit the actual causes and then do something about them.

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

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

... which, and this is key, has to be followed by managers at all relevant levels changing their processes to fix this. If it's not fixed -- at an organizational level -- as a result of the analysis, fuck off with the 5 whys process, it's just a joke.

I tried to run an Amazon-style 5-whys at my new job and my boss said, oh that was very good, good analysis. Then we did none of the things suggested. Well, there's no point. Just quit. You're going to be mediocre forever until the management chain buys in.

The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.

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. And of course plenty of departments at Amazon don't do this well either; it's too big a company to be culturally uniform. But at least the norm is to do it well instead of badly, which is more than you can say about most larger-than-startup-sized companies.

kqr3• 5 years ago

As someone who used 5-whys when I worked at Amazon, I love it and the criticisms here don't resonate. It's not about finding one path of causation, or finding everything you can point a finger out. It's about being willing to admit the actual causes and then do something about them.

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?"

ajkjk16• 5 years ago

imo, the question "Why?" is really supposed to be more like "How could this have happened!??". It really makes a lot more sense that way.

[edit: to respond to the dead comment about what else "Why" could mean, the difference is the emotional valence. It's not asking the _factual_ question of how it happened; it's applying the appropriate outrage and embarrassment to the fact that it happened. "My god, we messed up! How can we ensure it never happens again, with urgency?".]

digikata• 5 years ago

While there are other techniques, one thing to think about is how often the analysis/review group is that particular group. In large organizations, if they particular issue being analyzed is with a group that hasn't gotten together before, a more accessible technique like five whys could be easier to use and mediate. If the group regularly gets together to do such analysis, or has a longer range time frame to complete the analysis, more involved techniques could get to deeper work.

adamsmark• 5 years ago

I worked at Amazon too. This outcome of a 5 why,

"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.

shepherdjerred• 5 years ago

Hah. I cannot count the number of times we made action items as a result of five COEs and the ultimate result was a SIM issue permanently sitting in our queue because there was always something more important to do.

ajkjk16• 5 years ago

It worked pretty well in my org (fulfillment/supply-chain) but maybe I just got lucky. As you might imagine that org was pretty functional, being the backbone of the retail business.

stevebmark3• 5 years ago

To me your message embodies the criticism of the five whys. You don't run a five whys analysis because it's not effective. You run a more open ended root cause analysis with the goal of understanding issues, which is effective.

ajkjk16• 5 years ago

I believe that what I'm talking about is what "five whys" _actually_ is, and what a lot of the critics think "five whys" is, which they are rightfully criticizing, is just not a thing at all -- it would be trivially useless and ineffective, and obviously is so to anyone who does it.

In particular 'five whys' when run correctly has neither a set number of whys, nor a particular linear structure, nor a fixation on assigning blame, and involves actually taking actions in response to the root causes, not just creating meaningless action items. If those don't apply, you're not doing five whys, you're doing some bizarre aberration of it.

_ea1k• 5 years ago

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

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.

passivate3• 5 years ago

Indeed, the five Why's is just one of the starting points for introspection. Each person/team/department/org needs to find ways to generate consensus and actionable items out of that exercise. Reactionary phrases like "because x sucks" aren't very useful.

RealityVoid2• 5 years ago

At that point, it's not actionable either, it's just blame shifting.

ajkjk16• 5 years ago

I disagree so strongly with this. There's a pervasive fallacy in the industry that things that aren't quantifiable, or are hard to quantify, can't be real or true. It's just wrong: they can be very true, and often such things are deeply true but whole organizations are ignoring them because they haven't found a convenient way to shoehorn them into their KPIs / OKR framework / whatever.

Yes, it is often the case that product managers have no concern about the code quality. No, the problem is not that N days aren't given for QA. If the product managers talk to the engineers, they will get a sense of the problem. If they work as colleagues they will be in this sort of discussion all the time. When a product is implemented, they'll keep talking, and they'll be aware that the major corners are being cut, and they'll understand that that puts it at risk. Then they can make better decisions to avoid this.

If they have that information and still make the wrong decisions, then they have perverse incentivizes or are behaving maliciously to the business.

And if they try to reduce the intuition and professional opinions of their engineering team to some numbers -- estimates, QA lead times, bug counts -- which are pitched over the wall, badly summarizing actual expertise -- then they will fail, badly, over time, because that is a nonsensical way to work.

Good decision-making and leadership, imo, don't need you to have found ways to quantify things, and your time is often better spent doing good work than waiting for things to be put into numbers. Quantification helps, sometimes.

"If it isn't measurable, how can you make the needed changes? " Doesn't that question sound absurd? You make the needed changes! What does measurability have to do with it?

muzani• 5 years ago

It sounds like "Because our teams are not given n days for quality assurance before feature delivery" is just a further Why down. I can see how this becomes a loop if someone isn't trying to get a real answer though.

inopinatus• 5 years ago

If you believe a values problem isn't actionable, you're not thinking for the long term.

It's the foundation of strategy.

8note3• 5 years ago

"we don't have a method to prioritize code quality"

CobrastanJorji• 5 years ago

I did a Five Whys for Amazon once. It had been an embarrassing incident for the team. We had put a huge new feature together over a few months, and when we turned it on...nothing happened. The whole feature had been entirely disabled by a typo I made in a configuration change. At the time, we had a test team that was tremendously overworked and tested things almost entirely manually. They asked for a couple extra weeks to test our new feature but eventually greenlit it. My Five Whys basically asked "how did this get to production if it didn't do anything?"

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.

RealityVoid2• 5 years ago

I has a similar experience where I had to 5 why a issue and... the gist of it was that the why was because I bungled it up. I just.. saw it as an issue while I wrote my stuff, added a TODO and then... just never did it. So then, after the first 2 why's I could only answer in the back of my head, "Because I'm fucking stupid, that's why!"

I get the idea with the why's but sometimes, it's just that simple, you can't really go deeper than that. I fucked up.

ajkjk16• 5 years ago

Yeah, I don't think blaming the typo is the right outcome for this. The right outcome would be identifying where your testing / review / launch / validation process failed. Evidently it failed, or nothing would have gone wrong even when you made a typo.

Usually the response to a good root-cause investigation isn't "I'll try to avoid making mistakes" (although sometimes it's just a mistake and no changes is required). The outcome should be a new rule or practice for the organization, some kind of decision that determines how things will be done going forward to make the error less likely. This almost always requires a leader at some level declaring by fiat that things will be done this way going forward; if your managers aren't doing that, they're not 'leading' at all.

didibus2• 5 years ago

I don't think that's an issue per-say. You can't fix everything, but you can at least try to find the most likely path and do something about it. Even if it wasn't the biggest cause, you made progress towards improving some of the variables at play for the issue.

There's clearly something to learn and improve in your 5 why's. There was a hard to test feature, typos were allowed to pass through validation in the config, there was only one person making the config change and seemingly no one to review the change, etc.

Ok so all these seem like they'd contribute at least somewhat to why this issue occurred. Sure there might have been other deficiencies, like why didn't the test teams also forgot to test the feature or thought they did but didn't, etc. But you can't address everything.

So maybe you update the validation code for the config so it is more likely to catch such typo in the future. Maybe you make improvements to your config change management and enforce a 2-eye rule on config changes, and a 2 person review on the change. Maybe you make improvements to your testing capabilities so that such hard to trigger features become easier to write an automated test for. Maybe the leadership learns to inssist on planning more time for dev QA and writing tests when launching the next big feature, etc.

throwaway9843932• 5 years ago

Toyota's implementation of Five Why's actually doesn't stick to just one path, they can branch out or do multiple of them. But you're right about multiple causes and the need for alternative strategies to find and fix causes.

The problem with process is that most people follow it as prescribed rather than following the spirit of it.

kevinsundar2• 5 years ago

This is not accurate. Im currently working on a "5 Whys". I am writing it in a nested bullet format which allows multiple branches. Example:

  * Main Why?
   * Why 1?
    * Sub Why 1?
     * More Whys
   * Why 2?
    * Sub Why 2?

Its totally fine to have more than one change or path. Theres nothing in the nature of the doc that requires one change or one path, thats just an assumption.

freetinker3• 5 years ago

A better way of doing this would be the Ishikawa diagram.

https://en.wikipedia.org/wiki/Ishikawa_diagram

908B64B1972• 5 years ago

"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>."

Now that's engineering.

Code or any feature that's hard to get in isolation and test is prone to fail in unexpected ways. And if the failure in prod is big enough that gives you the opportunity to show that it's cheaper to invest engineering time to make this part of the product better instead of picking up the pieces later on.

necovek3• 5 years ago

Like any tool, it can easily be misused.

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).

beebmam• 5 years ago

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

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.

bumby2• 5 years ago

When the 5 whys technique is used for actual process improvement, data collection is part of the process to measure improvement of refute a claim. The next steps usually test multiple theories (sometimes concurrently).

aflag2• 5 years ago

Why did you leave Amazon?

ajkjk16• 5 years ago

I was 25 and it felt like a weird thing to be doing in my 20s when other people were traveling the world.

snthd• 5 years ago

management is incentivized to care about things other than shipping/deliverables/this quarter's returns.

Could someone elaborate on how that's done?

ajkjk16• 5 years ago

Management has to be rewarded by _their_ management for delivering on abstract improvements that make things less bad without necessarily pegging them to metrics and returns. Their management has to be rewarded by the managers above them, etc, all the way up to.. somebody. Ideally the CEO because the board ain't gonna do it. Bezos was great at this: it was always clear that fixing your shit was the first priority, because the C-suite understood that for a company that large to scale its labor, teams have to not be blocking / causing friction for each other. Hence being very forward-thinking about abstracting everything out into service-oriented architecture. (although it took like two decades to actually get there completely. My org, fulfillment, was one of the last to do it, and only finished after I left.)

timoth3y• 5 years ago

The Five Whys are a great as a tool for personal introspection, but in business it seems to become an exercise in chaotic story telling, with the final "answer" highly dependent on the initial assumptions.

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.

908B64B1972• 5 years ago

Then we did none of the things suggested. Well, there's no point. Just quit. You're going to be mediocre forever until the management chain buys in. The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.

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.

paulryanrogers• 5 years ago

The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.

Is comingling inventory among sellers long term thinking?

ajkjk16• 5 years ago

I actually worked on that project, and yes, it is. It was a good idea whose implications were not fully understood -- but Amazon will eventually get it right and it will stop causing problems, because they have a good 'make mistakes and fix things' loop. (I think this has already started happening but this moves very slowly.)

The main reason for commingling inventory is to be able to ship a product from the closest warehouse if it's the same as something in another warehouse (if you order it on the east coast and the nearest Amazon-owned inventory is on the west coast but an FBA seller has it on the east coast, ideally you could fulfill the order from the east coast).

The problem is, nobody anticipated the degree to which sellers began cheating this system when they figured it out. I don't think Amazon was ready to fully moderate the whole system against exploitation. They are no doubt working on it but it's a huge battle.

SavantIdiot2• 5 years ago

"5 whys" is more direct, but the goal of psychotherapy is to lead you to the root cause by practiced, skillful questioning. The goal is to cut through narratives we create to obscure the emotion. I use emotion intentionally: notice the very last why in this article is a feeling of shame.

ajkjk16• 5 years ago

All of my personal 5 whys like the one in the article end the same way.

"I'm always busy but I don't feel productive with my time"

Why? "Because I get distracted by email, refactoring, slack, .."

Why? "Because I don't really want to be doing any of this, but I feel like I should be at my computer trying to force myself to do it."

Why? "Because I have a job and therefore some responsibilities, and I wasted a lot of time last week so I guess I need to get things done this week"

Why? "Because I'm sitting at a computer at home, surrounded by nobody, writing code for projects I don't really believe in, that are being mismanaged outside of my control, and what rewards there are (salary) are totally decoupled from the work, and I have lots of money saved up from doing this anyway but the modern world makes no sense and there's nothing I really want to be doing so I guess I'm working."

... ah, you say, you can't work because you're burnt-out and depressed. Yeah, probably. But I mention this to make the point that: if you can't focus, perhaps you just _don't want to be doing whatever you're doing_. It is sometimes hard to admit that in this modern world where you're supposed to be a hard-working adult. But you don't .. have.. to be employed, or working a 9-5, and for many people it's deeply unnatural, I think, to be doing this your whole life day-in and day-out.

Related, this article about writer's block that was posted on HN a few weeks ago: https://sashachapin.substack.com/p/if-you-have-writers-block...

np-• 5 years ago

if you can't focus, perhaps you just _don't want to be doing whatever you're doing_

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.

ajkjk16• 5 years ago

I was talking to a coworker who said to me -- what do you think about asking for bonuses like my friend at FB gets, to get us to do more work? I said: I'm paid more than I know what to do with already. It's not a problem of money, it's a problem of managers who aren't leaders, and lack the ability to inspire anybody to do anything. It's no surprise we don't get much work done if nobody is inspired or proud of what they're doing.

She had apparently never thought of this, but agreed. I guess a lot of people think it's about the money and then wonder why they can't get much done. imo the money determines who works where, but has almost nothing to do with the amount of work that gets done.

... so yeah, I agree.

brainzap• 5 years ago

time is life

hinkley4• 5 years ago

perhaps you just _don't want to be doing whatever you're doing_

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.

tuan• 5 years ago

is this just a fancy name for debugging process that SWE do everyday, no ? It's basically walking up a call stack until you find the bug.

bootstrapsite• 5 years ago

I'm an indie hacker and kind of struggling with making any money with this new path I've taken, so I tried this technique:

[ ] I'm not making money

[ ] Why

[ ] Because i keep getting distracted doing new things instead of marketing

[ ] Why

[ ] Because marketing isn't as much fun as writing new code

[ ] Why

[ ] Because I'm a programmer not a marketer

[ ] Why

[ ] Because i love being left alone and avoid pitching to other people

[ ] Why

[ ] Because I'm just an introvert and sales and marketing feel like shilling and spamming

[ ] Why

[ ] Because i am not a businessman and i just suck sales tbh

I guess I can see my problem but really don't know what to do about it. So I just do it anyway until I develop more confidence and get good at it? Is that it?

Anybody got any advice for me?

airstrike• 5 years ago

Since you asked for advice, here's some that's free... Maybe partner with people who are good at what you are not?

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.

xmprt• 5 years ago

Have you tried hiring someone to do marketing for you? Or finding a cofounder? If you're not willing to try those then perhaps you care more about the building part than the making money part and are worried that making money will put unneeded stress and support load on your back when you'd instead like to be building.

egypturnash• 5 years ago

IMHO there are several paths to take once you have brought a problem down to "I am not good at [skill X]":

* 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.

hkon• 5 years ago

Having played this game a few times, I have noticed that it is a very effective tool for shifting the blame onto people not participating.

joemaller1• 5 years ago

There are seven trees.

5tefan• 5 years ago

Enough of literature around to learn and train critical thinking. That would be worthwhile and gets the job done in the end.

TheOtherHobbes• 5 years ago

This works up to a point. Unless the problems are political and can't be fixed at the level at which the questioner is operating.

Then it becomes an exercise in "Because there are things I can do nothing about without leaving and/or starting a revolution."

This is not an answer most people want.

EForEndeavour• 5 years ago

On the other hand, stepping through a systematic process invented by Toyota and arriving at the answer "the root cause(s) are beyond our direct control" is a plausible way to (1) not waste time on futile ideas, and (2) get managers off your back.

flerchin• 5 years ago

It's such a childish game. You just choose the problem you want to solve, and work it back from the whys and start at the beginning.

When I worked SAFe, I was able to point every single outage at the SAFe baloney using this technique. They stopped making us use SAFe.

PeterWhittaker• 5 years ago

They lost me at "We all strive to be more productive".

Do we? It seems to me that many of us reach a point in our careers when we can maintain a high level of productivity (defined using whatever personal metric we choose (personal metric chosen over any external metric on the basis of our being seasoned professionals who can manage our own work)) for a long period. Sometimes at our cost.

Productivity isn't my issue. Stepping away often is. It's far too easy to devote most of a week of long days to fixing bugs and adding features and tell one's self that a few hours of downtime Friday and Saturday will be enough to spend part of Sunday working on the critical customer demo Monday.

Which went very well, thanks for asking! But how well it went isn't the point. My level of fatigue is the point.

Instead of 5 why's, I offer why nots: Why not step back and take the extra day? Why not give yourself permission to rest (at least a bit) more so that you can sustain this level of quality and quantity for longer?

Why not indeed....

passivate3• 5 years ago

If your productivity declines, you can use the five Why's and come to the conclusion that you need more rest. I don't see what your "why not" methodology is adding here.

duderific• 5 years ago

The one I loved was this:

"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.

dsizzle• 5 years ago

Is there some significance to the number five? I assume that's just a rule of thumb of where the true root arises, but no one seems to be questioning this seemingly arbitrary number.

mym1990• 5 years ago

I think this is typically the number where one comes to the actual root/s of a problem. If you get there in 3, I don't think anyone would decree it as a violation of the technique.

pkdpic• 5 years ago

This is fantastic and obviously not what I expected at all. Im totally going to file this under 'wisdom to remember for the rest of my life' thanks for posting!

stakkur• 5 years ago

A quicker explanation, with some background of the technique and criticisms: https://en.wikipedia.org/wiki/Five_whys

Personally, despite the popularity of this technique in the Lean/Agile crowd, I've never found it useful for meaningful problems.

tyingq• 5 years ago

1 - Why do we think there's a trivial shortcut to analyzing problems?

2 - ...

zemvpferreira• 5 years ago

Another phenomenal manufacturing technique bastardised and ruined by mediocre software consultants.

It's a practical tool, not psychotherapy for engineers. You're not supposed to go namby-pamby hands-in-the-air "it's the culture!" after asking why five times. You are supposed to figure some automation to implement, some tool to build that will help fix a recurring problem for good.

Example:

Manager: Power costs at the plastics plant are way too high!

Engineer 1: Why are we using all that power?

Engineer 2: I figured out we have this press that eats a bunch of electricity all the time.

Engineer 1: Why's that one press so power-hungry?

Engineer 2: It needs to be operated at a super high temperature so it uses all that power to keep warm.

Engineer 1: Why's it wasting power to keep warm? Can't it keep temperature?

Engineer 2: The thing's out in the open and the building is air conditioned, so there's constant heat transfer to the environment. And I found an A/C vent pointed directly at it.

Manager: So we're wasting power on heat and cold! Good Lord! Can't we build a box around that press?

Engineer 1: Good point, George thought of that a while ago but no one's gotten to it I guess.

Manager (to now promoted Joint Chiefs of Ass-Kicking Question Making): Great! Get to it!

It's not rocket science. Everyone knows things stink and you can't get anything done at this stupid place etc etc. You either keep busy tending to the garden or you move on.

EDIT: To answer some other comments the original Toyota technique even included ways to explore multiple causes and other such complexities 50 years ago. It's ironic that lean software gurus can't even copy/paste properly. I would hope they read more books before writing their next one.

freetinker3• 5 years ago

Thank you for this comment. As a manufacturing engineer, I really appreciate it.

manmal• 5 years ago

This looks like a useful implementation of the Socratic Method [1] of asking „Why?“ until you get to the bottom of things.

1: https://en.m.wikipedia.org/wiki/Socratic_method

ahdh8f4hf4h8• 5 years ago

I think most of these techniques come down to the relationship between the management and employees. If everyone is honestly trying to solve the problem and earnestly listening to feedback from people above and below, than almost every troubleshooting process works. If the goal is to point blame to another team, then every process will fail.

rajacombinator• 5 years ago

Five whys is a good technique if you are in a position to truly apply it. Most people are heavily incentivized not to ask the right questions. So it can become yet another kabuki process quite easily.

sam1r• 5 years ago

Great article - does anyone here use superhuman? Curious about thoughts and usage. I am still somehow on the waitlist for the beta, unfortunately.

carapace• 5 years ago

A very similar algorithm is the foundation for a certain very powerful psychological/spiritual technique called "Core Transformation"[1]. You start with a particular problem or issue that you want to work with and work your way up the chain of intentions recursively to reach a "core state" which then transforms the original issue.

It turns out that, seen through the lens of this process, human motivations form a kind of skein or lattice structure, which terminates (or originates) with a small set of "core states" that are transcendent: bliss, love, oneness, okayness, happiness.

The states are transcendent in the sense that they depend on nothing and are universally available at all times and in all places and conditions. They are intrinsically satisfying, and all actions and behaviors are ultimately aimed at restoring the presence of these states.

It follows that the vast majority of human activity is, in fact, yak shaving! Human history is the story of a massive, intricate indirection through layers of abstraction to attain goals that are already available.

[1] https://www.coretransformation.org/

akuma73• 5 years ago

Because of the initial conditions of the universe and the laws of physics. That's as deep as we can go right now.

trhway• 5 years ago

Why the "five whys" is just another cargo cult like Scrum/Agile/Lean/Six Sigma/etc. ?

soheil• 5 years ago

A lot of these type of tricks try to reduce a problem that is not reducible, at least not in a general way. This sounds great when read to oneself, but the moment you actually think about it for more than a second you realize the bullshit that this type of advice really is.

Namely, there is never only one reason why something is the case at each of the 5 steps. It's usually a linear combination of various causes with different weights. Furthermore the reasons are not definitive, sometimes at best you can assign a vague probability to each. And finally there are unknown unknowns, the inexplicable. You may only have an intuition about something, but cannot put it into words. Remember often times intuition can be spot on and identify things that your conscious mind may not have access to.

hizxy• 5 years ago

I just can’t imagine doing this in a real conversation.

nrvn• 5 years ago

What this technique is missing is how to get yourself out of the trap of self-delusion. It is easy to lie to yourself when answering any of the why questions because our brains will more likely choose a comfortable answer instead of the right one. Instead of getting to the root cause one can easily get to the trap.

I believe the actual technique should be like “break 5 layers of your confidence in a given problem and _question_ everything about it until you build the whole picture”.

In other words instead of asking why 5 times question everything and unwind the knot until you have a straight thread. Sometimes it is not just 5 layers deep.

And one should be brave enough to put their own beliefs and experience under doubt and reassess them from the ground up.

That’s the path that leads to some really interesting questions about yourself, the world around, about other people. That’s what ignites the thought process.

5 whys is an oversimplification of the actual reasoning process. And as with other ideas that get wrapped up in a fancy proverbial form it can be misleading and turns to a cargo cult.

Start with “why should I trust the 5 whys? Will it really lead me to right answers? How? What if the answer is no?”

The "five whys" productivity technique

Related Stories