How would you settle a disputed migration?
Three teams share a deadline. Their constraints are different.
The question
Morrow must replace an unsupported event library in 12 weeks. The platform team offers to do common changes centrally. The client team objects. You own the technical decision, but team managers own capacity. All people and data are invented.
- Platform leadWe can change 30 common services in six weeks if service owners review their contracts.
- Product leadI can protect one review slot per team each week. I cannot stop the whole roadmap.
- Client leadOur service has less traffic, but a partner integration differs from the common path.
“Make one decision that can be implemented, including the objection you would investigate.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: You own the technical call. Who owns the team capacity?
What would you do here? Open the move you’d make.
Tell all teams the central team now owns their deadlines
Tempting, but it misses something. The technical owner cannot create capacity or remove the partner obligation.
Wait until every engineer agrees
Tempting, but it misses something. A named decision owner can decide with recorded dissent once the material constraints are understood.
Agree the delivery owner and capacity commitments
The strong move. This turns a preferred design into work that the teams can schedule.
See how a strong candidate says it
“I can choose the technical path, but I cannot spend another team’s time without its manager. I would agree the review slots, one central delivery owner and an escalation date before announcing the rollout.”
Why it works: Authority for the design and authority for capacity are related but different.
Step 2: New fact: the smallest service owns a partner contract that forbids the new event order. What do you change?
What would you do here? Open the move you’d make.
Record the contract exception and change the boundary
The strong move. Thirty common services can progress while the partner constraint gets an explicit plan.
Outvote the client team because it has little traffic
Tempting, but it misses something. Low traffic does not remove the contract requirement.
Stop all common work until the partner replies
Tempting, but it misses something. The packet has not shown that the common services share the exception.
See how a strong candidate says it
“Keep the common rollout, but isolate this contract as an exception with its own owner. The objection changes the boundary. Traffic size is not a reason to ignore a contract that blocks deletion of the old path.”
Why it works: The exception is about a required behavior, not the client lead’s preference.
Step 3: New fact: the partner can test in week 10. Common services finish in week 6. When is the migration complete?
What would you do here? Open the move you’d make.
Declare completion at thirty services
Tempting, but it misses something. The partner contract still requires the old path.
Track common rollout and final retirement separately
The strong move. This gives each milestone a real owner and evidence.
Keep the old path with no expiry
Tempting, but it misses something. An unbounded exception loses the deadline and retirement owner.
See how a strong candidate says it
“The common rollout can finish in week 6, but the migration is not complete while the old path remains required. The client lead owns partner acceptance in week 10; platform owns the removal task after that evidence.”
Why it works: A percentage of changed services cannot close an external operating obligation.
Step 4: New fact: partner tests fail in week 10 and support ends in week 12. What do you take to leadership?
What would you do here? Open the move you’d make.
Ship the common behavior to everyone at week 12
Tempting, but it misses something. That knowingly breaks the partner contract.
Hide the exception in a follow-up ticket
Tempting, but it misses something. The remaining support window requires a timely capacity or commercial decision.
Escalate the failed contract with bounded options
The strong move. Leadership can decide the cost and risk with the responsible teams present.
See how a strong candidate says it
“Escalate the exact failed contract and remaining two-week limit now. Offer a funded contract repair or a scoped, approved support arrangement if available. State the risk and owner; do not relabel the exception as complete.”
Why it works: The deadline does not authorize a contract break. A capacity or commercial decision now exceeds the original technical call.
The answer, in short
- Decision
- Run common changes centrally; manage the partner contract as a funded exception.
- Because
- The objection changes the boundary and completion rule without blocking unrelated work.
- What would change it
- A shared contract failure or loss of capacity would reopen the common rollout.
Common traps
- Treating dissent as disloyalty
- Calling changed services a completed migration
- Leaving exceptions without owners or expiry
Check your answer
- Did I separate design and capacity authority?
- Did the contract objection change the plan?
- Did I separate rollout from retirement?
- Did I escalate before the deadline?
Last reviewed Nov 10, 2026