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.
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.
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...
Nothing like blowing $40,000 on a $1000 feature.
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 don't see any reason that the same skills should be present in any given individual, so you always need both types.
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.
- 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)
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.
But yes, best manager I've had.
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.
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.
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.
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.
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.
Often software is used as a means for one group inside a company to control another group.
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.
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.
No, no, no!