“Ask 'why' five times about every matter” | Hacker News Reader

“Ask 'why' five times about every matter”

toyota-global.com

I don't force it 5x but asking why was the best lesson I learnt working with users/clients as people tend to talk about solutions and not the problems. That's also where my nickname comes from.

Yes, this!

As someone who likes to fundamentally understand processes and underlying reasons. It does take some practise though to get at the heart of the matter and propose alternative solutions that work without being abrupt or like "c'mon, etc?". People higher up tend to be rather attached to their solutions even though after chatting for a bit it becomes increasingly obvious a different approach would get them what they want and often reduce human error factors and/or make effeicent :)

I'm figuring this out slowly, getting "it" though.

> people tend to talk about solutions and not the problems

Hard to make this any clearer. To expand a bit on this, most of the times the solutions they talk about are of course expressed in terms of what they already know, which makes communication that much harder. It's a key aspect to keep in mind, and one that ideally both parties, but at least the one that's taking the job, needs to be aware of.

Otherwise it's like visiting a physician and telling them the diagnosis instead of the symptoms.

On the other hand, it's frustrating to call up the ISP help line to get a bad router replaced and get treated like a troglodyte.

Likewise, I'm probably qualified to diagnose when my laceration needs stitches. A conversation about problems and not solutions are frustrating at that point.

Which is what makes this comic so powerful: https://xkcd.com/806/

The people asking the questions are trying to defend against false confidence, but drive the people with justified confidence crazy. Being able to filter for "I know you're competent, we can skip ahead a bit" is really powerful.

I usually ask, "What problem are you trying to solve?", to anyone who brings me a solution instead of a problem, but it comes down to the same thing. I guess I don't even really know which question would be more efficient at getting the real answer.

The problem they think they need to solve is usually not the problem that needs to be solved. Hence the 5X (or more) to reveal the actual problem to solve.

I think this really old article addresses it better. It's self-explanatory.

Managing Complex Design Projects (1995) http://www.dubberly.com/articles/managing-complex-design-pro...

I just read through that. Asking questions and planning up front? Documentation before code? Thats so waterfall. (And it works quite well for some projects). Certainly having a problem that isn't clearly defined is a good way build something that doesn't solve the problem well.

I wonder how that sits with "Don't bring me problems—bring me solutions" that I occasionally hear from non-technical managers...

There is a need for both approaches. If you have the expertise to be able to diagnose the problem, asking for the problem to be solved is the right approach. When dealing with non-technical issues, where the person coming to the manager is familiar with the process, it makes sense to ask them to bring solutions (as a first step) instead of imposing something on them.

A problem without a suggested solution is a complaint. If your people only bring you complaints, it is a drain on everyone; it breeds discontent in the workforce and contempt in management.

I feel that some people are very good at seeing problems, and some people are very good at finding solutions to problems.

I don't see any reason that the same skills should be present in any given individual, so you always need both types.

I understand what you are saying. How does someone who is good at seeing problems communicate those problems and not come off as whiny and complaining?

I often hear "Ugh, it's tiring you telling us what all the problems are, why can't you tell us the solution?".

But I get "Man, I'm so glad you saw that problem way back at the design stage. We really dodged a bullet there." about 3-4 times as often.

What I generally don't hear is, "OMFG, our project is about to fail. Why did no one see that this issue was coming and do something about it!".

The assumption that anyone noting a problem is just whining and complaining is a good way to tank a project. I've seen that type of thinking prevail, and it sucks for everyone.

To me its part of the taxonomy of becoming a more experienced developer:

- First you can implement solutions (jr level) - Then you can design solutions (mid level, sometimes senior - most of time is spent here) - Then you can find problems that need solutions (senior, management)

Extremely well.

Stakeholders are supposed to present problems to engineers, and engineers are supposed to propose solutions to stakeholders.

The underlying meta-rule is that problems should be solved by the person with the most expertise.

One of my best managers ever was non-technical. His line was, "you're smart enough to fix this, so do it, do it right, and don't let it happen again." He did a great job getting the resources to back it up, too, while shielding his team from company politics. Right up until the point where he lost at company politics, anyway.

I guess the trick is to be an expert in Machiavellian games and intrigue without truly holding the values that typically drive such expertise.

I had a very similar experince with a similar boss, and similar conclusion.

But yes, best manager I've had.

I appreciate when they bring me a problem with a suggested solution. It's often quite helpful in determining the best possible solution, and so far as I remember, they quite often got that solution implemented.

But before I started asking that, and just implemented their solutions, I got a lot of kickback for it not actually solving their problem, which is how I learned to ask it in the first place.

The client bring the problem, the vendor brings the solution

Feature requests are really prone to this. Customers will only ask for features they can imagine, not the ones that really solve their problem. A significant chunk of the time the customer is better served by a different feature that takes less work.

This is why i don't like tender-based software projects. The tender already describes the features needed, and they must be built even if they are suboptimal for the problem domain.

One of our Business Partners suggested a pop up box with Yes No Cancel, and then went on to describe the behaviors of each button. Absolutely no imagination. It's like people have been broken by years of limited choices.

With some types of people, I've just stopped trying to get them to back up and describe the underlying pain point they are trying to relieve. Because as far as I can tell, some people just can not do that. Instead, I let them describe their implementation and listen/ask/listen/ask/listen to understand what they're actually trying to fix.

And then once we have the problem figured out, we as a dev/design team go back and work forward again to design a proposed solution. And then we present that. Often enough, they're happy to accept it. The trick is that some egomaniacs just get fixated on their own proposed solution, and won't let go. And then you just give them their Homermobile: http://www.wired.com/wp-content/uploads/2014/06/the-homer-in...

Could you give an example of what you mean by "tender-based software projects"?

The client writes spec and solicits a bid, instead of soliciting design partners.

If I had a dollar for every time a customer finally confessed that they actually wanted a different feature but thought it would be too expensive...

Nothing like blowing $40,000 on a $1000 feature.

why don't you force it 5x?

I just don't think there's a magical number that works for me. Dealing with users/clients is really just dealing with people so I guess it ends up like being in a light therapy session, asking questions until you get a good understanding of the real problem. I'm not good reading people but I think I'm good understanding their issues. Empathy gets you a long way. That's probably half of it, the other half being dealing with their expectations.

I've tried forcing it 5x and found that the fifth Why is exactly the point where they get annoyed and stop talking to you. So there may be a magic insight at the fifth Why but you'll never hear it :)

What if you told them ahead of time what you were doing, so they would happily cooperate knowing there would only be 5? Otherwise, by the fifth most people will think "man, this never ends..."

I'd probably ask "Why 5 times?" and then it would be game on.

"Diminishing returns."

By six, you're usually at something like "because that makes me happy". By seven, you're into metaphysics and cognitive science.

Of course, some issues are genuinely simple, and you're off in unhelpful territory halfway through. I suspect five why's is a decent estimate, but not necessarily more accurate than four.

There's a really good Louis CK routine about this, involving his young daughter.

The magic insight is always this: "Because I want to feel good." When someone doesn't want to put this in words, they get annoyed and stop talking to you.

You're so right... but you can substitute "powerful", " secure", etc for "good"; and also sometimes "because of secret reasons".

Sometimes it's, "Because I don't want a repeat of this crappy thing that happened to me."

Often software is used as a means for one group inside a company to control another group.

Part of the idea is that if it takes more than 3 or 4 "why"s to get to some really fundamental business goal (i.e. "Because I want to make more money"), then it might not be a problem worth solving in the first place

A blind drunk man was jaywalking and was hit by a distracted and inexperienced driver and died. Why did he die? There likely isn't a singular root cause. There are 5 potential singular root causes, but they are a subset of the 5-factorial potential combinatorial root causes.

I agree that solutions before problems is bad, but the five whys is problematic simply because it promotes the idea of singular root cause which is almost inevitably a fallacy when analyzing complex systems. There are often conceivably millions of overlapping and/or interacting causes to an observable problem. Sometimes, trying to boil causality down to a single item is merely missing the point, but very often it is much more problematic. Unintended consequences from solutions derived from improperly attributed singular root causes can be terrifying.

This seems like an overly simplistic interpretation.

The answer to "why" can be three different things. So you ask why to each of those. Repeat.

The five whys is only "problematic" if you expect it to give you the answer. It's only a means by which it can be easier for you to arrive at one or more of the many possible answers.

The point of 5 whys is NOT to assign proper blame for each problem. It is to give you a way in a complex system for identifying pain points that are causing you repeated problems.

I agree.

Relevant: http://web.mit.edu/2.75/resources/random/How%20Complex%20Sys...

My experience is that asking five whys can help you manage or mitigate some of the root causes. You probably won't get them all on this pass, but if this is important, it'll come up again and you'll try some other root causes. However, if you think you've found the root cause, you're probably wrong. I dunno about "terrifying", but accumulating scar tissue can definitely create more problems than it solves.

"My problem is that I need an app to x, y, z."

No, no, no!

Why is there no filter on the intake? It was proposed, but declined by management as "too costly".

Why is it too costly? Because cutting visible costs is perceived as saving money and therefore Good, whereas prevention and maintenance are perceived as unnecessary, because Bad Stuff Just Happens Regardless.

Why? Because people suck at statistics ("if we can't eliminate a risk altogether, there's no point in trying, let's just forever keep fixing the fallout") and because Fixing Broken Stuff Is Someone Else's Budget, Let's Pass The Buck.

(Or at least, that's the way things tend to turn out when you decide to go beyond the immediate cause-and-effect)

I was also disappointed that the example list didn't get into people issues.

But it is not as simple as prevention vs. cost-cutting. In any place, there are thousands of things that might prevent a problem, but which of them are worth doing? One of many strategies for selecting the right precautions is an evolutionary one: fix the ones that caused problems in the past.

This. My management is like generals fighting the last war. They continue to push process as an answer to anything that has caused an outage instead of reworking the process that we already have.

Unlike the Red Queen problem of arms race, "fighting the previous war" could help with one class of support problems (not always, not all problems). "Hmm, we've been here before, we know how to fix this; plus we should make it harder to get here again by accident."

I think the big question is whether you ever win the previous war.

If every problem adds permanent overhead ("add a check for that issue in the review process") then you're slowly losing ground. If problems get solved ("automate that step so no one forgets it"), you're making progress even if you don't anticipate issues.

Well, if you reworked the process, would it at least win the last war? Because if the "new" process reintroduces known points of fragility, you're guarding against potential problems at the expense of known problems.

It might be worth asking "why" of them. :)

Just as "Five" is really just a rule of thumb as pointed out by other people, "Why" is really just a rule of thumb too. "What can we do to prevent the underlying problem?" just isn't as catchy, but it's closer to what you should be really asking.

"People suck at statistics" is not an answer to that question. "Train people" is an answer, but only an answer. You've also got "something to make us more robust to bad statistics" and, no sarcasm, "trust the statistics less in the future", and several other such things. Another one I'd consider, for instance, is that if some set of statistics is truly bringing negative value to the process, stop collecting them.

Also, "we've got fundamental management issues" can be a valid answer. If you're in an engineering environment but your management isn't able to work that way, try to do something about it. In the end, it is not out of the question for the process to produce "I need a different job", though I think one has a professional obligation to at least try to fix the underlying problems first.

This is a process in which neither blind idealism nor blind cynicism is the road to success. If you're just getting cynical answers, that's not a reflection of the process, that's a reflection of your cynicism being too strong. Tone it down. Don't get rid of it. I would never suggest getting rid of it. But tone it down. And get more specific than "people generally suck" or anything that is simply a variant on that.

Of course it's not an answer - just asking "why" gets you turtles all the way down, and "stop after five steps" may halt you with a stack that's too shallow; as you say, it's a rule of thumb.

And now we're finally getting somewhere :) Cynicism can be a tool, a catalyst - "these are all the things that are unfixable, because Eeeeverything Sucks" is a good set for asking "are they all, really? Are there those that are only hard to fix, and which of them are worth fixing?" As you say, it's rare that there's a single, clear-cut answer for an issue, especially when it's not purely technical one.

I didn't intend my reply as a rant, and surely didn't intend it to mean "everything is broken, get out of here" as a solution.

To some extent I write to remind myself... I too tend towards the excessive cynicism rather than the insufficient. "All have sinned and fallen short of the glory of Knuth" may be a true statement, but it does tend to lead to fewer actionable ideas.

There seems to be some confusion/mis-interpretation about the 5 part.

This is called 五回のなぜ in Japanese ("Go-kai no naze," or Why Five Times) and refers to root cause analysis. Of course the number of times the process need be repeated until the root cause is identified is variable. Five in this case is merely a jingly mnemonic, as Japanese people are so fond of.

jignly?

jingly!

Jingly – like a jingle.

Could it be a play on the word 誤解 [1]. As in '誤解のなぜ’.

[1]http://eow.alc.co.jp/search?q=%E8%AA%A4%E8%A7%A3&ref=sa

Could you explain this play on words for someone who doesn't know Japanese?

I'm guessing but 誤解 => 'go kai', which means 'misunderstanding'. That sounds like 五回 => 'go kai', which means five times.

In Japanese, you often encounter words/phrases that sound more or less the same but are written differently.

Both the original Japanese (meaning 5 times) and possibly pun Japanese (meaning misunderstanding) are read as 'gokai'.

I don't really get how that pun works (it's not as though that's a common phrase). It seems more likely that it's chosen just because five is a round number.

If we're just going for homophones it could just as easily be "fifth floor" but that also doesn't make a lot of sense as a pun.

Exactly. This is all about getting to root causes.

I learned this working in a manufacturing environment for several years the was implementing the Toyota Production System and all the things that are a part of it like Kaizen, Kanban, etc.

After I left I thought it was too bad that all that good process was locked into the manufacturing world. I've seen it creep in more and more, often under the classification of UX with understanding user flows and actual problems of usability on a site (another area where asking why 5 times is very helpful to get to the root of a user's feedback).

I've also seen what I call "kanban flavored agile" be one of the most effective engineering processes for environments with ever changing requirements who don't need the rigid deadlines of sprint-based planning. When I saw it in manufacturing it was all about "just in time delivery" meaning a factory could easily switch production lines when suppliers missed deliveries (or delivered defective goods) or a machine broke down, etc. Which when you compare to the sorts of things that happen most every day in a typical software organization doesn't sound all that different.

Thank you for confirming. :)

I've always thought the idea behind "5" was to encourage you to ask more than once or twice. I think it's natural to stop after once or twice but you usually get the good stuff further along. Why is the sky blue? The atmosphere. Oh, ok -- I got it. There's a lot more to the story.

I know a certain 3 year-old who uses a similar trick to collect knowledge about the world. Not being sarcastic here; orgs can learn a lot from young children about how to acquire new skills and make decisions in the face of uncertainty.

Before they can even walk infants learn to judge whether they're about to crawl off a cliff -- a skill the yahoo board (for example) could have really used.

It's an excellent technique for learning unfamiliar domains (which is almost everything, for a 3 year old). If you don't have a strong framework to fit new data into, ask "why?" a bunch of times and people will hand you relevant pieces of that framework.

Actually...

Babies learn to crawl, then learn to not crawl off cliffs. Then they learn to walk, then they learn to not walk of cliffs. So there is a point after they won't crawl off a high drop, that they will just walk off it.

https://www.youtube.com/watch?v=WanGt1G6ScA

I survived several years in a Six Sigma organization. The Five Whys was one of my favorite 'tools' despite the 'Black Belts' dragging the process out much longer than required.

I've never seen a methodology burn through more easel pads.

Why are the five whys one of your favorite tools?

Why do you want to know?

Why do you want to know why I want want to know?

Unlike most management methodology nonsense, it works and makes sense.

Why are most management methodologies nonsense?

Why are most technology things gooblygook to normal people?

Management is a domain with domain-specific terminology and jargon. It's not terrible, just not user friendly. 5 whys is at its core really approachable. You may need to find the guy with domain-specific expertise to answer the 5th why, but still understand how you got there.

Like Spooky23 said, it actually works.

We had one project where the office admins kanban'd the conference room. This resulted in rectangles of painter's tape with a white label inside that read, 'Projector remote'.

Six Sigma has some value, but most of it is branded logic.

"Why do vehicle manufacturers lie about emissions?"

It's supposed to be

   why(why(why(why(why(theMatter))));

not

   why(theMatter);
   why(theMatter);
   why(theMatter);
   why(theMatter);
   why(theMatter);

A bug that I will blame on unclear requirements.

Why?

You could keep the second form but use a ditto operator instead;

   why(theMatter);
   why(%);
   why(%);
   why(%);
   why(%);

When I'm interviewing for a job at VW and they ask this question, I can deflect with my curry skills.

That sounds very meta.

compiler error at line 1. unmatched parenthesis.

... oh don't worry it's a loosely bracketed language.

That's one of the best points of Haskell:

why . why . why . why . why $ theMatter

Actually that is point-free

Careful, enough why()'s and you invariably get nil. This is a pointer your employer probably doesn't want you to follow.

I usually get "Because BIG BANG".

But good point - you want the why function to write the intermediate answers somewhere as a side effect.

I'd be interested to know why(Because BIG BANG)

Do not ask `Why?` Be cautious with `How?` `Why?` leads inexorably to paradox.

In a stack language:

  theMatter why why why why why

Well, that's possible. But sometimes also the whys are mutually recursive.

"Why is X unelectable? Because realistically no one will vote for him. And why will no one vote for him? Because he is unelectable"

I think the worst case scenario is an answer that forms a question, which lead to the answer framing the very question.

Infinite recursion. Basically.

I think its more like:

    Answer Why(Answer question) {
        if(validDivisibleQuestion(question){
            return Why(question);
        }
    }

I guess this is how our mind handles stuff too, and because of the stack issues is why working things on papers works better than doing it in mind.

Because they make money and it takes a while to get caught.

Why does it take a while to get caught?

That's only one "why".

because the emmissions test conditions are predictable

I preach this whenever i can in regards to social issues. Whenever one of your friends, or any person, acts in a way that you don't agree with (being rude, sleeping around etc), be patient and try to think about possible underlying causes; it's much more fruitful to engage the underlying unhappiness (carefully) than to react hastily to the immediate situation.

Why do you have the assumption that all behaviour that you don't disagree with has a cause of underlying unhappiness?

Some people enjoy things that other people don't approve of.

And also why do some people enjoy things that other people don't approve of?

And why don't those people approve of those things?

Because they are secretly unhappy

Unlikely that there's a single cause. One possibility is that people's value systems differ: do you like smoking? Do you like eating bacon? Do you like sunbathing? For each, there are people that disapprove, or would like you not to do this, or would even ban you from doing so (I could pick more controversial examples, but these are sufficient). Conflict clearly exists - but a way of resolution is not clear at all.

Reminds me of Feynman's answer[0] when asked about magnets.

0.http://youtu.be/MO0r930Sn_8

I love Feynman. He was an incredible teacher but this video has always annoyed me a little. The interviewer asked a pretty clear question (explain why magnets repel or attract depending on how you align them) but Feynman goes on a bit of a rant about how the guy won't understand if he explains things as he (Feynman) understands it and that he (Feynman) doesn't know how to explain it to him (interview) in ways he would understand.

For someone as excellent at sharing knowledge it seems like Feynman just didn't want to do the interview any longer. He sounds and acts a little pissed off with the question.

Well for me it sounded more like he wanted to stress the fundamentality of the magnetic force, and the weirdness of it by not showing up in other familiar areas to wich he could relate to in an analogy - but I agree that he didn't do a very good job with that answer.

Feynman tries to explain the absurdity of trying to ask questions which if divided down to their most simplistic forms can't give binary 'yes' or 'no' answers.

The issue with the 'why' questions is at the bottom most place in the the 'why' stack you need to have an axiom/postulation or at least a plain assumption, without which you can't explain the subsequent 'why' or 'how' questions.

Now this a classic trick in trying to prove science as useless and propel pseudo science concepts among crackpots.

Yeah I understand Feynman's point it is just if you watch the whole series of questions he has no problem answering other questions.

A perfectly acceptable answer from Feynman would have been to just explain magnetic force in a basic (high school) level.

He could have made his argument about any of the questions the interviewer asked as pretty much every scientific question will get down to fundamental physics which will be beyond most people.

Sometimes I have multiple solutions to a problem in mind and want to throughly investigate them, but run into a minor road block when investigating one of them.

In forums, some of the most annoying threads are people that are trying to help you "solve your real problem" instead of helping with the specific question at hand.

You know what's even more annoying? People who ask very misguided questions, because they're obviously trying to solve a wrong problem, and yet insist on doing things their own way even though it will lead them nowhere. They're much more common than people who know what they're talking about, and it's usually easy to tell them apart based on the communication style.

More common perhaps, but not always more significant. Stack Overflow is a messy blend of the two: lots of questions want to do some strange thing, and it's not always clear why.

The result is that people who don't know better are taught how to do dangerous things (like messing with the history of shared git repos), while people with weird special circumstances get second guessed and lectured.

At least online, I absolutely disagree with the idea that it's easy to tell the two groups apart. Doing so is one of the bigger challenges for lots of "advice" forums.

while people with weird special circumstances get second guessed and lectured.

I'd argue that if they cannot make it clear they are in special circumstances rather than being clueless, then they deserve second guessing and lecturing. That's what I meant by communication style.

What usually happens as one of the 'solve your real problem' people is context. You searched for a path and ended up with a path of A->B->C->D->#block->F but you only tell the group about D->#block and all the readers are guessing how you constructed a path to get to D. The destination of F is often also not clear and missing from the problem description. Even if the reader can approximate a route from A->...->D->#block->F they have a chance of applying their own experience, because often D->#block is a true dead end of the hopeful path of A->F.

Too many systems have contextual inputs that only make the solution apparent with adequate context, so really we are hoping for A and F.

This might be the deepest issue with Stack Overflow.

People post some bizarre objective/problem (because the bizarre stuff is what you need to ask about), and half the comments are people asserting that their goal is wrong.

There's no clear solution, though, because half the time the goal really is misguided, and the other half the "right" way is for some reason unavailable. The best answer I've seen is for commenters to offer "you really shouldn't do that normally, but you could try this to make it happen".

https://en.wikipedia.org/wiki/5_Whys

I have read Ohno's book. http://www.amazon.com/Toyota-Production-System-Beyond-Large-...

One thing that stuck out to me was how long everything took to figure out on the Toyota Production System. Ohno spent decades streamlining processes. The timeline is in the inside cover of my copy of the book.

Fascinating read, and easier to read than some other "Toyota Production" books written by academics. Recommend.

This. When folks come to my Startup events I host and ask about Lean I point to this book. Informative and an easy read.

Keep pressing next on that page to see a few more bite size pieces of Toyota wisdom. They won't change your life, but for 30 seconds or so you'll associate Toyota with intelligence and innovation.

Why 5x? You should rather check when you reached the point that it will not happen again.

Probably nobody is assigned to the task of installing filters in new machines and the next one will fail again...

because at 7 or 8 you are moving into "the supernova explosion created elements heavier than iron" category

The subsequent "layers" of reasons are fundamentally different.

For example, applying this to IT when analyzing the underlying causes of a particular downtime or security breach, usually, the first 2 layers of "why" are technical reasons that need to be adressed by the relevant specialists, the next 2 layers are failures of policy and procedures that need to be adressed by the managment chain, and around 5th "why" you get to weaknesses in the organization, company priorities and values which is slow to change but valuable info anyway.

Beyond that you just get to acknowledgements about how life is not perfect that is not actionable, but the first 4-5 layers of 'why' generally do lead to something that can be fixed given proper authority and motivation.

It's '5x' for two reasons: (a) that's a reasonable target for how many times you might have to ask it before you hit a root cause and (b) the 'five' is meant in a more metaphorical sense - you're meant to ask until you hit the root cause, but 'five' is catchier.

1. Why is Toyota accelerator-pedal drive-by-wire code a spaghetti mess of impossible to debug code?

2. Why still? 3. Why still years later? 4. Why a decade later? 5. Why not fix it?

http://www.edn.com/design/automotive/4423428/Toyota-s-killer...

This is why my car is the last model with mechanical accelerator and steering.

The first time I heard about this was from Joel Spolsky of Fogcreek/Stackoverflow. It really changed how I've approached postmortems and encouraging those to really drive deeper into problem solving. http://www.joelonsoftware.com/items/2008/01/22.html

AKA "Popping the why stack"

Ask why more than twice at my job and you'll get in trouble. Sometimes the boss, and the customer, doesn't want to be asked. I think this idea is too aggressive and indicative of high pressure sales tactics.

Indeed!

It can be done without just seeming rude. You just have to practice a bit.

You can often avoid asking the "why" question explicitly. If you instead ask about the unintended consequences of the current policy, people will elaborate on the reasons why the situation is undesired, without you asking for it.

For example, in the third question of the article you could ask "Is this the usual level of lubrication?" and you will reach the same conclusion of "No, the oil pump on the robot is circulating less oil than normal."

The point is to be the boss, then ask five times.

The Five Whys is essentially Toyota's version of Root Cause Analysis.

"Why?" is a fine response to a statement of intent; but "How do you know that?" as a response to a declarative statement used for motivation can often be more enlightening.

(This kind of epistemological work-out is handy in lots of other situations. When the JWs or Mormons show up at your door, asking "How do you know that?" repeatedly is often all that you need to do until they give up and go away.)

Oh man! I think my two year old boy is set to be a genius manager! He's asking more than five why's about pretty much everything!

5 whys is my go-to debugging strategy for truly mysterious software and systems bugs.

The rubber hits the road at the point where you have an answer like "one of A, B, or C occurred" and you don't know which because none of them are ever supposed to happen :) you know you're within a clue-bat-swing-radius of the problem then.

"when you have eliminated the impossible, whatever remains, however improbable, must be the truth"

I believe Goldratt suggested something like "ask why until the answer is a feeling" which is much in the same vein as the five whys. For anyone wanting to learn tactical approaches to root cause analysis, lookup Goldratt and ”reality tree", profound life/career/wealth changing stuff.

"Why" is my favorite question. It's also the most important and leads to solutions for 9/10 problems if you just keep asking it. Stop when you get to the root cause that you can fix (not some arbitrary number like 5).

But sometimes the whys do not converge; for example, in the case of a vicious cycle

But then you can recognize that situation, and ask why it occurs?

When would that actually happen in reality?

The rule should be "Ask 'why' at least five times" !

The first speaker at Beyond Tellerrand said this in his talk about 15 minutes ago. Coincidence? Or was this submitted by someone at the conference?

p(hnSubmitters ∩ btAttendees ≠ ∅) > 0

https://youtu.be/4u2ZsoYWwJA?t=6m19s

Wow, Toyota being given some love?! I thought there was a blanket ban on all things Toyota so the community isn't forced to admit that all things agile are actually from the manufacturing industry, decades ago. Where might this lead? Might we be forced to consider that much has been borrowed from architecture? Or math? But then, it will be so much more difficult to feel good about dwindling list of contributions software programmers have born to the world.

That's a really valuable lesson learned from The Lean Startup :-)

This method was invented by https://en.m.wikipedia.org/wiki/Sakichi_Toyoda. He died in 1930.

I'm pretty sure that it predates even the word "startup" as it is currently used :)

I know that Eric Ries did not invent it, but he spread this idea with his highly popular book.

"The Toyota Way" (https://www.amazon.co.uk/dp/0071392319/) probably had more of a hand in popularising it overall.

The method creator is duly credited in the book.

Why Moon orbits Earth? Why not Sun? I'm struck with 2 whys :)

Actually by some definition Moon orbits both Sun and Earth.

Why should I ask 'why' five times about every matter?

A very good approach.

Frequently talked about, rarely applied.

I find it hard to figure out if I'm only finding the answer I'm looking for.

Apply 5 whys to "Why did Snowden leak classified information?"

I can think of multiple directions it can go: "he's a traitor who managed to get around security policies", "the US spies too much", and "contractors aren't covered under internal whistleblower protections so leaking was the most likely way to get things to change."

That's fine. Coming up with multiple answers is useful, and then you can either explore all of them or you can filter.

For example, I think that you are jumping down too far with your first responses. Snowden leaked because:

1) he had access to it - exploring the why's here will improve your security

2) he was appalled at what he saw - exploring why's here will lead to discussion of whether he was right

I can, in no more than 5 whys, get from ANY problem back to my own personal hobby horse issue.

Typically you'd avoid subjective analysis in 5 why's so transform traitor into person and too much into empty string and in the third answer it should probably have "was perceived by Snowden as the most likely"

Or you could, you know, just figure out the root bloody cause of things.

Can you package that message up and sell it as a consultancy?

Five whys is a form of simple, expedient root cause analysis. It's meant to be simple enough that you don't need a consultant to teach you how to do it.

That doesn't stop people from trying to take 'shortcuts' though, and those shortcuts are what consultants prey on.

Why?

Pity they don't believe in this in real life.

Why does the hybrid braking system and mechanical braking system disengage with ABS, but then only re-engage the mechanical brake, resulting in a considerable change in deceleration, causing you to have to depress the brake further to avoid colliding with things in front of you.

Still waiting on a good reason for that one...

Is this different than the "unintended acceleration"?

I wonder what the answers were to "Why did we conceal our deadly (not for Toyota, but for their customers) mistakes?" and "Why did we actively deceive our customers regarding the safety of our vehicles?"

    for((I=0; I<5; I++)) ; do read -p 'Why? '; done

5 is getting close to the point where all possible answers converge to: "because I / they / someone want(s) to feel good."

I have just have one 'why':

Why is Japan's GDP growth looking like this: http://www.tradingeconomics.com/japan/gdp

Not that I don't like posts about management techniques but from Toyota (their best years are also some time ago) from Japan... I don't know.

It's a function of their money supply growth - which is now extremely low. Back in the 70's and 80's during the Japanese Bubble, it was relatively much higher.

Prices are a rather fuzzy function of the money supply, total production, and the supply of credit (for things customarily bought with debt). GDP is calculated by adding up prices of goods and services sold. Even though it is typically corrected for inflation growth, this doesn't adequately compensate for monetary growth, because production growth acts to reduce prices, and the two mask each other to some extent.

tldr: GDP is a terrible way to measure a countries output/growth.

That seems like a disingenuous question and the generally accepted answer is on the same website you linked: http://www.tradingeconomics.com/japan/population

Fewer people = less growth

Reply on news.ycombinator.com