My First Big Screw-Up at Amazon

Six months into my Amazon tenure, I owned a vendor project: $20k for an automated data processing system that was supposed to make a manual, error-prone workflow disappear. The vendor's engineer knew, partway through the build, that what I had asked for wouldn't actually work. He built it anyway. When it failed in testing, his response was essentially, "I built what you asked for, not what would actually work." Fixing it would cost $40k more.

I was six months in, I had just doubled the cost of a failed project, and I was sitting in an office alone at 11pm trying to figure out what to do next.

The Night I Wrote the Paper

I didn't go home. Not for any dramatic reason, there just wasn't anywhere useful to be except in front of a blank document, working through what had happened. I wrote for several hours and produced a six-page paper. What happened, in plain language. The root cause, which I will get to in a moment. What it would cost to fix. What I would do differently.

The next morning I asked my manager, his manager, and a peer to read it with me in a glass-walled cube, no one really gets offices at Amazon, it works. Twenty minutes of silence while three people read something you wrote about your own failure is genuinely uncomfortable, especially when one of the readers has the organizational authority to end your employment. I sat there and waited.

At the end, my boss's boss looked up and said, "This is fantastic. You took responsibility, you correctly identified the root cause, and you have a plan. You just got through your first big screw-up at Amazon, and you handled it well."

That sentence changed the way I think about accountability.

What Accountability Actually Is

Accountability is not accepting blame. It is the practice of converting a failure into a diagnosis that the organization can learn from, and then standing behind that diagnosis in public.

The difference matters because accepting blame is passive. You raise your hand and say "that was me," and then everyone moves on, and nothing changes, and the same failure happens again six months later with a different set of actors. Diagnosis is active. You do the work of understanding what actually went wrong at the root, you write it down precisely enough that someone else can follow your reasoning, and you present it to people who can pressure-test it.

Amazon's six-pager culture works as well as it does because it forces that conversion in writing, in advance, before anyone is in a room together. When you write a narrative document about a failure before the meeting, you cannot hide behind a slide deck or a vague verbal summary. The act of writing complete sentences forces precision, and precision is where the real accountability lives.

The Root Cause I Had to Own

The root cause of my failure was not the vendor's decision to build something he knew wouldn't work, even though that was a real problem I had to deal with separately. The root cause was that I hadn't asked the right questions at the start of the engagement. I had assumed the vendor's engineer would tell me if my requirements were flawed. I had not created the conditions for that conversation to happen, I had not explicitly invited challenge, and I had not built a checkpoint into the process where we verified that what we were building would actually solve the problem.

The vendor behaved badly, and I fired them. But the system failure started with my choices, and I had to own that clearly enough that my own leadership could see I understood it.

There is a version of that paper where I write "the vendor failed to surface concerns about the requirements" and stop there. That version gets me through the meeting but teaches me nothing, and teaches the organization nothing. It's also not honest. The honest version is that I created a situation where a vendor had to choose between surfacing a problem that might cost him the contract, or quietly building what I asked and collecting his check. I hadn't made it safe or economically rational for him to tell me the truth early.

That's what I had to write down, and what I had to say out loud in that glass cube.

The Asymmetric Bet

When you're sitting alone at 11pm after a failure, there are two paths. One is to minimize: write the version of the story that makes you look as uninvolved as possible, spread the responsibility thin, and hope nobody digs deeper. The other is to diagnose: write the version that's actually true, own the part that belongs to you, and present it to people who can evaluate your reasoning.

The first path feels safer. It isn't. The version of events you construct to minimize your own role will be inconsistent in some detail, your leadership will notice, and you will have added a trust problem to the original performance problem. The second path feels like walking into a room where you might get fired, because it is. But the asymmetry is worth understanding: the worst case of the honest path is that you get fired for something you were probably going to get fired for anyway. The best case is that the failure becomes the moment your reputation as a leader is actually built.

My boss's boss wasn't impressed that I had failed. He was impressed that I had done the work to understand the failure precisely, and that I had the nerve to present that understanding in writing to people who might disagree with it. That's what he told me, those words, and I have thought about them at least a hundred times since.

What You Can Borrow From This

You don't need to work at Amazon to use a six-pager after a failure. The format is simple, and the real value isn't the format anyway, it's the discipline of writing the thing in advance.

Before your post-mortem meeting, write a document. Not slides, a document with complete sentences and paragraphs. Cover what happened in plain language, the root cause with enough precision that someone who wasn't there can follow your logic, the cost of the failure (in money, time, or trust), and what you would do differently. Print copies, paper copies so that they can’t be on their computers doing something else while reading it. Then sit in the room while they do.

The silence will be uncomfortable. That discomfort is the accountability working.

If your root cause section points entirely at other people or external factors, read it again. That's usually a sign you haven't gone one level deeper. Root causes almost always have a "what did I do or not do that allowed this to happen" component, and the document isn't finished until you've written that part honestly.

The Engineer

A word on the vendor: he built something he knew would fail because he prioritized getting paid over doing his job honestly. We ended the relationship, and I don't think that was a difficult call. But I've thought about him often when I'm evaluating people who work for me, because the question of what to do when you're building something that won't work is one that surfaces constantly, in engineering, in product, in operations, everywhere.

The people I trust most are the ones who surface the problem early, even when it's inconvenient, even when they're worried it'll cost them the contract or the goodwill or the approval. That instinct, to say "I need to tell you this isn't going to work before we go further," is something I look for explicitly, because it's the thing I failed to create conditions for in that vendor relationship.

I don't trust people who don't make mistakes. I trust people who handle mistakes the way that glass-cube morning required me to handle mine: with enough precision to understand what actually happened, and enough nerve to say it out loud.