Being Trusted With Ambiguity

Being Trusted With Ambiguity is the threshold where work stops arriving as tickets. The problems that matter most to an organisation are the ones nobody has yet turned into a task, and they get handed to specific people for specific reasons. Those reasons are behaviours rather than traits, which means they can be practised.

Key takeaways

• Ambiguous work is work with no agreed definition of done. The scarce act is not solving it, it is converting it into something decidable, and the conversion is the deliverable.
• Undefined problems are assigned to whoever last converted one successfully and left a written trace of the conversion. Nobody assigns a vague problem to someone whose reasoning they have never seen.
• Framing comes before planning. A plan for the wrong problem is worse than no plan, because it is convincing and it consumes the review attention that would have caught the mistake.
• Choose a reversible first step, and say out loud that it is reversible. That sentence is what makes senior people comfortable letting you proceed without a defined answer.
• Stating what you do not know is a strength signal rather than a weakness signal. IBM Research's January 2026 study of 57 enterprise developers, one organisation only, found they preferred expressed uncertainty over confidently incorrect output, and Stack Overflow's 2025 survey found the top reason to ask a person, at 75.3%, was not trusting an AI answer.

Read this after Chapter 7, because the reviews and records you leave are the trace that gets you offered this work, and before Chapter 10, which is what happens when the ambiguity you are trusted with grows past what you can hold yourself. Chapter 9 is the sibling question of whether your organisation has any ambiguity worth being trusted with.

A meeting ends without an owner. Support has escalated a complaint that checkout feels slow, revenue has noticed a dip in one segment, and the dashboards say the p95 latency is fine.

Three people could take it. One says it needs proper investigation and nothing happens. One volunteers, spends a week reading traces, and reports that the situation is complicated.

The third comes back in two days with a sentence: for logged-in customers with more than fifty saved items, the cart page makes forty-one sequential calls, and here is the one measurement that shows it. She is now the person that class of problem gets given to. The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

Ambiguous work is work with no agreed definition of done

The distinction that matters is not difficulty. A hard problem with a clear finish line is not ambiguous, and an easy problem nobody has defined is.

Ambiguity has three usual sources. The desired outcome is contested, meaning two stakeholders want different things and neither has said so. The cause is unknown, meaning the symptom is real and the mechanism is not identified. Or the constraints are unstated, meaning nobody has said what may not change.

Each source needs a different first move, and confusing them is the common error. Contested outcomes need a conversation, unknown causes need a measurement, and unstated constraints need somebody to write down assumptions and circulate them for contradiction.

So the first thing to do with an ambiguous problem is classify which kind of ambiguity it has. That takes ten minutes and saves a week of solving the wrong shape.

What ambiguity is actually made of

There is a published account of what experienced practitioners think their own irreducible work consists of, and it maps onto this chapter almost exactly.

Anthropic's Economic Index report of 26 June 2026, drawing on roughly 9,700 linked survey respondents, records that workers with 15 or more years of experience judge AI can handle a smaller share of their tasks than first-year workers do. Asked why, they point to judgement, contextual awareness, situational reasoning, and the relational and interpersonal dimensions of the work. That is self-reported perception from a model vendor's own survey, as Chapter 1 said. It is not a measurement of capability.

Read the four categories as a description of ambiguous work rather than as a defence of seniority. Contextual awareness is knowing which constraints are real here. Situational reasoning is knowing which of five plausible causes fits this evidence. The relational part is finding out what the two stakeholders actually want.

That is why ambiguity resists delegation to anything, human or machine, that does not hold the context. It is not that the reasoning is too hard. The inputs are not written down anywhere.

How an undefined problem finds a specific desk

This is judgement rather than a citation, and it is the claim in this chapter I would most expect an argument about.

What I have seen is that undefined work goes to whoever last converted an undefined problem into a decidable one, in a way other people could watch. Not to the strongest engineer, and not to whoever has capacity. The mechanism is risk transfer: handing a vague problem to someone is a bet that they will come back with something usable rather than with a request for clarification, and people only make that bet on evidence.

Which means the trace matters more than the outcome. A written narrowing of a problem you did not fully solve builds more of this reputation than a quiet solution to something hard, because the narrowing is visible and the solution is not.

My read, and it is a read: this is why the artifacts in Chapters 6 and 7 have outsized career effects. A specification and a decision record are both public evidence that you can take something shapeless and make it decidable, which is exactly the capability being bet on.

Framing is the first deliverable, and it is not a plan

The most common mistake with ambiguous work is producing a plan too early.

A plan answers what we will do. A frame answers what question we are answering, what would count as an answer, and what we are choosing not to consider. Framing is cheap, reversible and easy to correct in a five-minute conversation. A plan is none of those, because once it exists people start scheduling against it.

The specific danger of an early plan is that it is convincing. It has steps and dates, so it draws attention to whether the steps are right and away from whether the goal is. The wrong problem, planned well, absorbs a quarter.

So the first artifact I would produce for any ambiguous problem is half a page: the question, the evidence that it is real, what would count as done, and what is explicitly out of scope. Circulate that before writing anything else.

Narrow until one week is decidable

Ambiguity gets resolved by narrowing rather than by thinking harder about the whole thing.

The test I use is whether one week of work can be judged as having succeeded or failed at the end of it. "Improve checkout performance" fails the test. "Establish whether the saved-items query is the cause of the p95 tail for accounts with more than fifty items" passes it, because in a week you will know.

Narrowing feels like a reduction in ambition and it is the opposite. A narrow first question that gets answered produces both a result and a much better second question, whereas a broad question produces a status update.

There is a discipline to it. Narrow along the axis of evidence rather than along the axis of convenience: pick the sub-question whose answer most changes what you would do next, not the one that is easiest to attack.

The reversible first step buys the right to proceed

The reason senior people hesitate to hand over undefined work is not doubt about ability. It is that undefined work has undefined blast radius.

Removing that objection is mechanical. Choose a first step that is reversible, and say so explicitly in the sentence where you ask to proceed. Measurement is reversible. Adding instrumentation is reversible. Writing a document is reversible. A schema change, a data migration and a public interface change are not.

The sentence to use is short: my first step is to measure X, which changes nothing and takes two days, and after that I will know whether the expensive option is needed. Almost nobody refuses that.

In my experience this single habit does more for how much latitude you are given than any amount of demonstrated technical skill. It converts you from a risk into an option.

Say what you do not know, in writing

The instinct under ambiguity is to project confidence, and it is precisely wrong.

There is indirect evidence for the preference. IBM Research's January 2026 study of enterprise developers found that they valued correctness above all other properties and preferred output that expressed its own uncertainty over output that was confidently incorrect. The sample was 57 developers inside a single organisation, so this is a first-party account rather than a general rate.

I would extend it to humans as an argument rather than a finding. The people I trust with ambiguous work are the ones whose status updates separate what they have established from what they are assuming, because that separation is what lets me help without redoing their work. Stack Overflow's 2025 survey, with 49,034 respondents, points the same way from the other direction: the top reason developers give for asking another person, at 75.3%, is not trusting an AI answer. Uncertainty is what gets escalated to people.

So write the unknowns down as a standing section. Three lines under every update: what is established, what is assumed, what would change the plan.

The honest status report

Status reporting under ambiguity is where reputations are actually made, and there are three shapes to choose from.

The third shape has a property the other two lack. When it turns out badly, the record shows you named the assumption that failed, which is the difference between a bad outcome and a bad judgement.

The objection: this is extra responsibility for the same title

The objection is fair, and the honest answer has a real limit in it.

It runs: converting ambiguity is senior work, it carries risk, and doing it without the title or the compensation is being taken advantage of. That happens, and it is not paranoia. There are organisations that consume this work indefinitely without ever changing anyone's role, and Chapter 9 is partly about detecting them before you join.

Two things make it not a trap. The first is that the artifacts are portable: a frame, a narrowing, a measurement and a decision record are evidence you can show elsewhere, unlike internal goodwill. The second is that ambiguity work is how thresholds are actually crossed, because no promotion committee has ever been persuaded by someone who only ever completed defined tasks well.

The limit is real though, and I would state it plainly. If you have done this three times, left a written trace each time, and nothing about your scope has changed, the problem is the organisation rather than your evidence. That is information, and Chapter 9 is what to do with it.

Chapter summary

Ambiguous work is work with no agreed definition of done, and difficulty is not what makes it ambiguous. Its three sources need different first moves: contested outcomes need a conversation, unknown causes need a measurement, and unstated constraints need written assumptions circulated for contradiction. Anthropic's June 2026 index reports that workers with 15 or more years of experience judge AI can handle less of their work, attributing that to judgement, contextual awareness, situational reasoning and relational dimensions. That is perception rather than measurement, and also a decent description of what ambiguity consists of. Undefined problems get assigned to whoever last converted one visibly, because handing over a vague problem is a bet that the person returns with something usable. Framing precedes planning, since a plan for the wrong problem is convincing and absorbs a quarter. The first artifact is half a page naming the question, the evidence that it is real, what counts as done and what is out of scope. Narrowing is the resolution mechanism, tested by whether one week's work can be judged succeeded or failed. A reversible first step, named as reversible, removes the objection that undefined work has undefined blast radius. Writing down what you do not know is a strength signal, supported indirectly by IBM Research's finding from 57 developers in one organisation that expressed uncertainty was preferred to confident incorrectness. And of the three status-report shapes, only the honest one survives being wrong.

Chapter 9 asks the question this chapter kept deferring. Choosing Problems and Choosing Companies is about whether the organisation you are in can compound judgement at all, because the same behaviour that earns latitude in one place is absorbed without trace in another.