Don't be a dick.
1. What is wrong with a suit?
2. He cofounded IMVU and had a number of failures before that, he has plenty of time in the trenches to back up his assertions.
3. A short 3 minute video is hardly the place to go into depth perhaps a blog post? [1].
4. Huh? Saying it doesn't make it so, perhaps some explanation.
5. See #2
[1] http://www.startuplessonslearned.com/2009/07/how-to-conduct-...
ps I didn't down vote you.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.