The Non-Fatal Override
If it isn't fatal, let them run it — but log your skepticism first so the outcome teaches both of you
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 90%
Dylan Field's protocol for handling disagreement with his own team. The gate is severity, not conviction: if the decision is not going to be fatal, the person who wants it gets to run it, even when Field disagrees. But he does not silently defer — he states the disagreement, names precisely what he is skeptical of, and then commits. This gives the team autonomy and gives the org a clean learning signal, because the prediction was recorded before the result was known.
Origin
Field's own described operating style at Figma, articulated when asked what actually changes his mind and how people influence him. It is a stricter, more explicit variant of the disagree-and-commit norm.
Core principles
- 01Filter by fatality, not by whether you agree. Non-fatal = they decide.
- 02Deference without stated skepticism wastes the learning; say what you think will go wrong.
- 03The more concrete the artifact, the better the debate — abstractions cannot be argued with.
- 04'Go find the answer' is a valid response to unanswered questions, but it must not bottleneck the org.
- 05Trust is built by being overridable in public, repeatedly.
How to run it
- 1
Demand a concrete artifact
When someone brings a proposal, push for the most concrete form possible — Field says the more concrete an artifact is, or the more you can debate something, the better. He asks for examples constantly.
Pro tip In a design tool company this is literal: make them show the thing, not describe it.
- 2
Ask follow-up questions until you understand from first principles
Interrogate the proposal until you understand it fully. If questions surface that have no answer yet, send them away with 'go find the answer to these questions, then let's come back to this' — but only for decisions that genuinely matter.
Pro tip Field is candid that this can read as dense or obstructive, and that sometimes the other person is right and simply returns with the data. Let them.
Watch out Only escalate to this level for important decisions. Field's own guardrail: it works 'as long as you make sure it's not bottlenecking the organization.'
- 3
Apply the fatality test
Ask a single question: is this going to be fatal? If it is not fatal, the disagreement does not entitle you to the decision. If it IS fatal, you are entitled to block it.
Pro tip Fatality, not reversibility, is the bar — this is a wider grant of autonomy than a one-way/two-way door test.
- 4
Say 'go with it' — and record your skepticism
Give the green light explicitly, then attach the disagreement: here's my feedback, here's what I'm skeptical of, let's see what happens. The skepticism is stated up front, not retrofitted after the outcome.
Pro tip This is what makes the override honest. The team gets the decision AND your real model, so they can watch for the failure mode you named.
Watch out Do not turn the recorded skepticism into an I-told-you-so. Field notes his team is usually 'pretty polite about it' when they come back proven right — the norm cuts both ways.
- 5
Let reality settle it and update publicly
When they come back with the data or the outcome, move on. Field: 'they come back and they're like okay here's the data now can we move on — and we do, we move on, and they're right.'
In the wild
Field had — and still has — deep skepticism about Pages, believing it is not the most elegant solution within the whole system of product design. The world and the team told him it did not matter and users needed pages. It was not fatal, so it shipped.
→ Figma shipped Pages and is not unshipping them. Field kept his stated skepticism on record without blocking the team.
A new director of engineering joined Figma and, in week one, presented a deck saying: here's what we have to do, here's the gap, everyone agrees on it, let's go. He told the team they were really close and needed to ship.
→ He catalyzed Figma's launch. A new hire's concrete artifact overrode the founder's inclination to keep polishing.
Common mistakes
Blocking on conviction rather than fatality
Leaders who veto whenever they disagree strongly train their org to stop bringing proposals. The only legitimate veto is 'this could kill us'.
Deferring silently
Saying 'sure, go ahead' while privately expecting failure deprives the team of your model and deprives the org of a testable prediction. State the skepticism or don't grant the override.
First-principles questioning as a stall tactic
Field admits that endless follow-up questions can look like density and can bottleneck the organization. Rigor that never converges is just a block wearing a lab coat.
Is it for you?
Best for
Founders and senior leaders with strong product opinions who are becoming a decision bottleneck and need a severity-based rule for when to defer
Not ideal for
Genuinely fatal decisions — irreversible bets on security, compliance, brand-destroying moves — where the fatality test correctly returns a veto
From the transcript
“I like build trust with people in deep ways and I think across our organization if things are not going to be fatal then if…”
“think we should do X then I'll say okay just go with it and here my here's my feedback here's what I'm skeptical of let's…”
“I think the more concrete and artifact is or the more you can debate something the better uh I like ask for examples a lot”
“my response might be what's go find the answer to these questions and”
“as long as you make sure it's not bottlenecking the organization”
From the episode
Dylan Field live at Config: Intuition, simplicity, and the future of design