Reframing "Impossible"

Why "Impossible" Is Just a Label

In 2004, nobody had built a search engine that could index the entire web and return results in under a second. The problem was called intractable. The data volumes were too large. The latency requirements were too tight. The engineering problem was, by the standards of the time, impossible. And then Google shipped it, and suddenly it wasn't impossible anymore — it was just a thing that existed.

In 2008, the idea of a company that would let strangers sleep in other strangers' homes and build a viable business around it was dismissed as dangerous, unscalable, and fundamentally unworkable. Three engineers decided to find out if that was actually true. The project felt impossible. They shipped it anyway.

Neither of these happened because the engineers were smarter than the people who said it couldn't be done. The engineers who said "impossible" were often highly intelligent, experienced, and technically correct about the specific obstacles. What they were doing — without realizing it — was confusing their current inability to see a solution with the project's actual impossibility. That is a category error. It feels true, but it's wrong.

"Impossible" is a word that belongs to a specific moment in time, a specific level of understanding, and a specific set of assumptions. Change any of those three things, and the word no longer applies. The engineers who ship impossible projects are not people who ignore obstacles. They are people who treat "impossible" as a starting point for inquiry rather than a stopping point for action.

The two kinds of impossible

Before we go further, it's worth noting that there are genuinely two kinds of "impossible," and conflating them is its own mistake.

Physically impossible means something that violates a fundamental law of nature or mathematics. You cannot build a system that is both perfectly available and perfectly consistent in the presence of a network partition. That's the CAP theorem. You cannot make a distributed system that provides linearizable reads without coordination cost. These constraints are real. No amount of engineering creativity changes them.

Practically impossible means something that nobody has figured out how to do yet, or that seems too complex to execute, or that requires resources or knowledge or organizational alignment that doesn't currently exist. This kind of impossible is almost always temporary. It turns into possible the moment someone figures out the right decomposition, the right sequence of steps, or the right set of tradeoffs.

The overwhelming majority of projects described as "impossible" in large technology companies are the second kind. When someone says "we can't migrate off this legacy system — it's too deeply integrated into everything," they are almost never describing a physical impossibility. They are describing a practical impossibility that has not yet been decomposed into a sequence of achievable steps. That is a solvable problem. It might take two years. It might require ten teams. But it is not in the same category as "build a machine that violates causality."

The skill this chapter is building is learning to immediately ask: which kind of impossible is this? And if it's the practical kind — which it almost always is — to treat it as a decomposition problem rather than a permanent limitation.

The Fog of War, Explained

The phrase "fog of war" comes from the military strategist Carl von Clausewitz, who wrote in the 1800s about the nature of conflict. His observation was simple but profound: in a battle, you almost never know what's actually happening. You don't know where all of your own units are. You definitely don't know where the enemy's units are. You're operating on partial information, outdated reports, and educated guesses. And yet — you still have to make decisions. The battle does not pause while you wait for better intelligence.

This is an almost perfect description of running a large, ambiguous engineering project.

At the start of a complex project, you are operating in thick fog. You can see clearly for maybe twenty feet in any direction — the immediate technical problems, the next two weeks of work, the people you're talking to right now. Everything beyond that is murky. You don't know which teams will push back and which will embrace the change. You don't know which technical assumption will turn out to be wrong. You don't know which dependency will be six months late. You don't know whether the approach you've chosen will survive contact with the real system.

Most engineers respond to this fog in one of two ways. The first group waits. They want more requirements, more specifications, more clarity before they'll commit to a plan. They're waiting for the fog to lift. The second group starts moving, carefully, using what they can see, with one eye always on the edges of visibility. They treat the fog as a given, not an obstacle.

The critical insight — the one that Clausewitz noticed about military commanders and that applies equally to principal engineers — is that the fog does not lift on its own. It lifts as you move through it.

When you take the first step — even if it's a small step, even if it's exploratory, even if you're not sure it's the right direction — you learn something. Maybe you learn that the first approach won't work, which means you now know one more thing than you did before. Maybe you learn that one dependency is much simpler than you thought, which changes your sequencing. Maybe you discover a team that wants to help, which changes your resource picture. None of this information was visible from where you started. It only became visible because you moved.

The group that waits for the fog to lift never gets the information it's waiting for, because that information is only available to people who are already in motion. This is not a metaphor. It is a literal description of how complex projects work.

What the fog actually contains

Here's what's hiding in the fog of a typical large engineering project, and roughly when it becomes visible:

Notice that nothing in this list becomes visible from a standing start. Every piece of clarity requires an action. Planning meetings do not reveal hidden dependencies — starting the work does. Whiteboard sessions do not reveal whether a team will be difficult — having the hard conversation with them does. The fog is not a waiting room. It is an environment that responds to movement.

The compass principle

Here is the practical operating model that comes out of this: you don't need the whole map. You need a compass and enough map to take the next step.

The compass is your north star — the clear, simple description of what success looks like. We'll build this in Chapter 7. It doesn't give you the route. It gives you the direction, so that when you're choosing between two paths you can't fully see, you can at least tell which one points the right way.

Enough map to take the next step means that you don't need to know how you'll get from month one to month eighteen. You need to know what you're doing in the next two weeks, roughly what you're doing in the next three months, and a loose shape of what comes after that. The next-two-weeks plan should be specific enough to execute. The three-month plan should be specific enough to communicate. Beyond that, you're dealing with fog, and you should admit that openly.

How Decomposition Dissolves "Impossible"

If you had asked a civil engineer in 1869 "Can you build a railroad across the United States?" the honest answer was no — not because the physical act was impossible, but because no one had worked out the specific sequence of problems that needed to be solved to get there. The Central Pacific and Union Pacific railroads were built not through a grand act of engineering will, but through a relentless, mundane process of solving one small problem after another — how do you blast through granite? How do you haul ties to the middle of Nevada? How do you feed 10,000 workers in the desert? — until the small problems added up to a transcontinental railroad.

This is decomposition. Not a technique. Not a project management methodology. A fundamental truth about how complex things get built: by breaking them into pieces that are each individually doable, even if the whole is not.

The reason decomposition feels hard on an ambiguous project is that you often don't know the right pieces to break it into. You don't have a blueprint. You're trying to decompose something that isn't yet well-defined. This is where most engineers get stuck, and it's where the fog of war analogy becomes most useful.

You don't need to decompose the entire project before you start. You need to decompose it just enough to start. Your first decomposition will be wrong in some ways. Some pieces will turn out to be ten times harder than you expected. Some pieces you thought were essential will turn out not to matter. But starting from an imperfect decomposition is infinitely better than waiting for a perfect one, because a perfect decomposition of a complex, ambiguous project is not available until the project is almost done. And by then you don't need it anymore.

The decomposition test

Here is a practical test: take your "impossible" project and try to answer this question — What is the smallest possible piece of this that would, if you completed it, prove that the bigger thing is achievable?

That piece — whatever it is — is your first milestone. It's almost always much smaller than you think it should be. Senior engineers often resist starting with something small because it feels like they're not making progress on the real problem. But the small thing is not a warmup. It is the fog-lifting mechanism. When you complete it, you will know things you cannot currently know. And those things will tell you what the second piece is.

Notice what happened there. Nobody solved the whole problem. Nobody waited for a complete design. The tech lead picked the smallest piece that would tell them the most, went and did it, and used what they learned to plan the next step. That is the decomposition technique on an ambiguous project. Move. Learn. Adjust. Repeat.

The Uncertainty Tolerance Gap

If you've worked at a technology company long enough, you've noticed a pattern. When a new, deeply ambiguous project lands on a team, the engineers respond differently based on their level of seniority — and not always in the way you'd expect.

Junior engineers tend to either dive in headfirst without thinking through the problem, or freeze up entirely because there are too many unknowns. Neither response is sophisticated, but both are understandable.

Mid-level engineers tend to do better on execution when requirements are clear, but they ask for those clear requirements before they'll commit. "Give me a spec and I'll build it" is a reasonable position. It works well when someone else has done the ambiguity-clearing work for them.

Senior engineers can operate with moderate ambiguity. They know how to break down a fairly well-understood problem even when the details aren't all filled in. They'll make reasonable assumptions, document them, and flag where they might be wrong.

Principal engineers — the best ones — can operate with deep, structural ambiguity. Not just unclear requirements, but unclear problem statements. Not just missing specifications, but fundamental uncertainty about whether the project is even the right thing to be doing. They can hold all of that uncertainty, stay calm inside it, and still make forward progress every single day.

That gap — between "I need clear requirements" and "I can make progress even when I don't know what the right answer looks like yet" — is what uncertainty tolerance means. And it is one of the two or three most important capabilities that determine whether someone operates at a principal level or below it.

This is not about being reckless. Principal engineers who run into walls, who make wrong assumptions and burn six months on the wrong approach, are not demonstrating uncertainty tolerance — they're demonstrating the absence of it. Real uncertainty tolerance is not the absence of caution. It is the ability to be appropriately cautious (not paralyzed) about the things that matter, appropriately decisive (not reckless) about the things that don't, and able to tell the difference.

Why this gap is hard to bridge

The uncertainty tolerance gap is hard to close for a very specific reason: the discomfort of not knowing feels identical whether you're being appropriately cautious or being paralyzed by fear. In both cases, you feel uneasy. In both cases, the solution seems to be "get more information." From the inside, there's no obvious signal telling you which one you're experiencing.

This is why so many brilliant engineers plateau below their potential on ambiguous work. They're not lazy. They're not incapable. They're making a completely understandable error — they're treating a feeling (anxiety about the unknown) as if it were a fact (insufficient information to proceed). Those are not the same thing. And conflating them keeps them stuck.

Fear Disguised as Process

There is a specific pattern that shows up on every large, ambiguous project in every large organization, and it is worth spending some time on because it is so common and so hard to see when you're inside it.

It looks like this: a project is handed to a team. The project is complex and there are many things the team doesn't know yet. Instead of starting, the team — or a key person on the team — begins generating process. We need a requirements document. We need a design review. We need stakeholder alignment before we can define scope. We need sign-off from the architecture committee. We need a threat model. We need to define our success metrics more precisely.

Some of these things are genuinely necessary. Some of them are fear wearing a process costume.

The difference matters enormously. If you genuinely need stakeholder alignment before you can define scope, then generating that alignment is doing the work — it's the right first move. But if you're generating process because the ambiguity feels unbearable and process gives you something to hide behind while you avoid confronting it, then you're not doing the work. You're managing your anxiety, at the project's expense.

How to tell the difference

Here are the four questions that separate legitimate process from fear disguised as process:

1. What specific decision does this process gate? Legitimate process is gating a specific decision. "We need the requirements document before we can choose between approach A and approach B" is clear — the document gates a real choice. "We need the requirements document before we can start" is vague and suspicious. What exactly can't start? What is the decision that depends on it?

2. What is the cost of getting this wrong? Legitimate process is proportional to the cost of the decision it gates. A six-week design review for a project that will run for two years is a different thing from a six-week design review for a project that will run for six months. If the cost of being wrong is high and hard to reverse, more process is warranted. If the cost of being wrong is low and easy to recover from, more process is overhead.

3. What would "enough" look like? Legitimate process has an exit condition. You know what state the world needs to be in before the process step is complete. "We'll have stakeholder alignment when all three VP sponsors have signed the one-pager" is an exit condition. "We'll have stakeholder alignment when everyone is comfortable" is not — "comfortable" is not measurable and will never arrive on an ambiguous project.

4. What is the cost of the delay itself? Every week spent in process is a week not spent learning from actual work. On most projects, real work generates more useful information per week than any process step does — because the information from process steps is often theoretical, while the information from actual work is concrete. If you've been in a process step for more than three or four weeks, you should seriously ask whether you'd learn more by just starting the work and seeing what happens.

Notice that the problem here was not lack of skill, lack of effort, or lack of intelligence. It was a habit — a deeply ingrained response to discomfort that substituted organized documentation for actual uncertainty reduction. The requirements document felt like progress. It looked like progress. It was not progress.

The two failure modes of fear-as-process

This pattern has two failure modes, and both are common enough that you should know them by name.

The first is indefinite process extension — where process steps keep generating new process steps, and the project never actually starts. This is the clearest sign of fear-as-process. At some point, someone in leadership notices that the project is six months old and nothing has been built. There is a reset meeting. Things are said about "moving faster" and "bias for action." And then the team often goes back to generating process, because the underlying discomfort hasn't been addressed.

The second is premature lock-in — the mirror image of the first. The team is so uncomfortable with ambiguity that they rush through the process steps, declare the requirements complete before they are, commit to a design before it's been tested, and then spend the next twelve months defending a set of decisions that were made too early with too little information. This looks like decisiveness. It is also fear. The discomfort of ambiguity is resolved by eliminating the ambiguity prematurely — locking in decisions that should have remained flexible longer.

The right path is neither of these. It is operating with sustained, intentional uncertainty: moving forward enough to generate information, committing to decisions when the cost of delay exceeds the cost of being wrong, and remaining flexible on everything else.

Building Uncertainty Tolerance Deliberately

Uncertainty tolerance is a skill. Skills are built through practice in increasingly uncomfortable situations. If you want to get better at operating with ambiguity, you have to deliberately seek out situations where the answer is not clear and force yourself to act anyway — with appropriate safeguards, but without the crutch of waiting for certainty that isn't coming.

Here are five concrete ways to build this capacity:

1. Name the discomfort explicitly

The most powerful thing you can do when you feel the pull toward more process, more information-gathering, more delay, is to name it. Say to yourself: "I am uncomfortable right now because I don't know X. That discomfort is pushing me toward Y, which is a way to avoid confronting the discomfort." This sounds therapeutic because it is. Naming the feeling separates it from the decision. Once you've named it, you can ask: is Y actually the right move, or am I choosing it because it feels safer?

2. Set explicit "act-by" dates on open questions

For every important open question on a project, decide: by what date will we have answered this question, and what will we do if we haven't? This does two things. It prevents the information-gathering loop from running indefinitely. And it forces you to think about what "act anyway" looks like — which is often less scary once you've actually thought it through. "If we don't have a clear answer on the data model by Friday, we'll go with option A and document the assumption" is a plan. "We'll revisit when we have more clarity" is an anxiety-deferral strategy.

3. Distinguish reversible from irreversible decisions

Not all decisions deserve the same level of certainty before you make them. A decision that is hard to reverse — choosing your primary database technology, committing to a public API contract, migrating all users to a new system at once — genuinely warrants more care and more information. A decision that is easy to reverse — the name of an internal service, the exact format of an internal log, the order in which you tackle two equally-important subtasks — does not. Most engineers treat all decisions as if they're in the first category. This is exhausting and unnecessary. When in doubt, ask: how hard is it to undo this in three months? If the answer is "pretty easy," decide now and move on.

4. Do small experiments instead of big plans

When you genuinely don't know the answer to an important question, the cheapest way to find out is usually a small experiment, not a planning session. Want to know if a certain migration approach will work? Do it on one table, not all of them. Want to know if a team will be receptive to an alignment request? Have the conversation informally with one person from that team before calling the formal meeting. Want to know if an architectural approach will hit your latency targets? Build a prototype, not a spec. Experiments generate concrete information. Planning generates organized speculation. When you don't know the answer, choose experiments.

5. Track your uncertainty explicitly

One of the most useful habits you can build on a complex project is maintaining an explicit list of what you don't know. Not as a confession of inadequacy — as a tool. Call it the assumption register, the unknowns log, the open questions list. Whatever you call it, the act of writing down what you don't know does three things. It makes the fog concrete and bounded — there are seventeen open questions, not an infinite sea of uncertainty. It tells you which unknowns are most load-bearing and need to be resolved first. And it lets you track, over time, that the fog is actually lifting — which is motivating in a way that's easy to lose sight of on a long project.

The First Move on Any Impossible Project

All of the above is theory until you're sitting across from a Slack message from your director that says: "I'm assigning you to lead the [terrifying project name]. This is our most important initiative for the next eighteen months. Can we talk Monday?"

Your stomach drops. You know enough about the project to know how complex it is. You might not know enough about it to see any clear path at all. What do you do in the first 48 hours?

Here is the exact first move, every time:

Write down every question you would need to answer to prove that this project is achievable.

Not the requirements. Not the design. Not the plan. The questions. What would someone need to know to be convinced that this can actually be done? Write them all down. Don't filter them. Don't judge them. Just get them out of your head and onto the page.

Now look at the list. Some of these questions are load-bearing — if you can't answer them positively, the project cannot proceed. Some are important but not blocking. Some are interesting but not actually essential. Circle the three most important ones.

Those three questions are your first three tasks. Your job, before you do anything else, is to go answer them. Not by asking in a meeting. Not by writing a document that discusses them. By doing whatever it takes to actually resolve them — a prototype, a conversation with the right person, a quick experiment, a search through the codebase. Real answers, not documented hypotheses.

When you come back with answers to those three questions, two things will have happened. First, you will have reduced the fog. The project will be less impossible than it was 48 hours ago, because you now know things you didn't know before. Second, you will have ten new questions — because real answers always generate more questions. And that is fine, because those new questions are better questions than the ones you started with. They're closer to the actual problem. You're inside the fog now, and the view is clearer than it was from the outside.

This is not brilliance. This is a method. You will notice that nothing in this chapter has required you to be smarter than the people who called the project impossible. It has only required you to treat "impossible" as a signal to start decomposing, rather than a conclusion to accept.

That shift — from "I can't see how this is possible" to "let me find out what would make it possible" — is the most important thing this chapter is asking you to build. It is a small change in how you hold the moment when a project first lands on your desk. But it is the change that separates engineers who ship impossible projects from engineers who watch other people ship them.