It is rarely the first request that breaks a sprint. The first request lands inside the budget you imagined for yourself when you wrote the plan, and you accept it the way you might accept a small favor from a colleague — a little inconvenient, but the kind of inconvenience that working together involves. The second request lands a few days later. By then the budget you imagined is already smaller than you remembered, but you can still see the shape of the original plan if you squint, and so you absorb the second request the way you absorbed the first, and you tell yourself that you will simply move faster.
The third request is the one that demands a decision. By now the budget you imagined is gone, and the original plan has been replaced by a plan in which everything fits only if nothing goes wrong, and in your experience something always goes wrong. You have three options, and exactly one of them does not involve telling someone they cannot have what they asked for. That option, the option in which you simply work harder, is the one most engineers reach for first — and it is the option that, six weeks later, produces the conversation in which you explain to your manager why three things shipped late instead of one thing on time.
What follows is a field guide for the moment when scope outruns capacity. It is written for the engineer who has already said yes twice and is staring at the third ask. It is also written, indirectly, for the manager who keeps wondering why their team’s estimates have started drifting and why the senior engineer who used to ship reliably has begun to seem quietly resentful.
Why this happens more now, not less
A counterintuitive observation: AI assistants have made this problem worse, not better, for senior engineers. The reason is structural. When the tools doubled the throughput of the easiest forty percent of the work, they did not double the throughput of the rest. The rest is mostly the part that requires you, specifically — the design call that has to be made before the code can be written, the production debugging that the assistant cannot do because the relevant context is in a Slack thread from August, the cross‑team conversation that needs the senior person in the room. That part still takes the same amount of time it did three years ago.
But the expectation of throughput has moved. The third yes in 2026 is being asked of an engineer whose visible output rate has gone up — they ship more code, they close more tickets, the dashboards look healthier — even though their available hours for the irreducible parts of the job have stayed flat. The third yes used to break the sprint at week three. It now breaks it at week two, because the asker was extrapolating from the new throughput, and the engineer was nodding along, and neither of them was tracking what kind of work the third yes actually consisted of.
If you are the engineer in this story, the first useful move is to separate two questions that the third yes always conflates: can the team produce more output? and can you produce more decisions? The first one is sometimes yes. The second one is almost never yes, and pretending otherwise is what produces the late projects.
The decision
You have three real options when the third yes lands. They are not equally good, but they are all available, and the one most senior engineers reach for first is the worst.
Option A: drop one of the first two. Go back to whoever owns the first or second request and say: “I committed to this when I had less information. I now have more. I can do two of these three things on time. Which two?” This is the option that feels rude. It is in fact the only one of the three that is honest. The cost is one uncomfortable conversation; the benefit is that the work that does ship, ships at quality, and the relationships you have with the askers stay intact, because they got to make the trade‑off rather than learn about it after the fact.
Option B: scope down. Take all three requests and reduce each one to its smallest defensible version. Ship the eighty percent that satisfies seventy percent of the need, and explicitly defer the rest. This option works when all three askers are flexible and when you are senior enough to make the call. It produces real artifacts and preserves all three relationships. It also, almost always, produces a fourth conversation in which you explain that the eighty‑percent version is the version, not a placeholder for a future hundred‑percent version that nobody is going to staff.
Option C: silently work harder. Keep all three commitments, work the weekends required, and ship in the hope that the cost falls only on you and not on the work itself. This is the option most engineers choose. It is also the option that produces the conversation, six to ten weeks later, in which an engineer who used to be reliable is now late on three things at once, and a manager who used to think highly of them is now wondering what changed. What changed is that the engineer accepted the cost of three yeses on themselves, the cost compounded, and the visible result was a quality drop on every commitment instead of an honest drop on one.
The conversation that prevents the conversation
The most useful thing a senior engineer can practice is the conversation that goes with Option A. It is short. It does not need an apology. It needs three sentences and the willingness to deliver them without flinching:
“I said yes to this when I had a different read on the rest of the sprint. I now have more information, and I’m going to break a commitment if I keep all three. I want to give you the chance to decide which one moves before I make that call alone.”
That is the whole script. It transfers the decision to the person who made the request, where the decision belonged in the first place. It is also one of the most senior‑coded sentences a working engineer can produce — managers and tech leads who hear it for the first time from someone who used to absorb everything in silence almost always recognize it as a step up, not a step down. It signals that the engineer is calibrating their commitments rather than collecting them.
A short test for the next time
Before you say yes to the third thing, run through this in thirty seconds:
- What did I commit to before this?
- What would have to be true for me to ship all three on time?
- Is that thing actually true, or am I assuming it?
- If it isn’t true, which of the previous two am I willing to renegotiate, and with whom?
If you cannot answer the fourth question — if there is no name attached to the renegotiation, no specific commitment you would unwind — you are not actually saying yes. You are deferring a conversation. The conversation will happen anyway. It will simply happen later, with worse facts, and with you having less of the room.
The third yes is not a moral failure. It is an information event. The senior move is to treat it as one.