Jeff Bezos and Root Cause Analysis | Hacker News Reader

Jeff Bezos and Root Cause Analysis

shmula.com

61 pointsAnon8422 comments

Bezos spoke at Startup School last year, and I think a lot of people were struck by how aware he was about very technical details at Amazon (Web Services, specifically). What impressed me most, however, was that when one of his employees gave a waffly non-answer to a question from the audience, he called him on it (subtly and politely), and made the guy commit to a real answer to the question...and made him personally responsible for it (with a comment along the lines of, "You can email him for that information and he'll get it to you.").

It was interesting to see, and it struck me as one of the things about Bezos that can explain how he has been so successful with a "bookstore on the web" when so many other "X on the web" concepts failed. You can't control every customer interaction in a company that size, but in that moment he established a precedent for that particular group of employees (probably folks who don't deal with customers a lot, since they were tech folks from AWS).

What I'm saying is that Bezos has certainly drunk some kind of obsessively customer-focused Kool-Aid, and I think I would take any opportunity I could to learn from him.

There are many parallels between Bezos and Jobs. Like you mentioned, Bezos is great at both macro- and micro-perspectives of his business.

Amazon didn't win because they were one of the first out of the gate, it's because Bezos has been obsessive (like Jobs) about the quality of his product.

That's interesting. The thing that stuck with me from that talk was when he was asked about Google App Engine. His answer was that Amazon has had a policy for years of not talking about competitors, not because they want to be evasive but because they don't want to take their focus off customers. Attention paid to what competitors are doing is attention not paid to what customers need next. I was deeply impressed by that.

Why did the associate damage his thumb? Because his thumb got caught in the conveyor.

Why did his thumb get caught in the conveyor? Because he was chasing his bag, which was on a running conveyor.

Why did he chase his bag? Because he placed his bag on the conveyor, but it then turned-on by surprise

Why didn't he hit the off button on the conveyor instead of chasing it? Because he wans't near the off button?

Why don't we have multiple off buttons so you're never far from one? That's expensive, let's buy some tables instead.

Great talk by Bezos on how the internet is more like electricity than the gold rush: http://www.ted.com/index.php/talks/jeff_bezos_on_the_next_we...

This is similar to his Startup School talk (http://www.omnisio.com/startupschool08/jeff-bezos), but perhaps offers a bit more perspective.

That's only four why's, and it doesn't address why the employee suddenly needed a table.

Which means it may not be the "root cause", either, and the offered "more tables" solution may not help.

I don't think there's anything particularly magical about the number five. We weren't there and that may have been adequately deep analysis; we don't have the information to tell.

Personally, I can't say I'm inclined to think "the employee needs a table" is likely to have any useful root cause that goes any deeper... "I need a table" is hardly some sort of exotic need.

The whole episode is recounted from memory, not a transcript, so it's probably off a little. The real why answer is 'because he didn't have anywhere else to place objects in the work area'. The table is one solution. You could go another layer deep and wonder why the work area was designed without a stable horizontal work surface. Maybe the job duties changed, maybe the designers didn't know. At the fundamental level though, you've discovered a good corrective action.

I commented about this on the linked site and it was deleted.

Adding a table strikes me distinctly as ignoring the root of the problem, which probably has more to do with safety standards and training. There has to be a more robust way to prevent accidents than luring people away from them.

So, ironically, this seems to be an example of asking too many questions, and we're not even at 5 yet.

The "5 whys" don't need to be exactly 5; it's just the name for the process of getting to the root cause of a problem.

Actually, "luring" people away from accidents is often a better way than strict training. "Don't jay-walk across the freeway" will only work when a viable (and safe) crossing is close by. Otherwise your users will simply ignore your training to make their lives easier.

True, and I'm all for that kind of thinking in addition to common sense precautions. Maybe that was the case and there were huge signs and training manuals and off buttons all over the place but coderr's scenario sounds more likely.

My larger point is that failure analysis is complicated and full of red herrings. Simplifying it to "five whys" (or four, or six) only creates false security.

I suspect that there is a long tail of root causes when it comes to accidents. So a little more analysis of a number of cases might have led to a better conclusion.

Has everyone forgotten this? http://business.timesonline.co.uk/tol/business/industry_sect...

Seems like Jeff could do with getting down to the distribution floor again!

I hadn't seen that. Amazon is a puzzle to me. They do so many things right, yet I keep hearing that it is not a good place to work.

Probably because they do the software stuff right, but a huge number of their employees are schlepping boxes in warehouses, or doing customer service?

Anyway, it's not an especially big deal to me that they would fire someone for taking too many sick days right before Christmas. If they disclose this to employees beforehand, they're likely to weed out people who tend to take sick days, whether for legitimate reasons or not.

I've also heard from software people that it isn't a good place to work. In fact, I've only heard it from software people. I haven't talked to or read blog posts from anyone who's worked in their warehouses.

Depends on where you are. "Front-facing" teams (e.g. site front-end and whatnot) tend to have a lot of sleepless nights when things blow up and a fix is immediately needed.

Software guys in the "back" tend to not live such a stressful existence, since there's far more time leeway for fixing things.

What kinds of complaints have you heard about them?

Kind of off-topic, but does Yahoo (or is it the publisher?) really think that interjecting ads in the middle of a narrative actually makes people want to click on the link? Do they really not know the least about human psychology? Most people who get to that point in the article have an inertial interest in finishing, and also a bias towards skimming over any contextual discontinuity. There are contrast effects that pull you towards them, and those that are obstacles people are happy to ignore. This is the second kind.

And, I should add, what works on television (ads in the middle) doesn't work in the same way for text. There is a natural ebb and flow of attention in a TV narrative,

I would guess they pay more attention to what works and what doesn't than to psychological theory or conjecture. It's easy for anyone to monitor what kind of ads perform better than others, and since ads are much of Yahoo's bread and butter, you can be sure they are paying attention.

I agree. So I should rephrase my question. Do these ads really perform better than footnote ads? I wouldn't be surprised if the higher clickthroughs are accidental (which, I am sure they measure for).

Reply on news.ycombinator.com