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.
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...
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.
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.
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 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.
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.
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)
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.
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.
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.
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.
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.
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'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 :)
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.
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
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..."
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.
> 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.
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.
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.
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.
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)
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.
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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
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.
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."
"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.)
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.
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).
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.
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."
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"
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 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.
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?"
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.
