In this article
Before you start
Why interviewers ask this
The question tests whether a manager can absorb change without losing the team or the plan. A candidate who says "we just adjusted" has not said what was dropped, how people heard about it, or what happened to the work in flight. It is reported in interviews at large technology companies in several forms: a time you re-prioritised the roadmap mid-quarter, a time you pivoted the team after a shift in company priorities, and how you would communicate a strategic change to your team.
A weak answer lists the new work. A strong answer names what stopped, who was told first, and what was done with half-finished items, and it admits a cost in people terms. The engineering manager interview guide shows how this fits with the other planning questions.
Handling a mid-quarter priority change from first principles
- Priority change
- A priority change is a decision from outside the team, such as a new company goal or a customer commitment, that makes some of the planned work less important or obsolete and some new work urgent, within a period the team had already committed to.
- Sunk cost
- A sunk cost is a cost already spent on a piece of work that cannot be recovered, and it should not by itself decide whether to finish the work, because only the remaining cost and value change the outcome.
In plain words
A mid-quarter change is like a road trip where the destination moves after you have driven half the way. Fuel is spent and cannot be refunded. The useful question is what the cheapest route to the new place is from where you now stand. The analogy breaks on people. A car does not feel anything about the miles already driven, but engineers do, so the way you tell them matters as much as the new route.
Said precisely, the answer is three steps. Decide what stops and what continues. Tell the team first and give the same message to partners. Close out the half-finished work on purpose. Google's guide to objectives and key results (OKRs), which sets objectives and measures each by a few numeric key results, recommends a mid-quarter check-in, which lets teams abandon objectives that are clearly not going to happen and move resources to borderline ones (Google re:Work, 2016).
Step 1: Decide what stops, not only what starts
The first step is to decide what stops, because new work needs capacity and a count shows whether finishing everything can pay for it. The output is a list of what continues, stops or pauses. Ask the sponsor, the leader who asked, why and how firm it is. Amazon's 2016 letter says to decide with about 70 percent of the information you wish you had, and that reversible decisions are two-way doors (Amazon, 2016 letter to shareholders).
Count the capacity. Seven weeks remain, which is 56 engineer-weeks, for 8 engineers when the change lands at the start of week 7 of 13. Say the new priority needs 35. Three in-flight projects need 3, 10 and 14 to finish. Finishing all three leaves 29, which is 6 short. Stopping the 14 that no longer serves a goal leaves 43, covering the 35 with 8 to spare.1 The sentence that earns the point: "we stopped X to start Y." What you now know: what stops.
Step 2: Tell the team first, with the reason
The second step is to tell the team before the news reaches them another way, with the reason and the new plan. The input is the decision from Step 1; the output is one message, in person, covering what changed, why, what it means for each person's work and what happens next. Give partners, meaning the product manager and the teams that depend on your work, the same message at the same time, so nobody hears a different version.
Netflix describes managers as giving teams "context, not control": equipping them with information and clarity so they can decide well (Netflix culture page, read October 2026). Say what you do not know yet, and when you will. If some people disagree, listen, then commit; Amazon's letter calls this disagreeing and committing. Speak to anyone whose project is stopped before the group hears it, because they carry the cost. What you now know: the team heard it from you, with the reason.
Step 3: Close out half-finished work on purpose
The third step handles work in progress deliberately, because half-finished work left lying around is a hidden cost. The output is a decision for each item: finish, pause with a note, or stop and archive. Judge by remaining cost and value, not by what was already spent.
In the example, a billing export needed 3 more engineer-weeks and had value 4 on a made-up 10-point scale, so it was finished. The search latency project needed 10 and was still relevant, so it continued. The admin redesign needed 14 and no longer served a goal, so it stopped.1 Write down what was paused and where it lives, so it can restart.
Scrum is a team process. A Sprint is its fixed period of a few weeks, and each Sprint has a Sprint Goal, its one aim. The Product Owner is the person who decides what the team builds, and only that person can cancel a Sprint, for an obsolete Sprint Goal (Scrum Guide, November 2020). What you now know: nothing is left in limbo.
| Project | Engineer-weeks left | Relevant now | Decision |
|---|---|---|---|
| Billing export | 3 | No | Finish (small) |
| Search latency | 10 | Yes | Finish |
| Admin redesign | 14 | No | Stop |
Step-by-step description
- 56 engineer-weeks left; stop one project.
- The team first, then partners.
- Finish, pause or archive each item.
- Seven weeks remain, which is 56 engineer-weeks.
- Stopping one project leaves 43 engineer-weeks for the new priority.
Text description of the diagram
- The new priority needs 35 engineer-weeks (illustrative).
- Finishing all three projects leaves 29, which is 6 short.
- Stopping the 14 engineer-week project leaves 43, which is 8 to spare.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
A Staff-level answer names what stopped, who was told first, how the half-finished work was handled and what it cost in people terms.
Tell me about a time you had to re-prioritise your roadmap mid-quarter.
In week seven a new company goal made one of our three projects obsolete. I asked the sponsor why and how firm it was, then counted: 56 engineer-weeks left against about 35 needed. We stopped the redesign, finished a small export that was nearly done, and kept the latency work. I told the team in person that day, then gave partners the same message. I spoke first to the engineer whose project stopped, and we archived the work with notes. Stopping the redesign left 8 engineer-weeks spare, so we delivered the new priority a week early.
What makes it Staff-level: it leads with what stopped, uses capacity numbers rather than adjectives, and names the person who paid the cost.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| What changed | "Priorities shifted" | The reason and its firmness | The reason, and the decision rule used |
| What stopped | Not mentioned | One item named | Items named with remaining cost |
| Communication | "I told the team" | Team first, then partners | Team first, same message to partners, owner spoken to |
| Work in progress | Left as is | Finished or stopped | Decided by remaining cost, archived with notes |
| People cost | Ignored | Acknowledged | Named, and how it was paid |
Three variants of this question
Tell me about a time you had to re-prioritise your entire roadmap mid-quarter.
Tell the story in the three steps with real numbers: what changed and why, what stopped, who heard first, and what happened to the work in flight. Finish with the result and what it cost.
Describe how you would communicate a significant strategic change from management to your team.
Tell the team first and in person, give the reason, say what is decided and what is not, and give the same message to partners. Follow with a written note so the facts do not drift.
How do you handle projects without defined end dates?
Give them a review date and a stopping rule. An open-ended project is a standing cost, so state the measure that would justify continuing and check it at each planning point. See how to build a roadmap and prioritise.
Common mistakes
- Only saying what you started. (wrong) "We picked up the new project." (right) "We stopped X so that we could start Y."
- Letting the team hear it elsewhere. (wrong) "It came out in an all-hands." (right) Tell the team first, in person, with the reason.
- Finishing everything. (wrong) "We finished all three and the new work too." (right) Count against the estimate: if finishing everything leaves less than the new work needs, stop something.
- Deciding by sunk cost. (wrong) "We had already spent ten weeks on it." (right) Judge by remaining cost and remaining value.
- Ignoring the people cost. (wrong) "It was fine." (right) Name who lost a project and what you did for them.
Follow-up questions
How do you balance team and organisational priorities?
Start from the organisation's goal, show what the team's work contributes to it, and bring the conflict to the decision owner with the trade-off in shared units. See stakeholder management for engineering managers.
How did you handle the engineer whose project was cancelled?
Speak to them first and in private, say why, say what the work contributed, and agree what happens to the code and to their next assignment. Check in again after a week.
What did you do with half-finished work?
Decide each item by remaining cost and remaining value: finish it, pause it with notes, or archive it. Record where it lives so it can restart if the priority returns.
What if the priority changes again next month?
A second change within a month is a signal about how firm the first one was. Ask for a stable decision date, keep a reserve for the unplanned, and read how to build a roadmap and prioritise for capacity sizing. For change that crosses teams, see driving a big cross-team change, and for the debt trade-off tech debt vs features; the project, program and agile hub and the product management hub cover delivery and product partners.
- Say what stopped, not only what started.
- Count remaining engineer-weeks; the example had 56 against a need of 35, and stopping one project left 43.
- Tell the team first, in person, with the reason; give partners the same message.
- Decide half-finished work by remaining cost and value, not sunk cost.
Sources
- Set goals with OKRs — Google re:Work (originally published 2016), 1 Jan 2016
- The Scrum Guide — Ken Schwaber and Jeff Sutherland (November 2020), 1 Nov 2020
- 2016 Letter to Shareholders — Amazon (Jeff Bezos), 12 Apr 2017
- Netflix Culture — Netflix (page undated; read 2026-10-24), 24 Oct 2026
