The Tech Lead Handbook · Capstone Case Studies

Capstone: Rescue a Slipping Migration

You take over as tech lead of a migration that is six weeks late. Diagnose, re-plan and communicate.

Create a free account to save this page, take notes and track your progress. Sign in

Scenario

Example company: a payments team of seven is moving card processing from a legacy monolith to a new payments service. The original plan was 12 weeks; it is week 14 and the previous tech lead has moved to another team. You take over.

Evidence

  • Plan: four horizontal phases — data model, service API, dual-write, cut-over. Phases 1 and 2 are "done"; dual-write is "70% done" for five weeks.
  • Throughput (items finished per week, last 8 weeks): 3, 5, 2, 4, 1, 3, 2, 4. About 45 items remain.
  • Reviews: median time to first review is 26 hours; the previous lead approved every PR.
  • Dependencies: the fraud team must change how it reads transactions; nothing is scheduled on their side.
  • Incidents: two incidents in the dual-write path in the last month, both found by finance in reconciliation, not by alerts.
  • Stakeholders: the CFO's office expects cut-over "next month" for a contract with the card network. Status has been green.

Deliverables

  1. Your diagnosis: the three to five main reasons the project is late.
  2. A re-plan: how you'd re-slice the remaining work and what you'd change in how the team works.
  3. A forecast you'd give the CFO's office, and how you'd present it.
  4. Your first message to stakeholders.
  5. What you'd do in your first two weeks, in order.

Hints

  • Look at the plan's shape, the review process, and the dependency — not only effort.
  • A forecast from 8 weeks of throughput is enough to give a range.
  • Reconciliation finding incidents is a signal about detection, not only bugs.

Draft each deliverable below before revealing the model answer and rubric.

Further reading: Monte Carlo method · Strangler fig application

Deliverables

Diagnose: why is the migration late?

Model answer

  • Horizontal phases: nothing is usable until the end; integration problems surface late ("70% done" for five weeks).
  • Review bottleneck: a single approver and 26-hour median waits slow everything and push large PRs.
  • Unscheduled dependency: the fraud team's change isn't planned; cut-over can't happen without it.
  • Poor detection: incidents found by finance, not alerts — the team doesn't know when dual-write is wrong.
  • Optimistic reporting: green status without a forecast hid the slip.

Rubric

Look for: structural causes (slicing, review flow, dependency, detection, reporting) rather than 'the team is slow'. Misses: blaming individuals or only asking for more people (Brooks's law).

Re-plan the remaining work and how the team works.

Model answer

  • Re-slice vertically using a strangler approach: route one card type or one merchant segment through the new service end to end, then expand by segment.
  • Detection first: add automated reconciliation checks and alerts on dual-write mismatches before expanding traffic.
  • Fix review flow: any trained engineer can approve; area owners only for ledger code; response within hours.
  • Dependency: agree the fraud team's change in their planning this week with an owner and date; offer to contribute the change.
  • Limit work in progress: finish one slice before starting the next.

Rubric

Look for: vertical/strangler slicing, detection before scale, review-flow change, explicit dependency agreement, WIP limits. Misses: keeping the phase plan and 'working harder'.

What forecast do you give the CFO's office, and how?

Model answer

Run a Monte Carlo forecast on the 8-week throughput (mean 3 items/week) for ~45 items plus ~10% growth. With that history it gives about 17 weeks at 50% confidence and 19 weeks at 85%. Present it as "50% likely in about 17 weeks, 85% likely in about 19", and say it should tighten and move earlier as the review and work-in-progress changes raise throughput. Give options: a narrower first cut-over (one card type) that could meet the card-network contract earlier, or accept the later date. Re-forecast weekly in a written update.

Rubric

Look for: a range with confidence levels from throughput data, options that trade scope for date, and a cadence for updates. Misses: a single date from estimates, or promising 'next month' to protect the relationship.

Write your first message to stakeholders.

Model answer

"I've taken over the payments migration. Honest status: AT RISK. Based on the team's actual throughput, completing the full migration is 85% likely about 19 weeks from now, not next month. Main causes: the plan only delivers value at the end, a review bottleneck, and an unscheduled change from the fraud team. Options: (1) cut over one card type in ~6–8 weeks to meet the card-network contract, then expand; (2) keep the full scope and accept the later date. I need a decision by Friday. You'll get a written update every Friday from now on."

Rubric

Look for: an explicit status change, forecast with confidence, causes without blame, options with a decision date, and a cadence. Misses: vague reassurance, or bad news without options.

Your first two weeks, in order.

Model answer

  1. Talk to each engineer, the fraud team lead and finance; read the incident reports.
  2. Change the review agreement (shared reviewing, response time) — immediate throughput gain.
  3. Add reconciliation alerts for dual-write.
  4. Agree the fraud dependency with an owner and date.
  5. Re-slice with the team and pick the first vertical slice.
  6. Send the forecast and options to stakeholders; start the weekly update.

Rubric

Look for: listening first, quick structural wins (review flow, detection), dependency handled early, honest communication within days. Misses: rewriting the plan alone without the team, or waiting weeks to tell stakeholders.

Open in the app to mark lessons complete, take notes and track your progress.

Was this page helpful?