This video exemplifies for me the 5 wrongs with business school yuppies:
* Smart looking guy in a fancy suit
* Confidently talks about stuff he doesn't have a clue about
* Applies over-simplified abstractions completely detached from reality
* Draws wrong and ill-conceived consequences from said abstraction
* Never realizes it's really the guys in the trenches
who keep his bacon afloat by politely ignoring his pointless
ramblings and just quietly cleaning his mess after him.
But yes, next time our "server crashes" I'll apply the "5 why's" for team motivation. A good laugh never hurts, especially when you make it a proportional investment.
I sat next to Eric Ries for months and worked with him personally. He knows about everything he talks about in that video and it's completely accurate. And the process worked.
1. Nothing, but I had 5 bullets to fill and he thankfully served the stereotype.
2. Anyway, skipping the bullets now.
What bothers me about this "presentation" is that it's the prototype pointless "biz-speak" ramble that many of us have to deal with every day.
He packs a nugget of truth ("when shit happens, ask why!") into a truckload of superfluous verbal padding and tries to sell it as some sort of great revelation, all the while completely ignoring the reality of the situation™.
Over here in the real world root-cause analysis falls under common sense for every engineer worth their salt. We are naturally inclined to fix problems at the source, simply because we don't like fixing stuff in the middle of the night, because we hate fixing the same thing repeatedly, and because we like paychecks.
However, his video lacks the tiniest bit of acknowledgement of reality, where the answer to the third 'why' usually amounts to something like "because the boss decided to outsource this" or "because the deadlines make no sense" or "because 3 people are doing the work of 8 here" or "because the product manager is incompetent" or "because they wouldn't listen when we told them 5 times this would happen".
Yes, these are people-problems, too. But you rarely see those addressed, presumably because these shiny polished biz-school fortune cookies tend to
conveniently ignore how the fish, more often than not, stinks from the head.
I could go on for a while on his rosy misconceptions about "proportional investment at every stage of the problem" (duh! can it be that simple!) and "training", but this is getting too long already and I'm going to be voted to -8 and beyond either way.
Of course root cause analysis is common sense, anyone with a couple of braincells to rub together gets it as soon as it is explained to them.
However as I understand it Ries' drive is for it to be a institutional practice, you are right an engineer will get to #3 as you say and there it will end. However if the entire company has taken up the practice it won't stop there. This is especially true if root cause analysis isn't used to assigning blame but fixing issues.
As to management and people issues, he addresses that directly in the video talking about management issues being part of the process. So this aspect isn't ignored and is promoting them being addressed.
I am certainly interested in what misconceptions there are is in "proportional investment at every stage of the problem" as I have used this stuff successfully in the past.
Well, you can formalize common sense only so much before it turns into parody.
I've been in these meetings too often where one (or more..) of the managers would follow their formulaic script, repeatedly uttering these catchy phrases without ever grasping the kernel of the issue.
Yes, "proportional investment" sounds awfully catchy. Yet it's simply not applicable in any kind of interesting situation. You can't "proportionally invest" into fixing a cronjob that shouldn't exist in first place but had to be rushed as a bandaid to meet unrealistic requirements.
You can't "train" a manager to make reasonable trade-offs when he has a track-record of doing the opposite.
These are literally the two most common root-causes that I have seen. And it would be great if the "5 why's" were ever executed consequentially, but they are not. In this type of meeting the analysis always ends before it gets to the point of questioning the guy who was calling the shots that went in the foot.
The cases where the formulaic "5 why's" are actually applicable are the uninteresting ones, the easy ones, the no-brainers.
It's the cases where the intern screwed something up - yes we shouldn't give critical stuff to the intern. Or the cases where not enough headroom was planned - yes we should be more conservative. In short: It's the cases where nobody important gets hurt by the conclusion.
I have never seen a people-problem being solved by someone following a catchy formula.
You either have the common sense to identify and the balls to tackle these kind of problems - or you're likely part of the problem in first place.
But in functional teams all of this isn't even something anyone talks about... Which makes videos like the above seem so surreal and detached from reality.
In this type of meeting the analysis always ends before it gets to the point of questioning the guy who was calling the shots that went in the foot.
One of the things I really enjoy about 5 Whys done well is that it can be done asynchronously. You don't need to gather everyone into a room for a long drawn out retrospective, preach lofty best-practices that everyone knows, and come out of it with nothing actionable on a reasonable timeframe.
Instead, someone who was close to the incident can draw up a quick email with the 5 whys, a tally of person-hours spent on the incident, and send it out quickly.
Oftentimes the answers from the 5Ws /are/ obvious to engineers -- we need more monitoring! that wasn't tested well enough! we didn't have time to prepare for this problem! -- their power comes in formalizing cleanup of technical debt, and prioritizing it appropriately.
Production problems don't get swept under a band-aid, new features get queued until the proportional investments are made.
And, yes, if the 5 Whys has management buy-in, it does address why the problematic cron job was rushed into production in the first place.
I think you can teach a manager with a track record of bad tradeoffs. The first step is showing that manager that their track record isn't as good as they may think it is. And that's hard to do in a single incident, so consistent feedback over time, as Eric suggests, has a chance to help enlighten.
If the past track record is bad, and one opportunity to enlighten is pursued and they "don't get it", that's ok. Either another chance will come up in the future, or it won't. If it doesn't, there isn't really a problem.
I believe that thinking like this is helpful by giving license to "demand fixes for things that aren't yours to fix". Specifically, why stop in the example at fixing the bad code? That's what some organizations, perhaps more than half, would view as sufficient.
I agree completely, thought I was the only one who saw it much like you. Eric Ries deserves credit. He knows his stuff, he worked his way up, he has a lot of great advice we can learn from but lets not just let him ride on his past successes here. This cannot be his best work. Unfortunately this does end up sounding like it came from some stereotypical higher-up that's totally detached from reality. The 5 why's? How about we save the cute names for it and call it what it is: wrapping up common sense in a cute name and selling it as innovative.
Besides that I don't like how he oversimplifies the root cause of these problems he's talking about. He's pretty much saying that all problems in your company can be traced to people. It's a person that is always the problem according to this video. That's not so. The problem can be people or it can be ridiculous processes like going through "the 5 why's" or it can be anything else in the world including a random act of god. Hopefully Ries bounces back with something better. Hopefully he hasn't peaked like the business school version of a pop star who's 15 minutes are up.
If it's common sense why do so many companies fail at identifying and addressing root causes? If making it a process with a name that's rigidly followed isn't the solution, what is?
It's not a complicated process that requires certification. It's simple enough to be described completely in three minutes.
I'd also love to see an example of a problem you've encountered that is actually pure technology, since virtually all modern technology is created and maintained by humans. I've run into lots of crazy hardware and software problems, but pretty much all of them had a human involved here or there that could help make things better.
If it's common sense why do so many companies fail at identifying and addressing root causes?
One failure that I see very frequently is that the analysis reliably stops at the invisible line between the trenches and the management.
I.e. the people-problems are very well identified by everyone in the room, but nobody feels like calling out the guy who sits on the other end of the table in your next "performance review". It just doesn't seem like a good idea.
This is something that I'd like to see people like Eric talk about.
Because either I live in my own personal bubble here or that is a much more common problem than people not knowing how to trace back a technical issue to people and processes.
In fact, every engineer I know could sing you a song about it. But again, perhaps I really just happen to live in a particular bubble far away from Harvard...
That's a really fair point, but it's also not a problem unique to any particular technique or process. There is literally nothing you can do via process to protect yourself from bad or actively harmful management. Your only choice is to try and drive them out of the company, or leave.
Maybe the problem is that 5Ys worked great and seemed like a nice process improvement because we had healthy management. I think the reality is - the unhealthy managers who could really benefit from Eric telling them how to be better managers? They're never going to go anywhere near HN or the Harvard Business Review.
Maybe we're trying to identify, or dare I say create problems that don't really exist. If its simple enough to describe in three minutes then I'd say it's very close to being common sense. What I see when I watch that video is someone trying to make a simple thing complicated. Do you really need five Why's? I think there are 4 superfluous Why's in that process. Eric Ries has the experience and education to talk about this stuff but at a certain point, after anyone has been out of the trenches long enough, they start to lose touch. This to me seems like an example of someone who once knew what was up now having nothing better to do than over think something as simple as "Ask Why something went wrong" and turn it into "Ask why something went wrong in 5 different ways" even though asking Why just once will suffice. Now, you asked why so many companies fail at identifying and addressing root causes. Well, why don't we apply the 5 Why's and see if we can find out?
He's pretty much saying that all problems in your company can be traced to people.
I shared the same concern, but having heard Ries speak in the past, I think his use of "people" here is a bit misleading.
A commenter on the video made the good point that it's probably more accurate to refer to "process problems" than "people problems". I think this video may have been flavored by his audience, looking down from an upper-management perspective.
"People problems" implies that you need to keep people from messing up. "Process problems" includes more institutional problems: culture, training, scheduling, prioritization, &c.
Honestly, I like Eric but this is kind of a strange video. The core of what "5 whys" is is root cause analysis. He doesn't really explain this and then goes on to, if I'm understanding him correctly, say that every time you hit the same root cause, spend a small amount of time on the fix? Or address each of the "why's" individually?
There's also something of an assumption that the root cause always ends up as a human problem and not a technical one which is only sometimes the case.
This ends up turning a very powerful process and tool into being a very convoluted MBA speak on process and team dynamics.
I suspect what he means is that the “root cause” is not a single, binary thing that is simply “fixed or not fixed”.
In the training example, it’s quite possible that the first hour of training will cover 80% of the problem, with subsequent hours offering diminishing returns. The point is to discover it while avoiding waste.
He’s acknowledging that “root cause” is a club that can be used for bureaucracy; handled wrongly it looks a lot like premature optimization or CYA. What he’s describing is what I consider empiricism.
The first half of the video served as a good example of how the 5 Whys can lead to the root cause. That doesn't mean the other Whys should not be looked at as they were an issue at some level.
The second half was a little more confusing with proportion of time in solving the problem. I understood the solution but now how it directly related to using the 5 whys analysis.
I think the idea was to spend a little bit of time/effort on each of the causes responsible for your issue. Over time, causes which need more fixing will crop up again and again and on average you'll spend the right amount of time on each one, without over-investing in any of them.
That's my interpretation, anyway: Imagine that you have 20 different issues related to training, but that you have the same conversation about training 20 times :)
I basically agree with you, but I think something positive about this video is its admonishment not to settle for one thing wrong. There are other factors and precursors that can be identified and fixed as well. Turn a root cause analysis into a root causeS analysis.
1.)Why is Eric Ries wrong?
Because he uses the 5 whys of root cause analysis
When all you have is a hammer, everything looks like a nail.
2.)Why is root cause wrong?
Because it is uses one of three logic frameworks.
3.)Why is one logic framework of deduction wrong?
In simple JAPANESE manufacturing environments,
deduction works.
In complex, chaotic environments need induction, abduction,
deduction and combinations of all three.
4.)Why are simple 'explanations' wrong?
Flawed safety process or entire 'safety culture' to blame?
Rise of the British empire or fall of the Roman empire?
5.)Why is the 'blame the process' wrong?
Mutual feedback loops between team, person, process and
technology. Technology includes software which is probabilistic.
Because it is 'the system of medical care'
6.)Why is the 'system of medical care' wrong?
Assumes you become healthy by taking pills. The more pills,
the better. The more root cause anomalies the better.
7.)Why is 'finding faults' wrong?
http://thinkexist.com/quotation/we_can-t_solve_problems_by_u...http://litemind.com/problem-definition/
Because “We can't solve problems by using the same kind of
thinking we used when we created them.”
5timewrong at workgold dot 33mail dot com
Tony's paradox on what happens when something has benn 'screwed':
replace quote of "When all you have is a hammer, everything looks like
a nail" with
When all you have is a screwdriver, everything looks like a screw,
but you can't tell if you are TIGHTENING the screws (on yourself) and
making the problem worse or loosening the screws.
PPS. start the flame war! rise and fall of the JAPAN manufacturing empire. SONY will eventually go bankrupt.
too many nitpicking fault finders and little creativity
in the big corp HQ in earthquake prone Tokyo. All the
factories clustered in Thailand (how convenient for Japanese
male execs to go!) which is flooded.
PS. How do I solve problems? I use the FIVE WHO.
I take the strangest assortment I can find. Throw them
together in a 'party' and then induce/abduce the answer.
Since 'birds of a feather' flock together, the 'corporate
dodo bird' is doomed to extinction (to mix metaphors).
There are many people who want to have power and control, but don't have the skills or experience to do anything concrete and exceptional. There is an entire management advice industry around finding tools and psychological tricks which allow those people to appear high-minded, visionary, and strategic. Eric Ries may not be one of these people, but his 5-why's lecture presents one of those tools. Anyone managing a team of ditch diggers needs some hard-to-criticize collection of platitudes which can be uttered to avoid either joining the diggers and/or being identified as completely useless.
1.)Why is Eric Ries wrong?
Because he uses the 5 whys of root cause analysis
When all you have is a hammer, everything looks like a nail.
2.)Why is root cause wrong?
Because it is uses one of three logic frameworks.
3.)Why is one logic framework of deduction wrong?
In simple JAPANESE manufacturing environments,
deduction works.
In complex, chaotic environments need induction, abduction,
deduction and combinations of all three.
4.)Why are simple 'explanations' wrong?
Flawed safety process or entire 'safety culture' to blame?
Rise of the British empire or fall of the Roman empire?
5.)Why is the 'blame the process' wrong?
Mutual feedback loops between team, person, process and
technology. Technology includes software which is probabilistic.
Because it is 'the system of medical care'
6.)Why is the 'system of medical care' wrong?
Assumes you become healthy by taking pills. The more pills,
the better. The more root cause anomalies the better.
7.)Why is 'finding faults' wrong?
http://thinkexist.com/quotation/we_can-t_solve_problems_by_u...http://litemind.com/problem-definition/
Because “We can't solve problems by using the same kind of
thinking we used when we created them.”
5timewrong at workgold dot 33mail dot com
Tony's paradox on what happens when something has benn 'screwed':
replace quote of "When all you have is a hammer, everything looks like
a nail" with
When all you have is a screwdriver, everything looks like a screw,
but you can't tell if you are TIGHTENING the screws (on yourself) and
making the problem worse or loosening the screws.
PPS. start the flame war! rise and fall of the JAPAN manufacturing empire. SONY will eventually go bankrupt.
too many nitpicking fault finders and little creativity
in the big corp HQ in earthquake prone Tokyo. All the
factories clustered in Thailand (how convenient for Japanese
male execs to go!) which is flooded.
PS. How do I solve problems? I use the FIVE WHO.
I take the strangest assortment I can find. Throw them
together in a 'party' and then induce/abduce the answer.
Since 'birds of a feather' flock together, the 'corporate
dodo bird' is doomed to extinction (to mix metaphors).
