Tell me about a time you cut scope to protect a delivery date.
answer
- why the date itself mattered
- the risk that forced a choice
- how you sorted scope into cut and keep
- who agreed to the trade
- what the cut cost, said out loud
basics
~20 sTests whether you treat scope, date and quality as a deliberate trade rather than a hope. Answer with one release where you chose the date, what you removed and why it was safe to remove, who agreed, and what the cut cost.
how to answer
5 beats- the date and why it was worth protectingSay what the date was tied to and who was depending on it. Keep this and the next beat to roughly a fifth of your airtime; the reason the date mattered is what makes the cut defensible later.
- the risk that made a trade unavoidableState the specific problem that put the plan at risk and when it surfaced. Vague pressure is not a reason to cut scope; a concrete blocker with a size on it is.
- how you sorted scope into keep and cutThis is the core, around half your airtime. Give the criterion you applied and one or two examples of what fell on each side, so the listener could apply the same sort themselves.
- how you got agreement and who you toldDescribe the trade as you presented it: date held, this removed, these people affected. Name who agreed, and mention anyone you told directly rather than letting them read it in a changelog.
- what shipped and what the cut costClose with the outcome and the price, in that order, using around a quarter of your airtime. Owning the cost — a disappointed user, work that never returned — is more convincing than a clean win.
your answer
4 story prompts- Pick a release where you held the date and shipped less than planned.
- Write the criterion you used to sort scope into keep and cut, in one line.
- Name the person or role who agreed to the reduced scope.
- Note what the cut cost and who was disappointed by it.
draft and rehearse your own answer in a learn session
go deeper
This probes judgement under constraint and stakeholder communication. The interviewer wants to see that you treat schedule, scope and quality as an explicit trade with a named owner, and that you can say out loud what the reduction cost. A strong answer shows a criterion for cutting and a decision someone else consciously agreed to.
An open-source analytics project I worked on had a publicly announced date for the release that introduced its new query engine, and three downstream tools had scheduled their own releases behind ours. I owned the dashboard side of it. About six weeks out, integration testing surfaced a real problem: saved dashboards with more than forty widgets took 12.7 seconds to first paint. Shipping that would have been worse than shipping nothing, and fixing it properly needed a pagination model nobody had designed yet. Moving the date was the expensive option, because the cost of moving it landed on projects that had no say in our slip. So I went at scope instead. I listed everything in the release and sorted it by one question: does removing this break a promise we already made, or only remove something nobody has been told about yet. Three of the eleven planned panel types were new and unannounced, and the pagination work only mattered for those. I proposed dropping them and shipping a hard widget cap with a clear message when a dashboard hit it. I wrote it up as a trade — date held, this is exactly what is not in it, these are the people it disappoints — and the maintainers agreed within a day. We released on time at 2.4 seconds to first paint. The dropped panels arrived the following cycle, and I put the cap in the roadmap so nobody met it by surprise.
The strength is the stated sort criterion — breaks a promise versus removes something unannounced — which makes the cut reviewable rather than instinctive, plus a written trade the maintainers actively agreed to. Naming who the cut disappointed keeps it honest. It would downlevel if the scope reduction were described without a criterion or without an owner agreeing.
I was one of the release coordinators on an open-source analytics project, and the dashboard rework had a date in our published roadmap. Nine weeks out it was clear the full rework would not make it. The theming migration alone had reached a hundred and forty files and was making render times worse rather than better. The choice was to hold the date with less in it or move the date with everything in it. Before choosing, I did something earlier releases of ours had skipped: I asked what the date was actually for. Two things depended on it — a talk a contributor had scheduled at a community event, and a downstream distribution's freeze window. Neither needed the theming work at all. That reframed the whole trade. We shipped the data-layer rework and the new default dashboard on the date, held theming for the next cycle behind an opt-in setting, and I told the contributor with the talk privately before anything went to the mailing list, because being surprised in public is what makes people stop believing a roadmap. The date held, and the default dashboard's ninety-fifth-percentile load fell from 8.1 seconds to 3.6. Most of that win was in the data layer anyway. The change that outlasted the release is procedural: roadmap entries now record the reason for a date beside the date. When something has to give, we can tell which half of a commitment is the real one.
Notice the order of operations: interrogating the date before cutting against it, sequencing who heard the news first, and ending in a standing practice rather than a rescued release. The metric is claimed modestly, with credit given to the part of the work that earned it. It would downlevel if the date were simply accepted as fixed and the answer became a list of removed features.
You may not own release scope yet, so use a smaller version: a task where you proposed shipping a narrower slice to hit a date. Show that you asked before you narrowed it, and that you said clearly what was left out.
This is your home ground. Show a real sort of scope into must-keep and safe-to-drop with a stated criterion, the trade written down for whoever holds the date, and honesty about who was disappointed.
Interrogate the date itself before you cut against it. Show that you found out what actually depended on it, who you told first, and how you protected the credibility of the plan as well as the delivery.
Speak to how commitments are made, not only to this cut. The interesting material is the standing practice — recorded reasons behind dates, default slicing, an agreed way to shed scope — that makes trades routine instead of dramatic.
saying these in an interview costs you the question
- Cutting tests or review rather than scope, and calling it a trade
- No named decision-maker who agreed to the reduced scope
- Cannot say what the cut cost anyone
- Dropped work quietly, so users found out from the release notes
- Describes the date as immovable without ever checking why
- How did you decide what was safe to cut?Give the criterion out loud rather than an instinct — broke a promise versus removed a nicety, on the critical path versus adjacent, reversible versus permanent. Interviewers want to hear that the sort was repeatable by someone else, not a private judgement call made under pressure.
- Who signed off on the reduced scope?Name the role that owned the date and say how you put the trade in front of them: what was held, what was removed, who it disappointed. If you decided alone because you owned it, say that plainly and say who you informed and when.
- What happened to the work you dropped?Follow it to its end. Landed next cycle, quietly abandoned, or still open years later are all acceptable answers, and the last two are more credible than a tidy one. Say whether the cut turned out to matter to anyone once the release was out.
- When would you have moved the date instead?Show you have a threshold rather than a reflex. Usually it is when the remaining scope cannot be reduced without breaking a promise already made, or when cutting would push the cost onto people who had no say. Naming that line proves the cut was a choice.