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:
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?"
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.
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.
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.
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.
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.
Your reliability example shows why the method has more power than it advertises. Three groups meant three different things, and settling on customer-impacting incidents chose one of them. That's adjudication carried out under the cover of clarification, and it works precisely because a question dump makes the choice look like discovery rather than a decision. Whoever writes the problem statement decides whose definition wins, which is a considerable amount of authority to acquire by volunteering to do the tedious part.
Thanks for the great post!
The framework is great - dump the questions, sort them, go get them answered, write everything down - I've run that loop, and it genuinely works. But I noticed that it often works when the room lets you run it.
If a principal asks forty questions and people assume you're seeing something they can't but if a senior IC asks the same forty and they assume you haven't understood the task.
Did you notice that or was Amazon's culture flat enough that it never came up?