Early in my career, I spent a lot of time tuning two numbers.

The first number lived on the load-balancer. Amazon gets far more traffic than any one computer could handle, so behind the website there’s a fleet of them. And something has to decide which computer gets which incoming request, to balance the load across the computers. The first number that needed tuning was a setting for how many requests the load-balancer was allowed to send to any one computer at the same time.

The second number lived on the computers themselves. Each computer had a fixed number of threads. Think of a thread as a worker at a counter taking an order. It takes one request, does the work to answer it, hands back the result, and only then can it take the next order. A computer with twenty threads has twenty of these workers that can do jobs like rendering part of the website or calculating the taxes on your order.

Those two numbers had to marry.

If the load-balancer sent more requests than a computer had threads to handle them, the extra requests were dropped. The person on the other end got an error.

If you gave each computer too many threads, that wasn’t good either. Every thread took up memory and attention regardless of whether it was busy or sitting idle, waiting for something to do. Think about the waste of resources at a restaurant with ten waiters per table.

What I was tuning was the concurrency number. To set the numbers correctly, I had to ask myself the question:

How much work could this thing do at once before it starts to break?

You and I also have a concurrency number.

We found that number at Amazon by creating synthetic traffic to a single computer and experimenting with the number of threads until we found an optimal number that maximized the throughput. (If you’re nerdy and curious, we conducted a binary search.)

The sad thing is that we can’t find an optimal concurrency number for ourselves in the same way. We don’t have the time or the energy to do fake work. But more importantly, the nature of our work is too varied.

A load-balancer only works because every request is similar to every other request. The work on your plate doesn’t look like that. Some work is due this week, and some is due whenever. Some things are really big, and some things are really small. Some things you know how to do, some things you have to learn, and some things depend on others.

That’s the fundamental difference between scaling a system and scaling ourselves. At Amazon, to maximize throughput, to get the most requests through, we needed to increase concurrency.

That’s the wrong goal for a person. For us, if we want to maximize throughput, we need to minimize concurrency.

Why Fewer Is Faster

There are two things that are true of your work that aren’t true of the requests hitting those Amazon computers.

The first is that your work is varied, and context-switching, or switching between varied work, is expensive. A computer swapping between two identical requests can be highly optimized. In contrast, you will lose a lot by moving from a document that you’re writing, to a difficult bug, to chasing down and clarifying requirements.

Each switch means putting one thing down, picking up the state of another, and remembering where you left off. The more things you have in flight, the more of your day goes to the switching cost instead of the work. Past a certain point, adding one more item, no matter how small, makes everything on the list slow to a halt, including the tiny item you just added.

The second is that your work has priority. Every request that hit the load-balancer was just as important as any other request. Nothing on your plate is like that. One piece of work might matter more than the rest of the list combined, and a week where twelve small things are completed but one big thing is left undone is still a bad week. For a human, throughput is about whether the thing that mattered got done, not about how many things got done.

Put the context-switching cost and prioritization risk together, and the optimal approach for a human looks much different than the optimal approach for a load-balancer.

My optimal approach for a person has two parts, and each one addresses one of those problems. First, we want to pick a single piece of high-priority, high-impact work and protect it, so that whatever else happens, the thing that matters gets done. Second, we want to cut the number of things in flight down to as few as we can stand, so the switching costs are minimized. We want one thing at the top, and as little as possible underneath it.

The Three Buckets

If you’d like to see whether this kind of optimization helps you, follow this exercise. Start with your priority. Take everything you could choose to work on between now and the end of the year. Leave out the obligations and anything else you’d get in trouble for skipping, because those aren’t choices. List the work itself, not the outcome you’re hoping it will produce. Getting promoted doesn’t go on the list; the work that earns the promotion does. If there are more than, say, ten items, group related work together until the list is manageable.

From what’s left, pick one item for the first bucket. It’s the piece of work that, if you finished it, you’d look back on this year with pride. Everything else goes into one of two buckets: “Maybe now” for the things you’d like to do this year, and “Not now” for the things you won’t get to. If you’re anything like me, most of the items will land in the middle.

Now we cut the switching cost. Every item in the “Maybe now” bucket is a tax on your highest priority. It’s an idle worker holding memory, whether or not it ever gets utilized. For each item, compare it to your priority.

Ask yourself: When I look back on this year, would I give up the one thing for this?

Then ask two more questions: What would happen if I didn’t do this at all this year? What is the real impact? If the honest answer is “Not much,” it moves to the third bucket.

Repeat this until you’ve gone through every item.

If nothing has moved, be honest with yourself. A full middle bucket means you believe everything on it matters this year. It doesn’t. Most of it is work you’d like to have done, which is a different thing from work that changes anything. Give yourself permission to skip what isn’t going to matter.

Hopefully, we’ve lowered the concurrency of your life a little and raised the chances that you’ll land something truly special by the end of the year.

At Amazon, the load-balancer and the threads had to marry. Why? Because a computer will happily accept more work than it can finish.

It’s the same with you. But unlike the computer, which will just as happily drop those extra requests, every extra item you add to your plate puts at risk the one piece of work that matters more than everything else combined.

How much can you hold before it breaks? Don’t wait to find out. Chances are, it is less than you’re holding right now.

The most important number is one. Your one priority item, the thing that really matters. Don’t put it at risk.

Enjoyed this week’s newsletter? Give it a ❤️ so I know to write similar ones in the future.

Subscribe now

I was listening to Jimmy Carr on a podcast recently, and something he said stuck with me:

Your life does not need to be easier. It needs to be simpler. Your system is designed to handle stress and challenge but not complication. You probably handle hard things pretty well but feel overwhelmed when they become messy. Do not attribute to difficulty that which can be explained by complexity.

For much of my life I’ve conflated difficulty and complexity.

Early in my career, I was building a system that processed work in batches.

Five hundred items would arrive together in a request, and my task was to decide what happened when something went wrong. There were so many failure modes.

Sometimes the batch request itself was bad. Sometimes a single item out of 500 failed, which raised the question of what to do with the 499 that succeeded. Retrying everything meant redoing work that had already been done. Retrying only the failure meant tracking partial completion forever, which added so much more scope to the project. My head was swimming in edge cases.

The design that I finally shipped did almost nothing. When a batch hit trouble, the system marked it as stalled, then it generated a report and alerted a human, who would take it from there.

Confusing hard and difficult is an issue. Why? Because the two types of problems should be handled in opposite ways.

When something is hard, putting in more effort is the right move. When something is complex, more effort will merely compound the problem.

When we describe something as being “too hard,” more often than not, we’re talking about something that is too complicated.

Put those two properties on their own axes, and we get an interesting spread:

The top left is the grind quadrant. The solution is to put in more work. You can win by doing more. It may be uncomfortable, but it’s not confusing.

The bottom right corner is interesting. Navigating a crowded sidewalk requires you to predict what a dozen strangers are going to do all at once, and you can do it without a single thought.

The top right is where burnout happens if we keep trying harder.

I spent almost twenty years building software at Amazon, and the biggest lesson about scaling is captured in Carr’s quote. Systems scale when each step stays simple. The services that can help Amazon survive a Black Friday are the ones that aren’t complicated. Each component should do only one small but important thing.

Complexity is the enemy of scale.

The same goes with our careers. We should grow our careers by putting in hard work but also by minimizing the number of things we do at any given time.

When we’re overwhelmed, we wish life were easier. But overwhelm comes from too many things that depend on too many other things in a complicated web where you don’t know where to begin, not from the difficulty of any one item.

This week’s exercise is to draw your own graph. Draw two axes on a piece of paper: easy to hard and simple to complex. Plot everything at work and in life that’s weighing on you. If you’re unsure where something goes, ask yourself a question: If I just kept showing up and doing the work, would it eventually get done? If your answer is yes, it’s hard. If more work wouldn’t make a dent, or the situation keeps shifting underneath you, it’s probably complex.

The stuff on the left of the graph can be solved with effort, so give it effort.

The stuff on the right is different. The goal there is to stop working harder.

Start by asking whether it can be made simpler. It usually can, and the approach often looks like my batch system: lower your ambition for what the solution has to cover. Handle the common cases well, and let a person or a rule catch the rest.

However, some things can’t be made simpler. Raising a teenager will never have fewer moving parts. Neither will caring for an aging parent. For those, the honest move is acceptance. Extra effort won’t untangle them. The best you can do is respond to what comes and let go of the idea that there’s a neat solution.

The next time something feels too hard, take a second look. If it’s hard, push. If it’s complex, simplify what you can and make peace with what you can’t.

Sometimes the best advice is simple.

Enjoyed this week’s newsletter? Give it a ❤️ so I know to write similar ones in the future.

Tech Salary Negotiation Masterclass | Colin Lernell

Most engineers think their pay reflects their performance. Colin Lernell watched the worst performer on his team earn $120K more than the best, and that one observation changed everything.

Now one of the world’s foremost experts in tech salary negotiation, he sits down with me to break down the secret menu that most candidates don’t even know exists, why you don’t need a competing offer to negotiate, and how to get one of those $2M to $7M AI compensation packages even if you’re not an AI expert.

I found out last week that I lost hundreds of thousands of dollars this year. Nobody stole it, and I’m not talking about a bad investment.

I lost it by ignoring advice so basic that I’m a bit embarrassed to write it in this newsletter.

Here’s what happened: I was planning my content strategy for the rest of the year, and I realized I couldn’t answer a simple question: Which of my videos has led to the most sales?

I signed up for an attribution service to answer it going forward, but in the meantime I asked my team to run a one-off report against the back catalog.

When the report came back, I thought we’d made a reporting error.

A video I had written off as a failure, one that pulled only twenty-something thousand views, had driven about $75,000 in sales. Meanwhile, videos I was proud of, videos with hundreds of thousands of views, had driven almost nothing.

I remember vividly the day I published that “failed” video. I remember the sinking feeling in my sto…

Read more

Getting better by doing less.

I just got back from a business conference where I did something unusual for me: I barely took notes.

Most conferences bury you in information. You fly home with dozens of pages of cryptic handwritten notes, a laundry list of new tactics, and the vague guilt of knowing you won’t implement any of them.

This time, I decided it would be better to leave with fewer commitments than I arrived with.

Here are five things I’m thinking about this week:

1. Reduced by Rick Rubin

The best session I attended was titled “(Re)ducer.” It was built around a detail from music producer Rick Rubin’s career. On his first album credit, LL Cool J’s Radio, the liner notes read “Reduced by Rick Rubin,” instead of “produced.”

Rubin’s job was to strip away everything that obscured the music, not to add more. He explained…

Read more

He breaks down how to spot manipulation, stop dumping problems on your manager, and ask for a raise or promotion without sounding selfish, then admits something most executives won't: everyone lies at work sometimes, and pretending otherwise is its own trap.

Guest Links:

• https://www.ethanevans.com/

• Level Up Newsletter

  Top weekly newsletter to make career breakthroughs with AI-proof leadership skills.

  By Ethan Evans

Read more

This is the last of the three pieces I pulled from the archive for this trip. Normal service resumes next week, once I’m back. This one is a reader favorite on getting up to speed fast in a new role.

You’re eager to make an immediate impact.

You’ve just started a new role or a challenging project, ready to dive in and prove your worth.

But instead of hitting the ground running, a lack of understanding is holding you back. Everyone around you is speaking fluently in what might as well be a different language. While you’re nodding along, you secretly grasp maybe five percent of what is being said. You feel like you should be understanding closer to eighty percent by now.

You realize you now have two full time jobs. There is the work you were brought in to do, and there is the task of getting up to speed. Both feel like they are falling further behind with every passing moment of confusion. If this sounds familiar, you are not alone. I have been there.

After nearly two decades at Amazon, operating as a Principal Engineer, often parachuting into complex, high stakes projects, I’ve developed a system to cut through this chaos. In this article, I’ll share with you that exact framework to help you get up to speed unbelievably fast.

The New Guy Trap

How does this scenario unfold?

If you are like most people, your first instinct is to gather information. You ask for every document, every link, every resource available. Soon, you face a digital mountain of material to read and videos to watch, often more than you can consume during working hours. You start at the beginning, only to find that much of what you are reviewing is outdated, irrelevant, or not applicable to what you need to understand. You realize the critical information, the context you need, is not written down.

Your next step is to schedule meetings with colleagues. After fifteen minutes of introductions, the next fifteen minutes become an avalanche of details. You try to capture notes, filled with jargon and acronyms, when someone knocks on the door for the next meeting. You attempt to schedule more time, but colleagues are busy and their availability is limited.

You then return to your notes. They are a jumbled collection of three and four letter acronyms, specialized terms, and sentence fragments. You remember understanding something about it when you wrote it down, but looking at it now, it often feels more confusing than before. “Fine, I’ll look it up myself,” you say to yourself. But you find that answering one basic question such as “What does this mean?” only leads to two more questions. As your list of unanswered questions grows, so does that feeling of falling behind.

Not All Knowledge Is Created Equal

So how do you deal with this avalanche of information and your own jumbled notes? There are only so many hours in the day. What you need is a reliable way to sort through the incoming details and filter for the things that truly matter. But how can you do that when you do not even know enough to determine what might be important?

This brings me to my core underlying principle. Not all knowledge you encounter is equally useful, especially when you are trying to get up to speed quickly. Based on the type of information coming in, you need to treat it differently. The key is to begin bucketing the information for your notes as it arrives. Let’s focus on categorizing information by its type. There are three primary buckets here. Information can be a fact, details about a process, or a concept.

• Facts are true statements that describe something.

• Process information explains how something is done.

• Concepts are ideas, and importantly, how those ideas relate to other ideas.

It is a big mistake to treat all these types of knowledge the same. Your approach to learning and retaining them should differ based on their category.

Here Are The Facts

Let's begin with Facts. When it comes to factual information, it is useful to make another distinction. There are facts that need to be in your working memory for you to function effectively, and there are facts that you can simply reference when needed. I remember this distinction clearly from my first job at Amazon working on the "Search Inside the Book" feature around 2006. This feature allowed customers to search and browse the content of physical books online. Certain facts needed to be part of our team's working memory. For example:

• The core purpose of Search Inside the Book (or SITB as we called it internally) was to enhance book discovery and improve customer experience.

• All book content processed for SITB had to be associated with an Amazon Standard Identification Number (ASIN).

• The content processing pipeline involved several key stages: scanning book pages, optical character recognition (OCR) to extract text, and then indexing that text for search.

• We had a service level agreement (SLA) for how quickly new book content should appear in SITB after publication.

These were fundamental principles and operational realities we needed to know to do our jobs and communicate effectively. Then, there was a vast amount of factual information that we could, and should, reference when needed. These might include:

• The complete list of specific error codes generated by our internal processing platform and their detailed troubleshooting guides.

• The exact specifications for image quality and format required from publishers or scanning operations.

• The comprehensive list of all publisher series codes that were flagged for special processing rules.

• The specific server names or configuration details for the different environments like beta or production.

You would not need to memorize every single error code or server name. Knowing where our team's documentation was and how to look up these details was what mattered. For the facts that do need to be in your working memory, the key is consistent exposure and understanding their direct relevance to your daily tasks.

Tip: For those essential working memory facts, create a running list on the first page of your project notebook or a prominent digital note. Review it for a few minutes periodically. For reference facts, do not just assume you will find them again. Maintain a simple, personal directory of links to key documents, dashboards, or contact people. This habit of actively sorting and organizing facts as you learn them will pay off immensely in how quickly you feel competent.

Process: Learning the How-To

The second bucket of knowledge is Process Information. This type of knowledge is all about the HOW. It explains how you bill clients, how you check in code, or how you troubleshoot customer issues.

Now, this is different from how you might handle facts. With processes, it generally does not make sense to try and write down every single step in exhaustive detail and review it like you would a list of facts. When you are new to a team or project, the existing process should ideally already be developed and documented, perhaps as a standard operating procedure (SOP), a playbook, or a similar guide. If such documentation is missing or inadequate, as the new person, it is typically not your immediate job to create it from scratch. Your primary goal is to learn the current process, warts and all, mainly through doing.

Of course, if your role specifically includes creating or refining processes, that is a valid goal. However, you can only contribute effectively to that kind of work once you are genuinely up to speed on the existing situation, something I will discuss more later.

I saw this principle of running through procedure play out many times at Amazon. For example, software developers always carried a pager. If a critical system went down, what we called a sev-2, the on call engineer would get paged. If there was a major issue, like the Amazon website not accepting orders, it was a sev-1. A sev-1 meant pretty much everyone needed to join a call to resolve the problem quickly.

Most teams had some sort of playbook or published SOPs for people who were on call. Having these SOPs was helpful as a reference. I recall this very well from my time on call for Search Inside the Book. Our playbooks detailed procedures for common issues, like when new book content failed to appear on the website. But it was not until I was paged in the middle of the night for that exact problem, and had to personally trace the data through our content pipeline under pressure, that the deeper lessons emerged.

That intense experience didn’t just teach me how to fix that one stall. It provided real knowledge into the types of things that can cause data pipelines to break. It highlighted how to design more effective monitors and gave me a framework for how to proactively investigate and uncover potential issues before they escalated into outages. This hands on work went further than simply referencing any written procedures. Reading about how to handle a critical event is one thing. Experiencing it and working through the steps yourself is how procedural knowledge sticks.

Tip: Instead of just asking colleagues to explain a process, ask if they can shadow you or pair with you while you perform it for the first time. This active participation is the fastest way to get up to speed. For instance, a new software engineer eager to get on call quickly will find most teammates are very willing to shadow them during their first few on call shifts, providing real-time guidance and a safety net. This accelerates learning and builds confidence much faster than passive observation (and will get them a lot of brownie points with the team).

Concepts: The Real Learning Accelerator

We have covered Facts, which describe things, and Processes, which explain how things are done. Now we arrive at the third, and arguably most powerful, type of knowledge: Conceptual Information.

Concepts are ideas and importantly, how those ideas relate to other ideas. While facts give you the 'what' and processes give you the 'how,' concepts give you the 'why.' Understanding conceptual information is about building a mental model of the system, the business, or the problem domain. It is about seeing the bigger picture and the underlying principles at play. How do you actively build this crucial conceptual understanding, especially when everything is new and feels complex? The key to processing conceptual information effectively is to focus on actively constructing the relationships between these ideas. Essentially, you want to build a mental map that shows how different concepts connect, influence each other, and form the larger picture. This map becomes your framework for understanding.

Let me show the power of this with another example from my work on the Search Inside the Book feature. My time on that team was an introduction to the concept of a large scale digital catalog system. It went beyond the facts like specific ISBN formats or the process of scanning pages. I began to build a mental map of what a catalog fundamentally is, a structured system for uniquely identifying items, managing their metadata, handling different versions or editions, and making that information discoverable and useful. I learned core concepts around data ingestion pipelines, the importance of consistent identifiers like ASINs, how catalog data quality impacts search and discovery, and the complexities of mapping external data (like publisher feeds) to an internal canonical representation.

This conceptual understanding of catalog systems in general was a massive accelerator years later when I joined a team tasked with selling tickets for events like concerts and shows. The challenge was new: how should we model things like a selling Justin Bieber concert tickets in Amazon's system? Should the artist be the core item (the ASIN)? The tour? Each individual show date? Or even each seat? While the items (tickets vs. books) were different, the underlying conceptual questions about unique identification, inventory structure, metadata for discovery, and mapping to Amazon’s existing ASIN based architecture were similar to the problems I had been exposed to within Search Inside the Book. Because I already possessed that mental map of how catalog systems work, the patterns were clear. I could contribute to designing our approach for this new business far more quickly than if I had been starting from zero.

The same conceptual toolkit was just as critical when I moved to the Prime Video team years after that. They managed a vast catalog of movies and TV shows, which, while logically separate from the physical product catalog, needed to integrate seamlessly for search and customer experience on the Amazon retail website. The Prime Video org. was facing a complex rewrite of their catalog systems. Again, the surface details were different, video encodings instead of page scans, streaming rights instead of print editions. But the fundamental catalog concepts were the same: understanding vendor SKUs from content providers, the challenges of matching and merging data from multiple sources for the same title, handling errors and inconsistencies in metadata (Type I and Type II errors), the requirements for localization and globalization of content, and the profound effect of catalog structure on search relevance and content discovery algorithms.

My pre-existing conceptual framework meant I could get up to speed and contribute meaningfully to this highly complex video domain much faster than anyone might have expected. The core conceptual understanding was already in place. I just needed to learn the new domain specific facts and adapt to local team processes.

This Prime Video project, with its immense scale and complexity, and my role in leading the technical vision for the catalog rewrite, was the one that led to my promotion to Principal Engineer. This is why focusing on conceptual understanding is so powerful. Concepts are incredibly transferable across different projects, teams, and even industries. They form the bedrock of rapid learning.

You will encounter these same core concepts again and again throughout your career, just in different packaging or with a new layer of complexity. While the specific facts and processes are likely to change, the fundamental concepts within any given field are surprisingly finite. Learn about them once, and you carry a toolkit that allows you to adapt and excel wherever you go.

Tip: When building a mental map for a new domain, start by identifying what you believe is the most central concept or system. Place this at the center of your page or digital canvas. As you learn related ideas, facts, processes, or sub-components, draw them as branches from this central point, or from other related concepts if that makes more sense. Focus on labeling the connections and relationships between these items (e.g., 'is caused by,' 'is a type of,' 'depends on,' 'leads to'). This act of defining relationships is what clarifies the structure of the domain. Your mental map is a living tool, revisit, redraw, and refine it as your understanding grows. If you’re able to get time with experts, share your map with them. Walk them through your understanding. Ask them: "Does this make sense? Are the connections I've drawn accurate? What key concepts or relationships might I be missing or misinterpreting?" This will maximize your time with these busy people.

The Power of Your Questions

Throughout this guide, we’ve focused on how to acquire, categorize, and understand new information. But there is another crucial element in your journey from newcomer expert: the questions you ask. Think of your questions not just as requests for information, but as markers that define the borders of your current understanding. They illuminate the boundary between what you know and what you are still exploring.

This is why I strongly recommend keeping a running list of the questions that arise as you learn. Do not just focus on just getting the answers, log the questions themselves. Over time, this list becomes a record of your progress. Looking back at questions you jotted down weeks or months prior, you’ll find that what once seemed confusing is now clear, or even obvious.

This list of questions is also a signpost that indicates when you’re no longer the new guy. Initially, your questions will likely be about basic facts, established processes, and foundational concepts. But as you get up to speed, you’ll eventually notice a shift.

Your questions will become more nuanced, more probing, perhaps even challenging existing assumptions or exploring new territory. You will know you have truly arrived when your open and unanswered questions begin to align with the complex, open questions that experienced subject matter experts on your team are also grappling with. When this happens you are no longer just learning the ropes, you’ll be the person that others want to sync up with to ramp up themselves.

Turning "New" into Your Superpower

Getting up to speed quickly is not magic or something you’re born with. It is a skill just like anything else. By treating Facts, Processes, and Concepts, differently you’re accelerating your learning. This approach, coupled with tracking your questions to map your journey, will help you get up to speed unbelievably fast.

My hope is that by applying this framework, the challenge of tackling something new becomes an exciting opportunity. Your life will change when you lean into learning new things, rather than shying away from them.

Note: I’m still on the road with the family, so here is week two of the archive favorites I lined up before I left. This one is on dealing with ambiguity, and it is one I come back to often myself.

I remember a pivotal moment early in my career at Amazon. My team was tasked with solving a complex problem in the retail catalog system, and everyone was stuck. The project had vague requirements, unclear success metrics, and stakeholders with conflicting priorities.

Classic ambiguous situation.

I grew impatient with the situation, threw my hands up in the air during a meeting, and said "What problem are we actually trying to solve?!"

I didn't realize it back then but I had hit on exactly the issue and solution.

The difficulty with ambiguity is there's nothing to grasp on to. Everything feels like an unbounded investigation.

Coding interview problems are so unrealistic because all of the problems are well-defined. Clear constraints on input. A battery of test cases with known solutions. But real-world engineering is filled with fog and uncertainty.

Tech workers and software engineers specifically are problem solvers. When it comes to code, we have to be exact because computers don't take in fuzzy directives. Yet when it comes to defining what we should build, fuzziness is the norm.

When Ambiguity Strikes

Some common situations include:

• Being assigned to "investigate" a particular topic without guidance, requirements, or desired outcomes.

• Your team faces a project requiring skills no one currently has, with unclear resources for training or hiring.

• Being tasked with making the system "ready for scale" or “highly available” without specific traffic projections, growth expectations, or performance requirements.

Sound familiar?

The Problem is the Solution

What I came to realize is that when confronted with ambiguous situations, your goal isn't to find a solution. Once a suitable problem has been framed, the ambiguity doesn't exist anymore, and then everybody can go on their merry way delivering a solution.

When it comes to dealing with ambiguity, the problem is the solution.

This completely transformed how I approach vague directives. Instead of spinning my wheels trying different solutions to poorly defined problems, I now focus my energy on problem definition.

In engineering, we're trained to jump straight to solutions. We pride ourselves on our ability to "figure it out." But with true ambiguity, there's nothing to figure out yet—there's only possibilities.

When someone says, "We need to improve our site's performance," the statement itself isn't actionable. What aspects of performance? For which users? Under what conditions? To what degree? By when? With what resources?

The magic happens when you reframe ambiguity as an opportunity to define the problem space. Once you've established clear boundaries, success metrics, and constraints, the fog lifts, and the path forward materializes.

I've seen teams spend months (sometimes years) building solutions to problems nobody cared about because they never took the time to properly frame the problem they were solving. Meanwhile, teams that invest in generating a well-defined problem definition go much further much faster.

As Einstein reportedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."

Questions Define a Problem Space

I think of an ambiguous situation as a high-dimensional problem space. Each unknown variable adds another dimension of complexity, making the solution space impossibly vast.

The way forward is to ask questions and to find answers to the extent you can. By collecting and exploring questions, you're able to gradually reduce the dimensions of this problem space until you reach a manageable, solvable problem statement, or at least a lower-dimensional and tractable space.

Questions, at first broad but then more specific, are your tools for mapping the territory of the unknown.

Here's my process for using questions to navigate ambiguity:

1. Start with a "question dump". When faced with ambiguity, I open a document and spend 10-15 minutes listing every question I can think of about the situation. "What do I know?" "What does success look like?" "Who are the key stakeholders and partners?" "What constraints are we working with?" "What assumptions are we making?" "What's the timeline?" "What are the risks?"

2. Organize by power. Once I have a good list of questions, I triage. I group the best ones into categories: Questions with answers I already know. Questions with answers I can find. Questions where I don't know the answers. The best questions fix dimensions in that high-dimensional space or allow you to avoid whole swathes of areas to investigate. For questions that I don't know the answers to, I recurse and start with step 1 again.

3. Seek answers systematically. With my priority questions in hand, I identify the right people to share my work with. I ask everybody I speak with who I should talk to next. A lot of information you can probably go find the answers to on your own, so don’t be afraid to roll-up. your sleeves.

4. Iterate and refine. As I get answers, new questions emerge. That's expected and healthy. This means I’m making progress, even if the number of questions explodes. I add these to my list and repeat the process.

5. Document and share. At some point I can go back to the person that made the request. If I need to write a document, I've got a list of questions, answers, and also things I DON'T know. This does wonders to combat an empty page.

I've never had anybody be disappointed in this type of disambiguation and research because by going over the questions, what I don’t know, and what I’ve discovered, I take people along with me. They get to use the map I’ve created as a starting point.

The beauty of this approach is that it works at any level—from a vague ticket to a mysterious strategic initiative.

A Real Example: From Fuzzy to Focused

Let me share how this worked on a real project. My team was asked to "improve the reliability" of a critical system. As vague as it gets.

Instead of immediately coming up with solutions, I started with questions:

• What specific reliability issues are we experiencing?

• How are we measuring reliability now?

• What level of reliability do we need to achieve?

• Which components are most critical?

• What's the timeline for improvement?

• What resources do we have available?

Through conversations with stakeholders, we discovered that "reliability" meant very different things to different teams. For operations, it meant reducing alerts. For product, it meant consistent response times. For leadership, it meant a significant reduction in customer-reported issues.

By framing the problem properly, we were able to define success as "reducing customer-impacting incidents by 80% within six months while maintaining current performance metrics."

Suddenly, our ambiguous directive had transformed into a clear, measurable goal with defined constraints. The team rallied around this concrete challenge, and we were able to make amazing progress.

Take Your Ambiguity-Busting Skills Further

Ambiguity is inevitable but by reframing it as an opportunity to ask profound questions, you turn what most people see as a frustration into your competitive advantage.

The next time someone drops a vague request in your lap, don't panic—celebrate. You've just been handed the perfect opportunity to demonstrate your ability to create clarity from chaos.

Speedrun To Promotion Video Course Is Now Free

Tired of watching colleagues zoom past you while you're stuck in place? I've just released my battle-tested Speedrun to Promotion course to the public—at zero cost. This isn't just another "work harder" pep talk; it's the exact framework I used to rise through Amazon's ranks, and it's helped hundreds of engineers accelerate their careers.

You can get access here. If you’ve been struggling at the same level for too long, I’m here to help.

Subscribe now

Podcast Appearance

Ryan Peterman came to my studio and filmed an episode of his podcast. It’s on track to be his most viewed video. Take a look and while you’re there, subscribe to his channel as it takes off.

Steve Huynh coaches him live on how to lead with outcomes instead of methods, find stories with stakes that match the level he's targeting, and and bring the same energy to the interview that he already brings to the work itself.

If you want to be in the hot-seat for the next video like this, apply here: https://forms.gle/121P4FhVhxkBaPiq5

Previous Episodes

• What Big Tech Still Gets WRONG about Great Programmers | Casey Muratori

• Why People Are INVISIBLE To Leaders And How To Fix It | Ethan Evans

• Why Even The Best Engineers Are Afraid Of What’s Coming | Philip Su

• $4 Billion Founder: Should You Leave Big Tech or Ride It Out?

• The Career Decisions That Quietly Limit Your Future | Christopher Brown

• Tech Interview Expert: AI Isn’t Killing Careers, But THIS is

• OpenAI and Meta E9…

Read more

Quick note: I'm out of the country with my family for the next few weeks. To keep the inbox alive while I'm away, I'm resurfacing three of the most-read pieces I've ever published, one a week. This first one is the single most popular thing I've written. If you joined recently, it will be new to you, and it holds up.

Your manager has already put you in a box.

Whether you realize it or not, they've mentally categorized you into one of three buckets: the stars they can't afford to lose, the solid performers who get the job done, or the baseline employees who just meet expectations. Once you're labeled, it's surprisingly difficult to change categories—but the quality of your work life depends on which bucket you're in.

Well, that’s not entirely true. There’s a fourth bucket of low-performers that your manager does not favor. But those people get let go and so it transitions back to the three buckets.

The four three manager buckets:

The stars get the best projects, visibility with leadership, higher ratings, faster promotions, and the benefit of the doubt when things go wrong.

The baseline employees? They get the routine work, meager cost-of-living increases (if anything at all) and live in the fear of moving to the low-performers bucket.

This newsletter isn't about manipulation or brown-nosing—it's about doing simple things that make your boss's job easier while positioning yourself as the high-value team member you are.

The Challenge of Changing Categories

Here's something most career advice gets wrong: Movement between these buckets doesn't happen gradually. You don't slowly drift from "meets expectations" to "star performer" through incremental improvements in your work quality.

Instead, these transitions happen in quantum leaps — sudden shifts in how your manager perceives your value. Your manager mentally re-categorizes you after specific moments or actions that fundamentally change how they see you.

The truth is that doing good work consistently is necessary but not sufficient. Many solid employees produce quality work for years without ever making it to the star category. The difference isn't just about work output—it's about how you make your manager's life easier and how visible your contributions are.

5 Simple Ways to Impress Your Boss

These five strategies aren't about manipulation—they're about smart relationship management with the person who has the most influence over your career trajectory. Each one creates disproportionate value for the effort required, in other words, they are high-leverage.

1. Ask for feedback, then visibly act on it

From your boss's perspective, most feedback they give to their employees might as well go into a black hole. They'll spend time thoughtfully formulating constructive criticism in a one-on-one, only to see zero change in behavior. Week after week, they'll repeat the same suggestions, wondering if they're being heard at all.

This is precisely why when someone actually proactively asks for feedback and is seen acting on that feedback quickly, it's shocking—in the best possible way. It immediately differentiates you from 99% of employees.

Most people make the mistake of responding to feedback verbally rather than with action. They'll say things like "That's great feedback, I'll definitely work on that" or "I completely agree, I should do more of that." But words without follow-through reinforce the perception that you're all talk.

We want to show our managers that we're taking feedback, not tell them we've changed. There's a world of difference between saying "I'm working on being more proactive" and actually demonstrating proactivity through visible action.

When I asked my manager for proactive feedback, he mentioned that I should "take a more active role in upleveling my coworkers." The following week, I organized a brown-bag lunch session where I did a deep dive on our system architecture, highlighting some of the common traps and pitfalls of working on the system.

My team loved the session because it provided valuable context on the system. We ended up adding the recording to our onboarding process. In our next one-on-one, my manager specifically mentioned how he was impressed by my actions, even though he was the one that gave me the feedback.

Quick win: During your next one-on-one, ask for feedback and be seen taking some aspect of that feedback. The faster you do this, the better.

2. Deliver exceptional status updates

Most managers spend their days in an information desert. They're responsible for knowing what's happening across their team, but getting that information is like pulling teeth.

This is why delivering clear, proactive, and thorough status updates creates such a powerful impression. When everyone else is making your manager work for basic information, you're the oasis in the desert—the person who consistently provides exactly what they need before they even have to ask.

The typical employee approaches status updates as a checkbox exercise. They'll say things like "Project X is on track" or "Still working on that database issue" without any meaningful context or forward-looking information. They view status updates as reporting to authority rather than as a strategic communication opportunity.

What your manager actually needs is a complete picture of how things are going: what you've accomplished, what you're working on now, any challenges you're facing, and how you plan to address them. When you consistently provide this level of clarity without being prompted, you immediately stand out as someone who makes their job easier rather than harder.

I learned this lesson early in my career at Amazon. My team was working on a complex migration project with multiple dependencies. I started sending brief weekly summaries that outlined: completed items and milestones, current focus areas, existing and potential blockers on the horizon, and proposed mitigation strategies. When promotion discussions came around, my manager already had a six-month record of my impact.

It doesn’t have to be at the organizational or project level. Simply being proactive about status at the personal level with slack messages or during 1-1s already sets you apart.

Quick win: Play this game: Everytime your manager has to ask you about the status of something, you lose. When you are surfacing issues, make sure to come with solutions and a recommendation, not just with problems.

3. Get Ahead of Bad News

Managers hate surprises—especially negative ones. There's nothing more stressful for a manager than discovering at the last minute that a deadline will be missed, a feature is broken, or a client is unhappy. These moments trigger the feeling that they aren’t in control.

This explains why the employees who bring problems to their attention early—along with potential solutions—are so highly valued. When you preemptively flag issues before they become emergencies, you transform from a source of stress into a trusted partner that has their finger-on-the-pulse.

Bad news delivered early enough is just news. Bad news delivered late is truly terrible.

The average employee avoids delivering bad news until absolutely necessary. They hope problems will resolve themselves, try to fix issues without telling anyone, or wait until the last possible moment to admit something's wrong. They fear being associated with problems or having their competence questioned.

What they don't realize is that every manager knows problems are inevitable. What separates high performers isn't avoiding problems entirely—it's how proactively they identify, communicate, and address them before they spiral out of control.

I noticed concerning performance metrics in our staging environment just days before a major release. Instead of sitting on the information or waiting for someone else to notice, I did some quick research and reached out to my manager with a assessment:

"I've identified a potential scaling issue with the new service that could impact user experience during high traffic periods. Here's what we're seeing, here's what I think is causing it, and here are three options for addressing it before release. My recommendation is option two, which would require a two-day delay but ensure a smooth user experience."

My manager later told me this message gave him the feeling that he could absolutely trust me to do the right thing in his absence. This led to me being a stand-in for him to meetings meeting with external partners, growing my influence.

Quick win: The next time you encounter a potential issue or delay, immediately draft a message to your manager that follows this structure: (1) clear identification of the problem and how you came to know of its existence, (2) potential impact if not addressed, (3) options for resolution, and (4) your recommended approach. Send it as soon as you're confident in your assessment, not when the deadline is already in jeopardy.

4. Anticipate Needs Before They Become Problems

Managers spend much of their time playing defense—reacting to issues, responding to requests, and putting out fires. This constant reactive mode means they rarely have bandwidth to focus on strategic initiatives or improvements. It's exhausting and often prevents them from making their own impact.

This explains why employees who can anticipate needs before they become problems become invaluable. When you identify and address potential issues before your manager even has to think about them, you demonstrate a level of ownership and foresight that immediately separates you from peers.

Most employees operate in a request-response pattern. They wait for explicit direction, complete the assigned work, and then wait for the next instruction. Even diligent, hardworking team members often limit their focus to their immediate responsibilities without considering the bigger picture.

High performers, by contrast, develop a sixth sense for pain points and proactively address them. They're constantly asking themselves: "What recurring issues are slowing us down?" "What information or resources are we frequently missing?" "What would make everyone's job easier?" Then they take initiative without waiting for permission.

I noticed our team was spending hours each sprint debugging configuration issues between environments. Nobody had explicitly flagged this as a problem—it was just accepted as part of the development process. Instead, I spent a few evenings documenting the inconsistencies and creating a configuration validation tool.

"I built a small utility that automatically checks for config mismatches between environments. I've been using it for the past week and it's saved me hours of debugging time. I've put it in a shared repo with documentation if anyone else wants to use it." Within a month, my tool extended and adopted as an automated part of our process.

While my manager didn’t really understand what I did, he was very pleased that it saved developer time and led to faster feature development. The fact that I did it without being asked was the thing that really boosted my contribution in his eyes.

Quick win: Identify one recurring friction point in your team's workflow—something that consistently causes delays, confusion, or extra work. Develop a simple solution (a template, script, documentation, or process improvement) and implement it without fanfare. Don't ask for permission; just solve the problem and casually share the solution as if it's the most natural thing in the world. Make sure your manager is CC’ed.

5. Make Your Manager Look Good To Their Bosses

Your manager exists within a hierarchy, facing their own pressures, goals, and performance metrics. While they're evaluating your work, their boss is evaluating theirs. Just like you, your manager's success is directly tied to how their leadership perceives their effectiveness.

This explains why employees who actively contribute to making their manager look good to senior leadership live in the stars bucket. When you help your manager shine in front of their boss, you're not just doing your job—you're actively advancing their career, which creates a powerful incentive for them to advance yours.

The average employee considers only their direct responsibilities and perhaps their team's goals. They rarely think about how their work affects their manager's standing in the organization or what metrics their manager's performance is judged by. They assume that simply doing good work is enough.

High performers understand that the organizational context matters tremendously. They make it their business to know what their skip-level manager cares about, what initiatives are priorities at the leadership level, and how their manager's performance is evaluated. Then, they deliberately align their work to support those priorities.

I noticed my manager was under pressure to improve our team's feature velocity—a metric his boss had highlighted in a recent all-hands meeting. Instead of simply focusing on my assigned work, I took the initiative to analyze where our time was being spent.

After identifying several bottlenecks, I determined that we could substantially and reliably increase our delivery velocity if we didn’t spend so much time gathering, deep diving, and prioritizing requirements from product managers. I surfaced this to my manager, who was in a much better position to do something about it.

Once the product to tech handoff was identified as a problem, my manager rolled his sleeves up and initiated conversations with the product team. He shared with them the pattern of ambiguous or missing requirements, and the fact that insisting for “nice-to-have” items, instead of sticking to the necessary functionality, was slowing down the team (and were getting cut anyhow when dates slipped). Working with the product team to standardize this handoff and therefore increasing our velocity made my boss look good in front of his, and played some part in his (and eventually my) promotion.

Quick win: Schedule a brief conversation with your manager around this simple question: "What's one metric or deliverable that you are being measured on?" Once you understand this priority, look for ways to contribute to it.

The Path to the Top Bucket

These five strategies offer a clear roadmap for changing how your manager perceives your value. They don't require extraordinary talent or superhuman effort—just thoughtful attention to what actually matters in the manager-employee relationship.

What makes these approaches so powerful is their compound effect. Implementing just one creates a positive impression. Consistently applying several creates the quantum leap needed to move from one bucket to another in your manager's mind.

These transitions aren't gradual—they happen suddenly when your manager mentally recategorizes you based on a pattern of behaviors that set you apart from your peers.

Start with just one approach this week. Notice the response. Add another next week. Within a month, you'll have created a new dynamic with your manager—one that opens doors to opportunities reserved for those in the highest bucket.

Did I miss anything? Let me know below.

Enjoyed this week’s newsletter? Give it a ❤️ so I know to write similar ones in the future.

Subscribe now

I keep a running list of what separates world-class engineers from the rest of us. Last week I shared the first five. Here are five more.

But first, one thing worth saying out loud. I am a behavioralist at heart. I believe you are, in the end, what you do.

That belief is the undercurrent beneath everything I write. It is why none of these ten items, last week’s five or this week’s, is about being smarter than the people around you. These engineers are brilliant and they work hard, and I am not pretending otherwise. Brilliance and hard work are table stakes at this level, and almost everyone at the top has already cleared that bar.

But what separates them from the rest is their behavior. Specifically, how they act and react when things get difficult.

That is what you need to copy. Do enough of the same, and you will be well on your way to becoming an elite engineer.

These five elite behaviors show up in how the best carry themselves under pressure. They…

Read more

One of the best things about doing my podcast is the hours it buys me with engineers at the very top of the field, the principal and distinguished engineers whose careers other people seek to model their own.

After participating in many such conversations, both through my podcast and during my time at Amazon, I have recognized a handful of patterns that have held over the decades and across different companies.

What follows is my running list of those patterns, the ones that keep surfacing whenever I sit down with someone elite. There are five of them, and I explain the gap between what they do and where most other people stop. If you would add another one to the list, drop it in the comments.

1. They measure their growth on a monthly cadence

The best engineers do not wait for a promotion or annual performance revi…

Read more

Most people think that the adjective “senior” is earned as a function of time and raw output.

I have been here five years. I am one of the most productive people on the team.

Yes, those things matter. But something else matters even more: observable behavior.

It is what people see you doing in real time, in your meetings, and in the messy middle of an incident, in the documents you write. And it’s in the things you do when nobody told you to do them.

When your actions don’t match the description of “senior,” you will remain at your current level, no matter how smart you are or how hard you work.

Today, I am going to hand you a clear lens on the behavior others are watching

Read more

Steve Huynh has seen this before — the experience is all there, but the stories aren't showing it. He coaches John live on exactly what's getting in the way.

If you want to be in the hot-seat for the next video like this, apply here: https://forms.gle/121P4FhVhxkBaPiq5

Previous Episodes

• What Big Tech Still Gets WRONG about Great Programmers | Casey Muratori

• Why People Are INVISIBLE To Leaders And How To Fix It | Ethan Evans

• Why Even The Best Engineers Are Afraid Of What’s Coming | Philip Su

• $4 Billion Founder: Should You Leave Big Tech or Ride It Out?

• The Career Decisions That Quietly Limit Your Future | Christopher Brown

• Tech Interview Expert: AI Isn’t Killing Careers, But THIS is

• OpenAI and Meta E9: The Career Bet Every Engineer Must Make

• The Career Strategy That Survives AI

• I Tried Everything to G…

Read more

If you’ve ever played Risk, you will know the feeling.

Early on in the game, expansion feels incredible. First you take one country off an opponent, then another, then another. Eventually, you capture a whole continent. Every territory you hold earns you more new armies when your turn comes around again, and it feels good to see the map of the world filling up with your color. It looks like you’re winning.

Then come the counter-attacks.

And because you had to spread your armies thin to grab all that land, you’ve left some territories guarded only by single pieces. The moment your opponent breaks through into one, they can then bulldoze their way through a whole swath of your territory in a single turn.

With only a single die to defend against your opponent, you watch helplessly, a mere spectator, as, one by one, your understrength armies succumb to the onslaught.

And, just like that, the board has flipped, and you don’t feel so good.

That’s the seduction of R…

Read more

I was heading out on a long trip this week to meet up with some other creators this weekend. As I prepared for it, I caught myself doing the thing I always do before I travel.

I was loading up on distractions to take with me.

I downloaded dozens of YouTube videos. I queued up a backlog of podcasts that I had been wanting to listen to. I threw in a video game. I packed two physical books and my Kindle. And, of course, I had my laptop, just in case I felt like being productive while I was away.

I was packing for my trip the way a lot of us live now: hedging against the terrifying possibility of an empty moment.

Then I stopped. I looked at the little arsenal I’d assembled, all of it to guarantee that I would not “waste” a moment of my trip.

And then it hit me.

This arsenal of distractions was going to prevent me from experiencing my trip.

Ironically, my insurance against empty moments would virtually ensure that all of the moments I had would be empty.

I empti…

Read more

What he's missing has nothing to do with experience — and everything to do with how he tells it. Three changes. One session. Watch it happen in real time. Steve Huynh coaches him live through every story.

If you want to be in the hot-seat for the next video like this, apply here: https://forms.gle/121P4FhVhxkBaPiq5

Previous Episodes

• What Big Tech Still Gets WRONG about Great Programmers | Casey Muratori

• Why People Are INVISIBLE To Leaders And How To Fix It | Ethan Evans

• Why Even The Best Engineers Are Afraid Of What’s Coming | Philip Su

• $4 Billion Founder: Should You Leave Big Tech or Ride It Out?

• The Career Decisions That Quietly Limit Your Future | Christopher Brown

• Tech Interview Expert: AI Isn’t Killing …

Read more

It was my first experience of a big re-org, and we did everything wrong.

The announcement landed in a meeting that lasted fifteen minutes. We got a new VP, a new organizational structure, and half the teams moving under managers I’d never worked with.

When our team met right after the announcement, our manager was peppered with questions.

“What does this mean for my project?” “Am I still on this team?” “Who do I report to now?”

To each question, he gave the same answer, in slightly different words.

“I don’t know.”

We didn’t believe him.

We asked him again the next day, and the day after that. We traded theories in DMs about what was coming, and why.

We burned weeks of nervous energy trying to pull certainty out of a person who had none to give. Because the decision had been made three levels above him, and he’d found out about it only a day before we did.

I went through more than twenty managers in my eighteen years at Amazon. The last five were under one person,…

Read more

From the late 19th century until well past the middle of the 20th century, many women worked as telephone operators. In the 1920s, there were about 230,000 of them sitting in front of switchboards and plugging calls through to wherever they were going.

Then, with the advent of the automatic exchange, the profession was wiped out.

It’s the classic story of technology erasing a job, and it’s the story everyone’s afraid of with AI.

The fear is everywhere, and it’s difficult to ignore. It seems as if every week there’s another spate of layoffs attributed to AI. You can’t help but think that the thing you’re doing is going away.

I lived a smaller version of that fear for almost twenty years. The job I had at Amazon when I started bore almost no resemblance to the one I had when I left the company. It changed underneath me again and again.

Every time, what I did got automated into something a beginner could do in an afternoon. Tasks that I’d spent years doing…

Read more