What if you are the migration bottleneck?
Your fixes are fast. Every team still waits for you.
“explain why you made architectural choices and how you involved your teams.” (opens the source)
The question
You are Morrow’s staff engineer. You built the migration tool and approve every exception. Three teams wait on your review queue. Your manager asks how the project can finish without depending on your availability. All people and data are invented.
- Team A leadWe can run the tool, but only you know when an exception is safe.
- Team B managerMy engineers can take review responsibility if we agree the contract and reserve time.
- Support leadThe runbook says to ask you. We cannot yet rehearse recovery without you.
“Choose what to transfer and how you would know that the new ownership works.”
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 clear exceptions twice as fast as other engineers. Should you keep all reviews?
What would you do here? Open the move you’d make.
Work nights to clear every queue personally
Tempting, but it misses something. This retains the single reviewer and makes the project depend on your availability.
Delegate every exception with no limits
Tempting, but it misses something. Some exceptions may still require expertise or authority that has not transferred.
Split repeatable decisions from expert exceptions
The strong move. This makes a safe transfer possible without assuming all work is identical.
See how a strong candidate says it
“I would identify which decisions require my expertise and which have a repeatable contract. Personal review speed does not help the project if every team queues behind me. The next goal is an owner who can act within clear limits.”
Why it works: The project depends on throughput across teams, not the fastest individual review.
Step 2: New fact: Team B accepts two weekly review slots if it gets clear stop conditions. What do you provide?
What would you do here? Open the move you’d make.
Agree decision limits and pair on the first reviews
The strong move. This connects the team’s accepted capacity to work it can actually own.
Send a long design document and close the ticket
Tempting, but it misses something. The team still needs authority, examples and a way to resolve uncertainty.
Transfer the title but keep every approval
Tempting, but it misses something. The queue and decision dependency remain unchanged.
See how a strong candidate says it
“Agree the contract, representative examples, stop conditions and escalation route with Team B. Its manager commits the time. I would pair on the first reviews, then let the new owner make the bounded decisions.”
Why it works: A named owner needs knowledge, authority and capacity; a document alone supplies none of them fully.
Step 3: New fact: Team B handles routine changes, but recovery still requires you. Is the handoff complete?
What would you do here? Open the move you’d make.
Declare handoff complete because routine reviews pass
Tempting, but it misses something. The recovery path still depends on you.
Let the new owners lead the recovery rehearsal
The strong move. This tests the remaining operating responsibility at the team boundary.
Keep recovery undocumented so experts stay involved
Tempting, but it misses something. That preserves the exact dependency the project needs to remove.
See how a strong candidate says it
“No. Run a bounded recovery rehearsal led by support and Team B with the real runbook. I can observe, but the exercise must show they can detect the stop condition, return to the accepted state and communicate ownership.”
Why it works: Routine execution does not establish the ability to operate the changed system.
Step 4: New fact: the owners complete recovery without you and maintain it through two rollout rounds. What do you own now?
What would you do here? Open the move you’d make.
Keep checking every decision privately
Tempting, but it misses something. That undermines the authority the new owners have demonstrated.
Leave all technical work immediately
Tempting, but it misses something. The agreed exceptional decisions and outcome review still have an owner.
Close the transfer and retain only the agreed exceptions
The strong move. The evidence supports moving out of routine work while preserving clear accountability.
See how a strong candidate says it
“Close the accepted handoff and stop shadow-approving routine work. Keep only the named exceptional decisions and a scheduled outcome review. My account of the project should credit the teams and explain the limits they now control.”
Why it works: Continuing every approval would recreate the bottleneck after a demonstrated transfer.
The answer, in short
- Decision
- Transfer the bounded decisions and verify operating ownership.
- Because
- The project is stronger when other teams can act and recover without one staff engineer.
- What would change it
- Unowned exceptions or a failed recovery rehearsal reopen the handoff.
Common traps
- Calling personal output organizational impact
- Confusing a runbook with a working transfer
- Keeping hidden approval rights after the handoff
Check your answer
- Did I name the decisions to transfer?
- Did the receiving team accept capacity and authority?
- Did the owners rehearse recovery without me?
- Did I stop routine shadow approval?
Last reviewed Nov 10, 2026