Live data from Hacker News

“Ask 'why' five times about every matter”

toyota-global.com

161–170 of 172 posts

Re: “Ask 'why' five times about every matter”

#161
post #9

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.

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 whic…

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.

Re: “Ask 'why' five times about every matter”

#162

Earlier quoted context omitted.

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.

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

Re: “Ask 'why' five times about every matter”

#163

Earlier quoted context omitted.

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

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 had a very similar experince with a similar boss, and similar conclusion.

But yes, best manager I've had.

Re: “Ask 'why' five times about every matter”

#164
post #15
post #5

Earlier quoted context omitted.

It's supposed to be why(why(why(why(why(theMatter)))); not why(theMatter); why(theMatter); why(theMatter); why(theMatter); why(theMatter);

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

Re: “Ask 'why' five times about every matter”

#165
post #123
post #43

Earlier quoted context omitted.

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 pro…

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

Re: “Ask 'why' five times about every matter”

#167
post #9

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.

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 whic…

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.

Re: “Ask 'why' five times about every matter”

#168
post #43
post #9

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 pro…

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.

Post reply on HN