Sign in Get started

The Team Lead Handbook · Capstone Case Studies

Capstone: A Team in Conflict After a Missed Launch

A launch slipped by five weeks and the team is blaming each other. Diagnose, repair trust and change how the team works.

Scenario

Example company: you've just become team lead of the six-person mobile checkout team. Their big launch — Apple Pay and Google Pay support — slipped by five weeks and shipped with two serious bugs. The previous lead moved on. The retro was cancelled "because it would get ugly".

Evidence

  • Blame in the air: backend engineers say mobile "changed the API contract twice"; mobile engineers say backend "never answered questions"; QA says everything arrived in the last week.
  • Process: two-week sprints; carry-over averaged 45%; 13 items in progress at the end, for six people.
  • Reviews: cross-platform PRs waited a median of 2.5 days; some merged with one comment.
  • People: the most senior mobile engineer, Kim, has gone quiet and declined two meetings. A junior backend engineer says privately she "saw the contract problem early but nobody listens to juniors".
  • Stakeholders: product is frustrated and has started assigning work to individual engineers directly.

Deliverables

  1. Your diagnosis: what went wrong — process, people and structure.
  2. How you'd run the first team session (the cancelled retro).
  3. The changes you'd make to how the team works, with how you'll measure them.
  4. How you'd handle Kim, the junior engineer, and product's direct assignments.

Hints

  • Notice the WIP, the review times and the API contract.
  • Who raised the problem early, and what happened?
  • Blame is a symptom; look for the system that produced it.

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

Further reading: Understand team effectiveness · The Retrospective Prime Directive

Deliverables

Diagnose what went wrong.

Model answer

  • Flow: 13 items in progress for six people and 45% carry-over — too much started, too little finished; integration and testing were squeezed to the end.
  • Contract: no agreed API contract between mobile and backend; changes weren't communicated — a missing working agreement, not bad people.
  • Reviews: 2.5-day waits across platforms pushed big, late merges with shallow reviews.
  • Psychological safety: a junior saw the problem early but didn't feel heard.
  • Structure: product bypassing the team now is a symptom of lost trust in the plan.

Rubric

Look for: systemic causes (WIP, contract, reviews, safety, trust) instead of blaming individuals. Misses: concluding 'backend was slow' or 'mobile changed scope'.

How would you run the first team session?

Model answer

Hold the retro within a week, framed as learning: read the Prime Directive; bring data (timeline, WIP, carry-over, review times); silent writing so everyone contributes; group into themes; focus on "how did our way of working make this likely?". Pick at most two changes with owners and measures. Facilitate firmly: redirect personal blame to the process ("what made that handover hard?"). Consider asking a neutral facilitator from another team if tensions are high.

Rubric

Look for: blameless framing, data, structure that includes quiet voices, and a small number of owned actions. Misses: skipping the retro again, or letting it become a blame session.

What changes would you make, and how will you measure them?

Model answer

  • WIP limit of about six, walking the board right to left in standup — measure WIP and cycle time.
  • API contract first: mobile and backend agree the contract (schema, examples) before building; changes go through a short review — measure contract changes after agreement and integration bugs.
  • Review agreement: response within four working hours, cross-platform reviewers paired — measure median time to first review.
  • Plan to real capacity: track planned vs done — target 80%+.
  • Check after six weeks in a retro; keep what works.

Rubric

Look for: each change tied to a cause and a metric, and a review date. Misses: many vague process changes with no measurement.

How do you handle Kim, the junior engineer, and product?

Model answer

  • Kim: 1:1 soon — ask openly how she's doing, listen; she may feel blamed or burned out. Agree what would help (role in the fix, time off, ownership of the contract process).
  • Junior engineer: thank her for raising it and make it right publicly in a way she's comfortable with ("the contract issue was spotted early — we need to listen better"); invite her to help design the contract process.
  • Product: talk privately — acknowledge their frustration, explain that direct assignments undermine the plan and the fixes, and agree a single prioritised list with them, plus weekly updates so trust can rebuild.

Rubric

Look for: individual attention before group fixes, repairing safety for the person who spoke up, and rebuilding trust with product through a shared process. Misses: ignoring Kim, or confronting product publicly.

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