High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / evaluation

Published · transcript-backed

Ethan Evans: evaluation

14 Jan 2024 Lenny's Podcast Taking control of your career | Ethan Evans (Amazon)

“Because basically it was a reaction I think to Microsoft where they felt Microsoft always talked about what was coming and then pushed the dates back.”

— Ethan Evans

Source trail

Everything needed to verify it.

Speaker
Ethan Evans
Attribution
Verified speaker
Claim type
evaluation
Recorded
14 Jan 2024
Publisher
Lenny's Podcast

Transcript context

…Along the lines of lessons, last question here, what's something that you took away from the way you approached it that you should have changed or should have done differently, that you've done differently since? Obviously don't... You mentioned this idea of don't promise a date that you're not that certain you're going to hit. I guess is there anything along those lines? I have two things here. First, Amazon loved in the past, they loved surprise launches. They love the idea of we're going to be quiet, quiet, quiet. Because basically it was a reaction I think to Microsoft where they felt Microsoft always talked about what was coming and then pushed the dates back. And so there was this whole thing about vaporware. And Amazon wanted to be the other way, which is we won't say anything and then it will just be there. The problem I came to say is the biggest thing I learned with surprise launches is that you're surprised by what doesn't work. And so I shifted the approach to let's do a lot of beta testing. We always, even if others don't agree quite and say, "You're right, we're not going to have a surprise launch." Some of our beta testers, even if they sign NDAs are going to leak. And that's a better outcome than launching something that doesn't work. That's one lesson. The other lesson is this thing that broke in front of Jeff Bezos, ultimately it was a new college graduate engineer who wrote that code. And he had been left alone to write part of our user interface, but he had written it in such a way that it didn't scale. Now we didn't give him any help or oversight. We left him on his own, because we were busy focusing on other pieces of the problem. And shortly after the disaster, he left the company. And the mistake I made was not reaching out to him and really reassuring him of, "Yes, you wrote the bug, but that's not on you. The system failed you and we don't see you. Bugs happen." So the thing I regret in this whole thing is not realizing that even though no one in the team ever yelled at him or whatever, he knew it was his bug, and he obviously saw me and others sort of taking a beating. And so he left, and I wish he hadn't done that. And I wish more than that I had stepped in. I didn't realize what he was feeling. It's interesting, the lesson there isn't catch that person sooner, and notice these links in the chain that may break. But it's more just be there for that human that have this challenge, that people may not be focusing on.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence