Saying no
Pick not yet, not us or not like that, cost a week-3 request that adds six weeks, and decline it in the room without losing the sponsor or the date.
On this page
Week 3 of 8, and the VP of Claims asks, in the Friday meeting, whether the pilot can cover the travel line as well. Every request has a yes-shaped answer, and most engineers give it, because the sponsor is in the room and the request sounds like interest. A no has three shapes; each of them keeps the sponsor, and only one of them is right for a given request.
Three kinds of no
Not yet. The request is a good idea and belongs after the week-8 date. The sentence is "yes, in phase 2, which starts the week after the result, and here is what it needs". It comes with a date and a cost, so the sponsor hears a plan rather than a refusal. This is the no for anything that would move the date the renewal case depends on.
Not us. The request is outside what the product does or what the engineer's company will support after week 8: a custom reporting dashboard, an integration with a system the customer is replacing next year, an on-call commitment. The sentence is "that's not something we'd be the right people for; here is who would be". It names the alternative, because a bare "not us" reads as "not interested".
Not like that. The request conflicts with the definition of done: it would reduce agreement, add an action the model should not take, or put personal data where it should not go. The sentence is "we can reach the number you're after, and this is the shorter way", followed by the alternative. This is the no from the kickoff that asked for a chatbot: the outcome stays, the build changes.
The three are told apart by one question: does the request change the date, the scope of support, or the definition of done? The travel request changes the date.
The week-3 request, costed
Travel is a different line: about 400 claims a day, a 520-page wording set that is not the one indexed, and it would need the same two senior handlers to label it, since the floor has no other reviewers senior enough. Costed week by week:
- Getting the second wording set out, chunked and indexed, with the extraction pipeline from data plumbing re-pointed: one week, mostly waiting for the export.
- Building the eval: 200 cases, two reviewers, 11 minutes each, about 73 reviewer-hours. At two and a half hours a day each, the two reviewers need 15 working days, three weeks of calendar for one week of engineering, and the 25-odd disagreements get adjudicated inside that.
- Prompt and retrieval iteration against the new eval to reach 95%: one week; the pilot took two, but the prompt's shape carries over.
- A shadow run on the new line: one week minimum for an agreement reading on live claims.
Six weeks on the calendar, and the binding resource is not the engineer: it is the reviewers. The pilot's remaining labelling depends on the same senior-handler time, so accepting the request in week 3 moves the week-8 date to week 14 and risks the pilot's 95% as well.
The number to say in the room is the date, not the week count. "That moves the result you're taking to the COO from week 8 to week 14" lands; "it adds six weeks" invites a negotiation about the six.
Declining it in the room
The exchange takes two minutes, and the page that follows it takes an hour.
In the room: "Yes, and not yet. Travel is a second wording set and a second eval, and the eval is the part that takes the time: about 73 hours of your senior handlers' labelling, which they can't give until the triage set is finished. If we start it in week 3, the triage result moves from week 8 to week 14. I'd rather give you the triage number on the date you've promised the COO, and start travel in week 9 with its eval set being labelled from week 7. I'll send you the plan with dates by tomorrow."
Three things are in that paragraph. The outcome the sponsor cares about is named: the date and the number he promised upward. The cost is in the customer's units: reviewer-hours, not engineering weeks. And the alternative is dated: phase 2 starts week 9, labelling starts week 7, so the sponsor leaves with a plan that has the second line in it.
The page the next day has the six-week arithmetic, the two dates side by side, the reviewer-hours, and the one decision he has to make: keep week 8 with phase 2 from week 9, or move to week 14 with travel included. Sales gets the same page the same day, because a scope conversation with the sponsor that sales hears about later is how an account team splits.
What you do not do is accept in the room and re-plan afterwards. A week-3 yes with a week-5 "actually" costs more than a week-3 no, because it is the sponsor who then has to walk back a promise.
When the answer is yes
Sometimes the request is the deal. If the sponsor says "the COO is only interested if it works across lines; the triage floor alone won't get signed", the request has just changed the definition of done, and the answer is "then let's re-scope". Re-sign the scoping doc with the new date, cut what can be cut from the pilot (the volume gate from 90% to 80%, the p99 line unchanged), tell sales the same afternoon, and re-score the deal: decision criteria just moved, and so did the metric.
The signal that separates this from the ordinary request is where it comes from. A request that arrives with the economic buyer's name attached is a scope change. A request that arrives from a Friday meeting is a feature, and features go in phase 2.
In an interview
The customer-scenario round is frequently this request, sometimes with the sponsor pushing back twice. What is being tested is whether you can hold the date without holding a position: say which kind of no it is and why, cost it in the customer's units, and offer a dated alternative, the way communicating trade-offs has you reject an option by naming what it costs. Then show that you know when the answer becomes yes: when the request comes from the person who signs.
The mistake that loses points is the yes-shaped answer: "we could probably fit that in". The interviewer hears an engineer who will be at week 11 of an eight-week pilot explaining to a sponsor why his COO meeting has no number in it.
Check yourself
1. In week 3 the champion asks for a "confidence score" next to each triage result, half a day of work. Which no, if any?
None of them; it is a yes, with one condition. Half a day does not move the date, it changes nothing in the definition of done, and it is the champion asking for something that helps the handlers trust the output. The condition: the score is shown, not acted on, until the eval says what a 0.7 means on their 200 cases. Say yes in the room and put the condition in Friday's update.
2. The sponsor asks the model to auto-approve claims under a value band, skipping the handler, from week 6. Which no?
Not like that. The definition of done has a handler on every decision, and 95% agreement still leaves five decisions in a hundred that differ from the handler's; each one that should have gone to a person becomes an approval nobody looked at. Offer the outcome he wants, throughput on low-value claims, a different way: route the band to a fast lane where the handler confirms in one click, measure the time, and revisit auto-approval in phase 2, when that band clears the run gate in crawl, walk, run: four weeks of walk with 97% of its records accepted unchanged.
3. Sales has already told the sponsor yes to the travel line before you heard about it. What now?
The date still moves, so the sponsor still has to choose; the only change is who tells him. Send sales the one page first, the same day, with the two dates and the reviewer-hours, and ask them to carry it, since they made the promise. If they will not, you say it in the next meeting with sales in the room. The number does not change because of who said yes.