A Life Engineered · A Life Engineered · Transcript & summary by WhipScribe
It turns vague promotion advice into six concrete habits, each backed by a specific story from inside Amazon's promotion process.
Tap a chapter to open that moment in the transcript; the link to it is copied for you.
“I hereby grant you the permission to do the things that someone at the next level would do.” Steve Huynh · at 3:51 — open in the transcript →
“Instead, focus follows a power law.” Steve Huynh · at 9:27 — open in the transcript →
Steve Huynh, who spent nearly 20 years at Amazon, was promoted four times to principal engineer and ran close to a thousand bar raiser interviews, argues that talent and hard work do not explain who rises fastest in tech. His six principles fall into two groups: how you prove you are ready, and how you spend your limited attention.
On proof, Huynh says promotion cases succeed on undeniable evidence of impact, not on effort. He tells engineers to decide how they will measure a project before starting it, and illustrates the point with a junior colleague whose one-hour A/B test showed a tiny search-page text fix was worth about $2 million a year, earning him an immediate promotion. Evidence also has to be packaged: a one-line headline, like a mentor's claim of taking Prime Video from four countries to nearly 200 in a year, lets a committee check details instead of debating whether you belong. Huynh adds that most next-level behaviour needs no permission at all.
On attention, Huynh warns that reaching upward while current-level work slips is how senior engineers at Amazon miss principal. His fix is to meet the minimum bar at your level, drop optional work, and pick one large, visible project over many medium ones, because committees cannot fairly compare scattered contributions. He says focus follows a power law, so a second project during idle time cuts effectiveness far more than half. A short plug for his Top Tier coaching program sits in the middle.
Steve Huynh, a former Amazon principal engineer, lists six principles: promotion requires evidence of impact; act like the next level without waiting for permission; keep performance high at your current level; focus on fewer but bigger projects; develop a punchy one-line headline for your promotion case; and avoid picking up extra projects when your main one is temporarily blocked.
Steve Huynh describes a junior engineer friend who noticed a low-stock message was missing from Amazon's search results page. Instead of simply adding the text and closing the ticket, he spent about an hour setting up an A/B test first. The test showed the fix was responsible for roughly $2 million in additional annual sales, which won him Amazon's Just Do It Award and an immediate promotion.
Steve Huynh says almost nothing a next-level engineer does requires permission. Exceptions exist, such as junior engineers not interviewing senior candidates or non-managers not approving expenses, but he says there is no floating tag over your head showing your level. He learned this when a long, careful email to a more senior engineer outside his team got a one-word reply: okay.
Steve Huynh says senior engineers aiming for principal often stop doing their senior-scoped work and spend their time on non-coding, principal-style work. Because their performance review still measures the senior role, they get low to average ratings and are not considered for principal. His advice is to find the minimum threshold at your current level, reject optional work, and use the freed space for next-level work.
Steve Huynh says promotion committees do fuzzy math, adding up contributions against thresholds. Contributions from one project compare apples to apples, while work spread across many projects forces an apples-to-oranges comparison the committee lacks information for, so the easy outcome is to pass and cite unclear impact. When reorganized into Prime Video as a senior engineer, Huynh chose a high-visibility project with a tight deadline over a team with many medium projects and legacy systems.
Steve Huynh's headline was that he launched Amazon's multi-billion-dollar live sports initiative by reshaping Prime Video's core architecture, updating hundreds of systems against a deadline that could not move. A senior principal mentor told him to write such a headline; the mentor's own was launching Amazon's first truly global service, taking Prime Video from four countries to nearly 200 in a year.
Steve Huynh argues that splitting time between two projects does not make you 50% effective on each; it is more like 15% on both, and worse with three or more. So when a main project is blocked waiting on someone, he advises against starting a second one and recommends thinking ahead on the primary project instead, even if that work turns out to be throwaway.
Our own transcript of the public episode, with a timestamp about every 90 seconds. Tap a timestamp or the link button on a paragraph to copy a link that opens this page there.
0:00I think the real reason that the top 1% of people in tech advance so much faster than their peers comes down to six specific principles. Over my nearly 20 years at Amazon, I was promoted four times, eventually being made a principal engineer, a title that only about 1% of Amazon engineers achieve. I also conducted nearly a thousand bar raiser interviews where I determined whether to extend offers and at what level. I was talented and I worked hard, but sadly that's not enough. The truth is, if I didn't understand these six principles, I honestly think I would have followed the same bad advice I hear from so many other YouTube videos and stayed stuck as a mid-level engineer watching all my colleagues get promoted over me.
0:41Principle number one, being promotable requires evidence. Excelling as a mid-level engineer only proves you're a great mid-level engineer. To jump up, you need to leave signs your manager can point at and prove that you're more than just performing as a top-level mid. At Amazon, there's an award called the Just Do It Award. You'd get CEO recognition and receive a Nike shoe from Jeff Bezos himself on stage. My friend, who was a junior engineer at the time, won it. He got an immediate promotion for his work. So what massive thing did he do? Actually, it was really small. He noticed that a single message was missing on the Amazon search results page. It was a text that read, by now there's only three more left in stock. The obvious move was to
1:23just add the missing string, close the ticket, and move on to the next task. The big insight came before he did the work. He asked, how will I know the impact? I need evidence. It only took an hour to set up an A-B test, but fixing this single missing string was responsible for an additional $2 million of annual sales. He did the work, but the critical move was to generate evidence. That was the tangible material that made his promotion a slam dunk. The promotions that sail through the process have clear, unambiguous evidence of impact that's undeniable. The ones that stall are the ones that highlight how hard the person worked. We all can't do million-dollar bug fixes, but we need to be able to point to impactful results. Before you start a big piece of work, ask yourself, how will you measure the impact?
2:07What's the graph that you'll be able to point to that goes up and to the right, based off of your work? If it's not measurable, or you'll only get poor indirect measurements, think twice about whether the project, as it's currently framed, is worth doing. Don't go do a bunch of great work and then try to gather evidence after the fact. But if you really want to move up fast, you need principle number two. Don't wait for permission to behave like the next level. The fastest way to get promoted is to act like you're already there. It's like duck typing. If it walks like a duck and talks like a duck, you can treat it like a duck without loss of generality. When I wanted to be a senior engineer,
2:41I was blocked on an issue that required work of someone else outside of my team. I didn't want to bother him because I didn't know him and he was a level above me. So I went to my manager. My manager said, dude, just let him know that we need this by Monday. So I sent him a really lengthy email that described the context, why we needed it, and a ton of other small details. Could you please finish this work by Monday? The response was one word. okay. It was that moment I realized that I don't need permission to act like a senior engineer. I often tell my clients that there's not a floating tag on top of your head with your title and level. At companies like Meta, it's actually quite difficult
3:17to know what level people are, and they still get stuff done just fine. There are things that require permission or that you're forbidden to do based off of your level. If you're a junior engineer, you can't interview candidates for senior positions. You can't approve expense reports if you're not a manager. But there are surprisingly few things you need to ask for permission for at work. An exercise I have my clients do is to consider the work that you're currently doing and ask yourself, how would someone at the next level complete the same work? How would someone two levels above me do this work? It turns out that virtually none of those differences require permission. If you're still a bit apprehensive about it,
3:51I'll give you permission. I hereby grant you the permission to do the things that someone at the next level would do. There you go. If you need help growing your career, consider my program top tier. The premise is simple. Work closely with people one to three levels above you to improve your performance and get promoted fast. We work with engineers and scientists from all of the big tech companies, like OpenAI, Amazon, and Meta, along with engineers from non-tech industries and smaller companies. If you want help getting an exceeds performance rating or feel stalled at your current career, scan the QR code here or click the link in the description to learn more. Principle number three, maintain high performance at your current level.
4:29If you take on next level work and your current responsibilities slip, you're showing your manager you can't handle the extra scope that's required. I started at Amazon as a support engineer. It was a highly demanding role since I was responsible for keeping many big backend systems up and running. I had a pager and I'd get paged hundreds of times a week. The workload was terrible, but I wanted more scope. I wanted to become a software developer. So while I was carrying that pager, I started prepping for interviews. This was way before LeetCode. And so I was doing all of these coding problems, and I was taking on small amounts of extra dev work, like little features and tooling the developers didn't have time to do.
5:08But I couldn't neglect my support engineer responsibilities. I was interviewing internally at the company, and if they saw that I had low performance as a support engineer, they wouldn't take a chance on me as a software engineer. At Amazon, when senior engineers wanna become principals, they start doing all of this work that doesn't involve coding. When performance review time comes around, they get low to average ratings because performance is determined by their senior scoped work. By trying to do only principal level work, they aren't considered for principal. If you're charting the next level, you need to find a way to minimize your at-level work. Reject all optional work and make sure that you're generating
5:45evidence of impact at your current level. Find out what the minimum thresholds are and do only this. This should maximize the space to do the next level work. Now that you have all of that space, you're ready to move on to principle number four. Focus on fewer but bigger things. Even if you've freed up time, you don't want to work on everything that could get you promoted. Project selection is critical. You need to be incredibly selective with the projects that you do accept. When I was re-orged into the Prime Video organization, I was a senior engineer. I was given two choices. I could work on a team that recently had their principal engineer leave, or I could work on a big, complicated project with a ton of visibility, but also an insane deadline.
6:26The team that had the recent departure had principle level scope, but it came in the form of many medium-sized projects and a lot of legacy systems that needed to be maintained. I decided to go with the scary project with a ton of visibility. The reason is that it's so much easier to make a case for high performance or promotion when there's fewer, but really solid things to consider. When the people that will decide your promotion get together, they're going to have to do a lot of fuzzy math. They're going to add up your contributions and determine if they meet certain thresholds. If the contributions come from the same project, the math is easy because they can do the math apples to apples.
7:02If the contributions come from many projects, they'll have to do an apples to oranges comparison because the projects are different. They're gonna run into issues because they won't have enough information to make that comparison fairly. And so the easiest move for them is to pass on your promotion and cite unclear impact. It's just too much work and the process isn't set up for it. Once you've selected your project, you're ready for principle number five, develop a punchy headline for your promotion. You have to make it easy for people to understand that you're operating at the next level. A senior principal I worked with was mentoring me to help me get promoted. He told me to develop a headline for
7:38my promotion, something that immediately communicated that I was already operating at that level. So I asked him, what was your headline to get to senior principal? Without skipping a beat, he said, I launched Amazon's first truly global service. I developed an approach to take Prime Video from four countries to nearly 200 countries in a year. And it's a pattern that other lines of business within Amazon copied to also launch globally. When he said that, I instantly understood what level he was operating at. He didn't go into the details of how complicated it was and what exactly he did. Those details existed, of course, and there was a lot to it, but the headline made it really clear. I imagine the promotion committee went from wondering
8:20if he deserved the promotion to verifying the details of his contribution. My headline for promotion was, I launched Amazon's multi-billion dollar live sports initiative by fundamentally reshaping Prime Video's core architectures, which required updating hundreds of systems with an insanely tight deadline that couldn't move. If you want to get promoted fast, you need to make it really easy for people to understand that you're operating at the next level. If you're having trouble, take a look at the promotion announcement emails from past promotions at your company. Those will typically have short paragraphs on their contributions and achievements. Take those and see if you can turn them into one or two short sentences. Which leads
8:57us to principle number six. Avoid taking on more projects when they're slack. The biggest risk to your promotion is spreading yourself too thin. You might be working on your big project and now you need something that won't be available until next week. You might be tempted to start on a different project, but that would be a terrible mistake because next week is going to come and all of a sudden you have two projects in flight, watering down your potential impact. It's not that you're now 50% effective on project one and 50% effective on project two. Instead, focus follows a power law. It's more like you're 15% effective on both of those projects. The numbers get even worse if you're juggling
9:36three or more things. To take advantage of the crazy gains here, you need to have singular focus and not get distracted. This means that you need to be okay with slack. Instead of taking on a second project, it's a much better idea to think ahead of the work that you need to do on the primary project. You're going to feel a lot of resistance to this because this work isn't well-defined, and it might be throwaway work, but the risk of wasted effort pales in comparison to the guaranteed loss in effectiveness you'll experience if you split your focus. For more ideas on what the world's greatest engineers actually do differently, watch this video next.