Every architect gets asked this question sooner or later, usually in an interview, usually with a straight face on the other side of the table, waiting to see if you’ll flinch. “How would you describe handling ambiguity as an architect?” I used to have a rehearsed answer. Something about gathering requirements, running discovery workshops, aligning stakeholders. All true. All useless, honestly, as a description of what it actually feels like to sit inside a decision nobody can yet make.

So let me try again, properly this time. Not the interview answer. The real one — the one that took me years of half-answered whiteboards and quietly wrong diagrams to earn.

I want to start somewhere unusual for a piece like this: not with a framework, but with a feeling. Because before you get to any method, any diagram, any decision matrix, ambiguity is a physical sensation. It sits somewhere between your chest and your stomach.

It’s the feeling of being asked to draw a map of a country you haven’t visited, based on descriptions from three people who’ve each only seen one corner of it, and two of them disagree about which direction is north. Once you have felt it a few times, you start to recognise the same shape in every project that’s about to matter.

Early in my career, I thought this feeling meant something was wrong with me. Everyone else in the room seemed so certain. The product lead had a roadmap. The engineering manager had a delivery date already circled on a calendar. Someone from finance had a number that apparently could not move. And I was the one standing at the whiteboard, marker in hand, quietly aware that none of us actually knew what we were building yet — not really, not in the way that would let me draw a diagram I’d still believe in six months from now.

It took me years to understand that this discomfort wasn’t a sign of weakness. It was the job. If the path forward were obvious, they wouldn’t need an architect in the room. They’d need someone to type faster. The reason architecture exists as a discipline at all is precisely because the interesting problems don’t come pre-solved. They come as a tangle — half-formed business goals, contradictory constraints, technology that didn’t exist eighteen months ago, and people who are all, quite reasonably, protecting their own corner of the truth.

I say this not to romanticize discomfort, because there’s nothing noble about being permanently unsettled. I say it because the first real shift in how I handle ambiguity wasn’t a new technique — it was giving myself permission to feel the fog without treating the fog as a failure. Once I stopped fighting the feeling, I had far more energy left to actually think.

One thing I wish someone had told me earlier: ambiguity isn’t one thing. We use the word loosely, but there are at least two very different kinds of “we don’t know,” and confusing them leads to a lot of wasted meetings.

I’ve watched talented engineers burn weeks trying to research their way out of ambiguity of intent — building elaborate proof-of-concepts, gathering more and more data — when what the situation actually needed was a direct, sometimes uncomfortable conversation with a decision-maker who was hoping the problem would resolve itself if left alone long enough. It rarely does. Someone has to name the decision out loud, and often, that someone ends up being the architect, simply because we’re the ones forced to draw something concrete on a diagram eventually.

So the first practical skill in handling ambiguity is diagnostic: before doing anything else, I try to work out which kind of fog I’m standing in. Is this a “we need to learn something” situation, or a “someone needs to decide something” situation? They call for completely different responses, and mixing them up is one of the most common ways architecture efforts stall.

Let me tell you about a project that taught me most of what I know about this. I was brought in to help design the architecture for a system that needed to handle a “significant increase in traffic” — that phrase, verbatim, was the entire brief for the first two weeks.

No number. No timeline. No clear sense of whether “significant” meant twice the load or fifty times the load, which, as anyone who has designed for scale knows, are two entirely different systems with entirely different price tags and entirely different failure modes.

My instinct, the old instinct, was to go build something. Pick reasonable numbers, sketch an architecture, and present it — because presenting something felt safer than admitting we didn’t know enough to design anything yet. I’ve since learned that this instinct, however well-intentioned, is one of the more dangerous habits an architect can have. A confidently drawn diagram, even a wrong one, has a strange gravitational pull. Once it exists, people start planning around it. Budgets get attached to it. And un-deciding something that’s already been drawn is politically far harder than deciding it correctly the first time.

Instead, I did something that felt, at the time, almost embarrassingly simple. I wrote down, in plain language, every assumption I would need to make in order to design anything at all. Not technical assumptions — business ones. What does “significant” mean in a number. What’s the timeline. Is this growth expected to be sudden (a launch, a marketing push) or gradual (organic adoption over a year). What happens if we’re wrong — is a slow system merely embarrassing, or does it cost the business actual money per minute of degraded performance.

What I learned from that project, and have relearned many times since in smaller ways, is that ambiguity often isn’t resolved by working harder in isolation. It’s resolved by asking better, more specific questions of the right person, at the right moment, in a form they can actually answer. “What’s the load going to look like?” is a question nobody can answer off the top of their head. “Are we designing for a scheduled event we know the date of, or for gradual growth we’re guessing at?” is a question almost anyone with context on the business can answer in a sentence.

Over the years, the vague, anxious relationship I used to have with ambiguity has slowly turned into something closer to a set of habits — not a rigid process, because ambiguity resists rigid processes, but a handful of moves I reach for almost automatically now. I’ll walk through them honestly, including where each one has let me down.

None of these habits is dramatic on its own. What makes them work is that they compound. Naming the fog invites better questions, better questions surface intent, surfaced intent makes it clear which decisions are reversible, reversible decisions get made quickly, the doubt around the irreversible ones gets written down, and the team can see the whole picture without drowning in it. Take any one habit away and the others quietly start to fail alongside it.

Here’s what’s harder to say cleanly, but I think is the most honest part of this whole topic: handling ambiguity well doesn’t mean it stops being uncomfortable.

I’ve been doing this work long enough that the discomfort no longer paralyzes me, but I’d be lying if I said it went away. There’s still a specific, familiar unease that shows up whenever I’m asked to commit to a direction with less information than I’d like. I’ve just learned to recognize it as information itself, rather than as a warning sign to be avoided.

What changed, more than the feeling itself, is my relationship to it. I used to treat that unease as a signal that I hadn’t done enough analysis yet, and I’d respond by doing more analysis, often well past the point of usefulness. Now I try to ask a different question when the feeling shows up: is this the kind of discomfort that more information would actually fix, or is this the ordinary, unavoidable discomfort of making a real decision with real consequences? The first kind is worth chasing down. The second kind is just the job, and no amount of additional research will make it feel better — only making the decision, living with it, and being willing to adjust later will.

There’s also a quieter, more personal habit that’s helped me more than any framework: I’ve stopped needing to be the person with the answer in the room. Early on, I thought that was the job — architect as oracle, the person who resolves uncertainty for everyone else through sheer expertise. It’s a nice story, but it’s not true, and chasing it made me worse at the actual work, because it made me reluctant to say “I don’t know” even when saying it would have opened up a much better conversation.

Now I think the job is closer to being the person who’s comfortable enough with not-knowing to keep the room productive anyway — who can hold a question open long enough for the right answer to emerge, without needing to fill the silence with a false one just to relieve the tension.

There’s a real skill in communicating “we don’t know yet” to different audiences without it landing as “we’re lost.” I’ve found the difference usually isn’t in what you say, but in how specifically you say it, and what you pair it with.

Compare these two sentences: “We’re not sure how this is going to scale yet,” versus, “We don’t have production traffic data yet, so we’re designing around three specific load scenarios, testing against the middle one first, and we’ll have real numbers to validate against within two weeks of launch.” Both sentences are honestly describing the same underlying uncertainty. Only one of them sounds like a plan.

I’ve noticed that stakeholders, especially non-technical ones, are far more comfortable with ambiguity than we sometimes give them credit for — as long as they can see that the ambiguity is being actively managed rather than quietly ignored. What erodes trust isn’t admitting uncertainty. It’s vagueness. It’s the sense that nobody is tracking the open questions, that they’ll simply resurface later as surprises.

So when I talk to leadership about an unresolved architectural question, I try to always pair the admission with three things: what specifically is unknown, what we’re doing about it, and by when we expect to know more. That structure alone turns “we’re not sure” from an alarming sentence into a reassuring one.

It would feel dishonest to write this without admitting the ways I’ve mishandled ambiguity, because I think the mistakes teach more than the successes do.

The lesson from the first one wasn’t “never give numbers.” It was: when a number is a guess, say so in the same breath you give it, every single time, even when it’s inconvenient, even when it makes the meeting feel less resolved than everyone wanted it to feel. A guess presented as a guess is useful. A guess quietly promoted to a fact is a liability with a long fuse.

The lesson from the second was harder for me personally. I’ve sat in that kind of stall longer than I’d like to admit, mistaking motion — more diagrams, more research documents — for progress, when what the situation actually needed was a direct, slightly uncomfortable conversation with whoever had the authority to decide. I now try to notice the specific feeling of “this research doc is really a delay tactic” the moment it shows up, and treat it as a cue to schedule the conversation instead.

The lesson from the third has quietly reshaped how I run any project with unresolved questions: every open question gets a name next to it — not to assign blame, but simply so that “who’s chasing this down” is never itself an ambiguous thing. A named owner turns fog from a shared vague worry into something with a clear pair of hands attached to it.

One thing that took me longer to notice than it should have: “handling ambiguity” isn’t a fixed skill you learn once and then carry around unchanged for the rest of your career. It shows up differently depending on where you’re sitting, and I think it’s worth being honest about that, because a lot of advice on this topic is written as if there’s one universal version of the skill.

Early on, when you’re not yet the one being asked

When I was newer, ambiguity mostly arrived as instructions that didn’t quite make sense, and my job was largely to notice the gaps and ask about them without seeming like I was questioning someone more senior. I remember being genuinely afraid that asking “what do you mean by fast?” or “which kind of users are we talking about?” would read as not having done my homework. It took me a while to realize the opposite was true — the engineers who asked sharp, specific questions early were consistently the ones trusted with harder problems later. At this stage, the skill is mostly about noticing fog and having the nerve to say so, in a small, low-stakes way, long before you’re the one expected to clear it.

In the middle, when you start owning the fog directly

Somewhere in the middle of a career, the dynamic flips. You stop being the person who notices ambiguity and start being the person other people bring their ambiguity to. This is a strange transition, because nothing about you fundamentally changes overnight — you don’t wake up with new certainty — but suddenly you’re expected to project enough steadiness that a room full of anxious people can calm down. I found this stage the hardest, honestly, because it’s tempting to fake the certainty you don’t yet have, just to satisfy the expectation. What actually worked better, eventually, was learning to be calm about not-knowing rather than pretending to know — a subtle but important difference I touched on earlier.

Later, when the ambiguity gets bigger and slower

More recently, the ambiguity I deal with has less to do with a specific technical unknown — will this API handle the load, will this database choice hold up — and more to do with slower, organizational unknowns. Will this team still exist in its current shape in a year. Is the strategy behind this project actually stable, or is it likely to shift under us halfway through. These questions can’t be resolved with a spike or a prototype. The only real tool I’ve found for this level of ambiguity is designing systems and teams that can absorb change gracefully, and being honest with myself, more than with anyone else, about which of my current assumptions are actually load-bearing.

I share this progression mostly to say: if the version of “handling ambiguity” you’re currently practicing feels shaky, that’s not necessarily a sign you’re bad at it. It might just be a sign you’re in an earlier stage of a skill that keeps evolving, sometimes for an entire career.

These are the questions people actually ask after reading or hearing me talk about this. Each one gets the same treatment: a straight, non-evasive answer.

Isn’t it an architect’s job to eliminate ambiguity, not sit with it?

I understand the instinct behind this question, but I’d gently push back on it. Some ambiguity can genuinely be eliminated through research and clear thinking — that part is real work, and worth doing well. But a meaningful amount of ambiguity in any interesting project is structural. It exists because the business itself hasn’t decided something, or because the future genuinely can’t be known yet. Pretending that kind of ambiguity can be “solved” through more diagrams just relocates it, usually to a worse moment, later, when it’s more expensive to deal with. The honest job isn’t eliminating all ambiguity — it’s knowing which kind you’re facing and responding appropriately.

How do you decide when you have “enough” information to move forward?

I ask myself a fairly simple, almost blunt question: if I made this decision right now, with what I currently know, what’s the worst realistic outcome, and could I live with it — meaning, could I detect it early and correct it without catastrophic cost? If the answer is yes, I move. Waiting for certainty that isn’t coming is its own kind of risk, one that’s easy to underweight because it doesn’t show up as a dramatic failure, just as slow, quiet, expensive delay.

Doesn’t constantly admitting uncertainty undermine people’s confidence in you as an architect?

In my experience, it’s the opposite, over time. What actually undermines confidence is being confidently wrong, repeatedly, in ways people eventually notice. Being calmly honest about what’s unknown, while still being decisive about what to do next, tends to build a much sturdier kind of trust — the kind that survives being wrong occasionally, because you were never pretending to a certainty you didn’t have in the first place.

What’s the difference between handling ambiguity well and just being indecisive?

Indecision, as I’ve come to understand it, is staying open on a question after you have enough information to close it — usually out of discomfort rather than genuine need for more input. Handling ambiguity well is the opposite instinct: closing questions as early as they can responsibly be closed, and being visibly deliberate about the ones that genuinely can’t be closed yet. The difference isn’t really about how long you take. It’s about whether the delay is doing useful work.

Do you have a go-to first move when you walk into a genuinely ambiguous problem?

Almost always, yes — I write down what I currently believe to be true, in plain sentences, even the assumptions that feel too obvious to state. It’s a small habit, but it’s remarkably effective, because at least a third of the time, someone else in the room reads that list and quietly corrects one of the “obvious” assumptions. Getting that correction on day one, instead of week six, has probably saved more project time than any other single habit I’ve picked up.

How do you keep ambiguity from turning into stress that follows you home?

Imperfectly, if I’m honest. What helps most is having a clear, almost boring answer to the question “have I done what I reasonably can today to move this forward?” On the days I can answer yes, I find it much easier to let an open question stay open overnight without it gnawing at me. The stress I can’t shake is usually a sign that I’m avoiding a specific conversation I know I need to have, rather than a sign that the ambiguity itself is unusually severe — and recognizing that pattern has, over time, made the open questions feel a lot less heavy to carry.

If I’m ever asked that original question again — how would you describe handling ambiguity as an architect — I don’t think I’ll reach for the tidy, rehearsed version anymore.

I think I’ll say something closer to this: ambiguity isn’t a problem I solve once and move past. It’s the weather I work in. My job isn’t to make the fog disappear before I start walking — it’s to walk anyway, carefully, honestly, asking better questions along the way, choosing paths I can still adjust if the ground turns out different than expected, and telling the truth the whole time about what I can and can’t yet see.

What’s changed most, over the years, isn’t my tolerance for discomfort. It’s my respect for it. I’ve come to believe that the discomfort of not-knowing, sat with patiently instead of rushed past, is where the actually good decisions come from — the ones that hold up, the ones nobody has to quietly walk back six months later. The architects I admire most aren’t the ones who always seem certain. They’re the ones who are honest about uncertainty and steady anyway, who can say “we don’t know yet, and here’s exactly what we’re doing about that” without their voice shaking, and who somehow make everyone else in the room feel a little calmer for having said it.

I think that’s really what the interview question is quietly asking, underneath the polite phrasing. Not “do you have a process for ambiguity,” because everyone can recite one. What it’s really asking is whether you can be trusted in the room when nobody has the answer yet — whether you’ll fill the silence with false confidence, freeze until someone else moves first, or stay steady enough to help the group find its way through, one honest, well-placed question at a time.

That, more than any framework I could hand you, is the real answer.