Make the shortfall arguable before you argue about the cut
The instinct is to open with which item you want to drop, which invites everybody to argue about their favourite feature. Open instead with arithmetic anybody can check, because a gap expressed in engineer-weeks is something people negotiate with, and a gap expressed as "we are under pressure" is something people push back on.
Take a concrete shape. Eight engineers, a thirteen-week quarter, seven weeks gone, so six weeks and forty-eight engineer-weeks remain. Over the previous two quarters you measured interrupt and support work at roughly one engineer's time continuously, which is six engineer-weeks of the forty-eight, leaving forty-two. The team's current remaining estimates are twelve engineer-weeks for A, sixteen for B and twenty-six for C, which is fifty-four against forty-two available. That is a twelve engineer-week hole, and it is the first honest sentence of the conversation.
Notice what the same arithmetic tells you about the choice. Dropping B leaves thirty-eight against forty-two, so the two survivors carry four engineer-weeks of margin. Dropping A leaves forty-two against forty-two, which is a plan with no slack at all and will fail on the first sick week. When the candidates are otherwise close, the cut that leaves usable margin is the better one, and you can say why in a line rather than appealing to judgement.
Two caveats you should raise yourself rather than wait to be caught on. The remaining estimates are the same estimates that got you here, so they are probably optimistic in the same direction, and you should say what confidence you place in them. And engineer-weeks are not fungible across the three items if only two people can work on C, in which case the real constraint is those two people rather than the team total.
Rank on what is at risk, not on what is nearly finished
The seductive tiebreak is completion. C is eighty per cent done, so cutting C wastes the most work, so cut A. That reasoning is sunk cost wearing a project-management vocabulary. Effort already spent is not recovered by spending more, and the only live question is which two of these three deserve the forty-two engineer-weeks you have left, given what you know now rather than what you believed in week one.
Two criteria survive scrutiny. The first is the value that disappears if the item does not ship this quarter, which sorts genuine deadlines from dates. A regulatory date, a contractual customer commitment, a hardware launch or a competitor window is value that expires; most roadmap items simply arrive later and lose very little in the process. The second is what other people have committed on the strength of your commitment, and it is the one candidates forget even though it is where the real damage lives.
If marketing has bought a campaign, if a partner team has planned a dependent Sprint, if sales has been selling it, then the cost of your slip does not appear on your team's ledger at all. Find out before you choose, by asking each stakeholder what they have committed that assumes your date.
A third consideration is reversibility. An item that can genuinely resume next quarter close to the state you left it is a cheaper cut than one that decays, where the API you were integrating against changes underneath you, the contractor rolls off, or the context evaporates from the three people who held it.
The decision is not yours to make alone
This is where a strong manager separates from an adequate one. You own the assessment of capacity and the recommendation; you do not own the choice of which business outcome the organisation gives up. Making that call inside engineering and presenting it as an engineering fact is a quiet way of taking somebody else's decision, and it is also how you end up carrying blame for a trade-off you were never authorised to make.
Bring a recommendation with the analysis behind it and a genuine alternative, then let the owner decide. How that sounds matters more than the framework:
| Weak framing | What to say instead |
|---|
| "We are not going to make all three." | "We are twelve engineer-weeks short of all three, on estimates I would call plus or minus a fifth." |
| "We had to deprioritise B." | "My recommendation is to drop B, because A carries the March contract and C carries the audit date. I need your decision by Friday." |
| "We could probably still do it with overtime." | "Adding two people to C now costs us two weeks of ramp from the only engineers who know it, so it widens the gap rather than closing it." |
| "Which one do you want to cut?" | "Here are the three, what each is worth if it lands this quarter, and who else has planned around each date." |
Ask for a decision with a date attached. An open question to a stakeholder group produces three weeks of consultation, by which time the arithmetic has decided for you and you have lost the ability to choose at all.
Stopping is a task, not an announcement
Work dropped in a status meeting and not dropped in the repository is the most expensive outcome available. The team is now finishing it at reduced priority, which consumes the margin you just created, and the two surviving items miss as well. Expect the interviewer to probe here, because the engineer who has spent six weeks on C does not want to abandon it at eighty per cent, and neither, privately, do you.
Stopping properly means naming the state you will leave it in and a date by which it is there. Usually that means merging what is safely mergeable behind a flag, writing down the remaining plan and the decisions already taken while the context is still in somebody's head, closing the branch, and putting the tickets somewhere they will be found rather than somewhere they will rot. Then say in your own status report that the item is stopped, so nobody is quietly counting on it.
The other half is the conversation with the person whose work you stopped. Have it individually and before the wider announcement, be honest that the cause is capacity rather than their delivery if that is the truth, and hand them the next thing to own rather than leaving them to infer it.
Week seven is late, and the interviewer knows it
If this became clear in week seven of thirteen, something was visible in week three that you did not act on, and the strongest version of this answer volunteers that unprompted. The missed signal is usually one of a small set: the estimate for C was given before anyone had looked at the integration, the interrupt load rose and nobody re-derived the capacity, or a dependency slipped a fortnight and was recorded as a risk rather than subtracted from the plan.
The fix is unglamorous. Re-run the capacity arithmetic against remaining estimates on a fixed cadence, fortnightly being enough for a quarter, and report the margin or the shortfall as a number every time. A gap opening at two engineer-weeks is then a routine line in a report rather than a crisis at twelve. A manager who reports the gap only once it has become unmanageable has built the same false-green mechanism that produces inherited disasters, one quarter at a time.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).