Judgment Under Pressure

Judgment is a short list

FDE job posts ask for judgment, and almost none says what it is. OpenAI's FDE posting asks candidates to "Simplify complexity and make fast, sound decisions under pressure" and to "Model calm and judgment when the stakes are high". Its posting for the manager of an FDE team adds "Use judgement to distinguish what requires action and what does not". Glean wants "Builder's judgment", meaning knowing "when to simplify scope to get something real into production faster". The postings are in the box below. As evidence of how the job is done they are T4: they describe what the company hopes for. As evidence of what employers ask for they are primary.

That is the sceptic's opening, and it should be taken seriously. "Judgment" is the word an industry uses for the part of a job it cannot measure. It is claimed by everyone who survived a hard engagement, and no study links it to outcomes. This book's research found no data on which FDE behaviours predict a successful engagement. The best T2 material in this chapter comes from Stanford's study of successful enterprise AI deployments. Those are successful AI projects, some of them rescues, not studies of FDEs, and the study chose successes on purpose. The rest is T1 interview research on why AI projects fail, one T3 summary of a vendor talk, and T4 practitioner accounts and job posts. Treat what follows as a practitioner's argument built on that evidence, not as a finding.

The argument still has to be concrete enough to be wrong. Here is the claim. Judgment, in this job, is knowing which commitments are load-bearing: the ones that, if they give, take others down with them. There are four: the threshold, the data path, the sponsor and the exit. Almost everything else can be traded, and trading it freely is how you earn the standing to refuse on those four. An FDE who fights for every feature and every date has no credit left when the threshold is the thing under attack. This is the behaviour The Skill Map puts at L3 in the judgment domain: saying no to a sponsor, making it stick, and knowing which commitments carry the load.

The four load-bearing commitments

Each of the four protects something the others depend on. The test for whether a request touches one is simple: if you agree to it, which other promise in the engagement stops being true?

Readers of Chapter 13 will recognise most of this. That chapter used five conditions to diagnose an engagement that is already failing. This chapter is about the minute before the diagnosis: a meeting in which someone with authority asks you to give one of these up, nicely, for a good reason, and wants an answer now. Two of Chapter 13's conditions, a problem that matters and an owner for the result, are things you find. Three of these four, the threshold, the data path and the sponsor, are among Chapter 13's conditions; the exit is the promise behind its "no owner" test. All four are things you promise or extract, and so they are the ones you can be talked out of.

The threshold: its value is negotiable, its existence is not. The bar belongs to the customer, and a customer can rationally set it lower than an engineer would like. Stanford's study quotes the president of a logistics company: "Look guys, 80% is perfect for us… I understand that you can keep improving and at one point the model is going to be 95%, but we don't care. What we care is immediate cost saving and getting rid of these backlogs" (Pereira, Graylin and Brynjolfsson, The Enterprise AI Playbook, 2026; T2, self-reported interviews, in a report marked draft). That is a legitimate decision by the person who owns the result. What an FDE must not allow is the bar going missing: replaced by "let's see", or quietly moved by the vendor to fit the result. The judgment is to tell those two apart. A lower number, written down by its owner, is a decision. A number that nobody will write down is the start of the slow fade.

The sponsor: priorities move, so the line to the number must not. When Engagements Fail quotes RAND's interviewees on leaders who "rapidly switch their priorities every few weeks or months" (RAND RR-A2680-1, 2024; T1 as interview research with 65 practitioners, which measures what they report rather than project outcomes). The same report adds a line that matters more here: "Even when the project is successful, leaders may direct the team to move on prematurely." An FDE cannot stop a sponsor's priorities moving. An FDE can refuse every arrangement that lets the sponsor stop hearing the number, because a sponsor who still reads the number has to decide to move on, and a sponsor who has been shielded from it drifts. The concrete move is small: the weekly note goes to the sponsor by name, never only to a delegate, and it carries the bad weeks as well as the good.

What a rescue changed, and what it did not. When Engagements Fail told Stanford's recruiting rescue as a reset: a new owner, the process fixed first, real pain. Read it here for what the second attempt left alone; the report's verdict is "The difference was not the technology" (Stanford, T2; results self-reported, in a report marked draft). Across its cases the study says "The technology was consistently described as the easiest part." The rescue changed the load-bearing things and left the rest alone. Weak rescues do the opposite: a new model, the same missing owner.

What is negotiable. Nearly everything that feels urgent in the room: the date of a demo, the order in which failure categories are attacked, what the queue view looks like, which model or framework, the format of the weekly note, extra sessions with users, a narrower first slice, a later re-measure date that is still before the next invoice. Give these away readily, out loud. "Yes, we can move the demo; no, we can't drop the number" is easier to hear than a list of refusals.

The composite: four requests in one meeting

Three refusals, each naming the commitment it protected; one concession that was hers to make, not the FDE's; and three yeses that cost almost nothing. The yeses carried the meeting. Without them, three refusals in a row would have sounded like a vendor protecting itself.

How to say no so it holds

Sierra's posting for a flagship deployment strategist puts the job plainly: "At this scale, every big technical discussion is also a negotiation — you'll need to read the implications in real time, hold your ground, and steer toward the right outcome" (Sierra posting, September 2026; T4). Holding your ground is the easy half. The hard half is a refusal the other side can live with, which in practice has five parts, in this order:

1. Name the commitment it would break, and where it is written: "Write-back would change what model risk approved in week 3."
2. Say what it would cost them, in their terms. Not "our security posture" but "the audit sign-off your go-live depends on would have to start again."
3. Offer what you can do instead, this week. A refusal with nothing attached reads as indifference.
4. Give the trigger that turns it into a yes. Measurable, not "when it's ready": the threshold met on real data, and the target system's owner approving a change, not just a read.
5. Say who can overrule you, and how. Usually someone on their side, in writing. This is what makes the refusal principled instead of territorial.

Say it in the meeting, then write it down within a day, to the person who asked and copied to whoever owns the commitment. A verbal no is re-asked next week by someone who wasn't there. A written one becomes part of the engagement record, and the trigger in it becomes the plan. Scoping's "not now" list does this for scope. The say-no note does it for the four commitments, which should never be parked on a list without a stated condition.

The sceptic's objection. A vendor's "no" is not neutral. The same Sierra posting asks the strategist to "Drive financial success for both the customer and Sierra", and to "manage down cost to serve over time, improving margins". Read cynically, "hold your ground" means protect the margin. The opposite failure is the sceptic's favourite, the FDE job that turns out to be IT services; What an FDE Is gives the disappointed hires' accounts. That complaint was about the work, not about refusals, but an FDE who says yes to every request ends up doing exactly that work. Both failures are real. One test separates a load-bearing no from a commercial one: would you refuse the same request if the customer were paying for every hour it took? Write-back that voids the security sign-off would be refused at any price: that is a load-bearing no. A second dashboard would be built gladly if paid for, so refusing it was about cost, and cost should be priced openly, not dressed as principle.

"Can you promise it will never…?"

The commonest request an FDE cannot grant, and the one most often granted anyway, is a guarantee of behaviour: it will never route a litigation claim to the fast queue, never give investment advice, never say the wrong figure. The request is reasonable. Regulated businesses are built on promises like that. The answer has two halves, and you need both.

Promise in code what code can enforce. A rule that must hold every time does not belong in a prompt. Building in Their Environment covers the practice: write the rule as ordinary code that runs before and after the model, test it on every change, and require it to pass every time rather than score well. In the composite the litigation guardrail is a small piece of ordinary code, and the FDE can promise it outright, because the model cannot reach it.

Promise a measured rate and a verification path for everything else. The model's own behaviour can be measured, not guaranteed. The best public account of handling that honestly is Morgan Stanley's wealth-management assistant, built with OpenAI, whose weeks of build and months of trust-building Production and Handoff covers. What matters here is why: the summary of Colin Jarvis's account ties the trust period to "regulated financial environments where accuracy requirements are high and the technology is probabilistic", and says the FDE team built "verification tools for cases where confidence was lower" (ZenML LLMOps Database; T3, a secondary summary). The same summary repeats an adoption figure that matches OpenAI's own published number, a possible echo, so it is left out here.

What that case shows is the shape of a promise that holds: not "it will never be wrong" but "here is how often it is wrong on cases your experts labelled, here is what happens to the cases it is unsure of, and here is who checks". The judgment call is refusing the guarantee in the first meeting, when refusing is cheap. A guarantee given to win the pilot becomes the threshold by default, and it is one no eval can meet.

A useful sentence for the room: "I can promise the rules, because they are code. I can't promise the model, so I'll promise you a measured rate on your cases and a person on every case it isn't sure of."

Not every alarm needs action

Pressure does not only come from sponsors. It comes from the failure log, the latest complaint, the user who forwarded a bad output to three directors, and the new model release everyone on your own team is excited about. OpenAI's manager posting names the skill: "distinguish what requires action and what does not" (T4). The distinction is again about load. A bad output that breaks a rule the customer was promised requires action today. A bad output inside the measured rate requires a case in the development set and a place in the fix queue, not a hotfix.

The cost of treating every complaint as urgent is documented, though only by a practitioner. Hamel Husain's account of Rechat's assistant, Lucy, describes the pattern: as its scope grew, "the performance of the AI plateaued", and "Addressing one failure mode led to the emergence of others, resembling a game of whack-a-mole." Prompts "expanded into long and unwieldy forms, attempting to cover numerous edge cases and examples" (Husain, Your AI Product Needs Evals, March 2024; T4, a consultant's account of his client). The way out was a system rather than another patch: hundreds of assertion-style tests, trace logging with a review tool, human review of samples, and fine-tuning, which "resolved many failure modes… that were not possible with prompt engineering alone". The post reports no overall outcome figure, so treat it as a description of a method, not proof that it worked. Its first half, though, is the pressure pattern every FDE will meet: each urgent fix made the next failure likelier.

The FDE's own enthusiasm is the other source. RAND found that 16 of its 50 industry interviewees described failures driven by the data scientists on the team rather than by leadership, and its recommendation is blunt: "Chasing the latest and greatest advances in AI for their own sake is one of the most frequent pathways to failure" (RAND, T1). A new model is a negotiable: you may switch to it, but only through the regression suite and the held-out re-measure, on the eval plan's dates. A switch that skips those has quietly moved the threshold and the data path at once.

A working rule for the week: act today on anything that breaks a promise in code or touches one of the four commitments. Everything else goes into the failure log, gets categorised, and waits for the largest category to be attacked first. Tell the threshold owner this rule before the first angry email.

Who backs your no

A refusal is only as strong as the reporting line behind it. An FDE who reports into sales and refuses a request that would close a deal is refusing their own boss's number. One who reports into engineering or product has cover, and may be seen by the account team as an obstacle. The judgment is to know on day one which it is, and to agree with your lead which of the four commitments you may refuse alone and which go to the lead first. A sensible default: the data path and the guardrail, alone and immediately; the threshold, the sponsor and the exit, through the lead, the same day.

The same question applies in China, where the job family a role is filed in is a clue to its reporting line; What an FDE Is gives the filings. The practical point is the same in either market: before the first engagement, ask your lead whose number a refusal would cost, and agree the split above before a customer tests it.

The template: the say-no note

One request per note, sent within a day of the meeting, to the person who asked and copied to the owner of the commitment. Keep it to a page: a long refusal reads as a defence.

SAY-NO NOTE                                  date: _______________
To: ______________ (who asked)   Cc: ______________ (who owns it)

1. THE REQUEST (in their words, as asked)
   ________________________________________________________________

2. THE ANSWER:  no  |  not now  |  yes, if ______________________

3. THE COMMITMENT IT WOULD BREAK (tick one)
   [ ] threshold   [ ] data path   [ ] sponsor   [ ] exit
   Where it is written: ___________________ (document, date)

4. WHAT IT WOULD COST YOU (their terms, not ours)
   ________________________________________________________________

5. WHAT WE WILL DO INSTEAD (by when)
   - ______________________________________________  by: _________
   - ______________________________________________  by: _________

6. WHAT TURNS THIS INTO A YES (measurable trigger)
   ________________________________________________________________

7. WHO CAN OVERRULE THIS, AND HOW
   Decider: ______________  How: in writing, amending ____________

8. REVIEW DATE: ____________   Logged on "not now" list: yes / no

Test before sending: would we refuse this if every hour were paid?
   yes: send it     no: it is a price, not a no; quote it instead

Filled from the composite, for the first of the four requests. Figures are ranges or relative dates, as the composite rules require.

SAY-NO NOTE                                  date: month 2, day of
To: claims director              Cc: model-risk manager;
                                     claims-system owner; the lead

1. THE REQUEST (in their words, as asked)
   "For the claim types that already route well, write the routing
   straight into the claims system so adjusters stop re-keying."

2. THE ANSWER:  not now; yes, if the conditions in 6 are met

3. THE COMMITMENT IT WOULD BREAK (tick one)
   [ ] threshold   [x] data path   [ ] sponsor   [ ] exit
   Where it is written: model-risk approval, week 3 (propose only,
   read-only identity); replica read access, approved week 3

4. WHAT IT WOULD COST YOU (their terms, not ours)
   Model risk's approval covers suggestions, not writes. A write
   path restarts that review, and go-live waits on it. Claimant
   documents can carry text aimed at the agent; today the worst
   case is a wrong suggestion an adjuster rejects.

5. WHAT WE WILL DO INSTEAD (by when)
   - show the agent's one-line reason in the queue view,
     so accepting a suggestion is faster            by: next week
   - move your adjusters' top complaint category
     to the front of the fix list                   by: this week
   - add accept / override counts to the weekly
     note, per claim type                           by: next note

6. WHAT TURNS THIS INTO A YES (measurable trigger)
   All four: threshold met on the held-out set; claims-system owner
   approves a write change, not a read; every write traceable and
   reversible; adjusters have used suggestions long enough to
   trust them (override rate stable for some weeks).

7. WHO CAN OVERRULE THIS, AND HOW
   Decider: model-risk manager, with the claims-system owner
   How: in writing, amending the week-3 approval

8. REVIEW DATE: first readout after go-live
   Logged on "not now" list: yes

Test before sending: would we refuse this if every hour were paid?
   yes: send it     no: it is a price, not a no; quote it instead

Three things in the filled note are deliberate. Section 4 never mentions the vendor's risk, only the claims director's go-live. Section 6 restates the four conditions for earning write-back from Data Access and Integration, so the trigger was set before anyone asked. And the decider in section 7 is not the FDE: the note hands the decision to the people who own the approval, which is why it is a statement of fact and not a personal refusal.

Signals you are negotiating the wrong thing

Each of these shows up in ordinary weeks, and each means the line between load-bearing and negotiable has slipped.