Sign in Get started

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.

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.