Capstone: lead a quarter-long project
Monday, 9:00. Companies email StayHub about 600 times a quarter asking for blocks of rooms; the median quote takes 4 days and a third never get one. Karim gives you 13 weeks, three squads and their agents. Lina says one sentence: "You lead this one."
One whole quarter, three squads, agents writing the code. You lead it from the first number on the page to the last lesson learned.
- Problem
Companies and event organisers ask StayHub for blocks of 10 to 60 rooms by email. About 600 requests a quarter go to three people in Sales; the median quote takes 4 days and a third of requests are never answered. Karim gives you one quarter, three squads and agents to fix it.
- Why the simple system fails
Starting with code (or with the agent's 20-minute architecture) skips every decision that makes a quarter succeed: the measurable goal, the irreversible choices, the order of slices, the rules for a dozen parallel agent sessions, what "ready to launch" means, and how the team learns afterwards.
- Engineering concept
Run the whole leadership loop, each stage leaving evidence: goal as numbers and drivers; ADRs for one-way doors after a spike; a plan of vertical slices starting with a walking skeleton; short enforced rules; parallel delivery capped by review capacity behind required gates; a go/no-go with criteria written in week 1; incident response; a blameless retrospective with owned actions.
- Technology
One-page project brief, ADRs, a spike, milestones and agent-sized tasks, root and per-directory CLAUDE.md, hooks and permission settings, branches or worktrees per session, required CI checks, feature flags and a ramp, a risk register and weekly status, runbooks, a retrospective.
- Trade-offs
Every stage costs time the quarter doesn't seem to have; each skipped stage moves its cost to launch week. Scale ceremony to risk: heavy on one-way doors (inventory, money, personal data), light on two-way doors. Cut scope before checks, and let review capacity, not agent count, set the pace.
The problem
2 min- Maya · Product managerCompanies email Sales for blocks of 10 to 60 rooms, about 600 a quarter. Median quote: 4 days. A third never get one.
- Karim · CTOYou have 13 weeks. I want companies booking groups and getting one invoice a month.
- You · Engineer at StayHubClaude Code already drafted an architecture: a groups microservice, its own database, an event bus.
- Lina · Senior engineer, your mentorYou lead this one.
The big idea
4 minAgents are strong porters; you choose the route: goal, one-way-door decisions, plan, enforced rules, launch criteria and what the team learns.
The expedition leader agrees the goal, scouts the dangerous pass, plans the camps, sets the rope rules, decides at the last camp whether to push for the summit, and runs the debrief. Every stage of this module, on one quarter.
How it works
5 min- 1Brief
Goal: 80% of requests quoted within 1 business hour; 150 companies invoiced monthly. Drivers, non-goals, and criteria written in week 1.
- 2Spike + ADRs
Measure the (inventory holds, invoices) before deciding; record each decision with a "revisit if".
- 3Plan
Walking skeleton in week 3, then vertical slices with ranges; pilot in week 7.
- 4Rules + gates
Per-directory CLAUDE.md, hooks and CODEOWNERS on risky paths, required checks with no bypass, sessions capped by review capacity (~120 PRs a week).
- 5Deliver, report, launch
Weekly status on outcomes and risks; go/no-go checked by named people; ramp 30% → 60% → 100%.
- 6Learn
A is a blameless look back that ends with owned, dated changes to rules, tools or templates.
Watch a decision being made
4 minYour quarter, week 1 to week 13 (Lina checks each stage)
Take group bookings from Maya's numbers to a measured result with three squads directing Claude Code.
- 1Spike, then ADRs
Two days: 60-room, 7-night holds work up to ~2,000 held nights per hotel; search p95 118 → 121 ms; only a scheduled job releases holds (into the risk register). ADR-052: a groups module with an import-boundary check, not a microservice. ADR-053: invoices through the pinned chain-invoicing seam.
Why: The agent's architecture was research; measurements and drivers made the decision.
- 2Rules that hold
Holds in
src/inventoryare stop-and-ask, with CODEOWNERS and a hook. Week 6: a session tried to "optimise" hold queries there; the hook stopped it.Why: Text is guidance; enforced rules survive forty sessions a day.
- 3Slip handled by scope
Week 5, one week behind. Keep the 2-session cap, move multi-city requests after the pilot, add contract tests. Pilot on time in week 7, slip reported Monday.
Why: Scope moved; gates didn't.
- 4Go/no-go, result, retro
Week 10: 74% quoted in 1 h (≥ 70%), zero invoice differences, kill switch rehearsed, no on-call owner: no-go one day, owner named, go. Week 13: 76% (target 80%), 164 companies, zero differences. Three retro actions with owners.
Why: Week-1 criteria weren't bent, and the honest number is reported as it is.
In real life
3 minAmazon: two-pizza teams
- Small teams own services
- Deploy independently
- More services to run
Team independence, paid for in operations.
Shopify: modular monolith
- One main app
- Components with enforced boundaries
- One deploy to run
Shared app, protected by boundaries.
What goes wrong
3 minReview capacity is the bottleneck.
Move scope, keep gates, add automated checks.
Jobs stop without anyone noticing.
Read-time checks, heartbeat alerts, a rehearsed kill switch.
Nothing changes.
Owned, dated actions that change rules, tools or templates.
Trade-offs
3 min| Approach | Fits when | You pay |
|---|---|---|
| Full loop, scaled to risk | Multi-team projects touching inventory, money, data | Weeks 1–3 feel slow |
| More agents to go faster | Free reviewers, independent tasks, strong gates | Review overwhelmed; rubber stamps |
| Freeze and slip | The slip is in a one-way door that can't be cut | Trust and commitments spent |
- Karim · CTOEach engineer runs five Claude Code sessions instead of two. We catch up in a week.
- Omar · On-call SREAnd who reviews all that? Freeze, harden, slip the pilot to week 8.
- Karim · CTOThe pilot companies are booked for training in week 7.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- The goal as numbers, drivers, non-goals and go/no-go criteria, written in week 1 and agreed.
- Every one-way door decided from a spike's measurements and recorded in an ADR with a "revisit if".
- The order of work, how many sessions run at once, and go, no-go or wait at each ramp step.
Read docs/projects/group-bookings/brief.md, docs/adr/052-groups-as-module.md, CLAUDE.md and src/groups/CLAUDE.md. Plan mode, don't edit: propose the week-3 walking skeleton, one request becoming a quote, a hold and a confirmation for one hotel in staging, behind the groups flag. Flag anything in src/inventory or src/billing. Then split the rest into vertical slices with criteria, size ranges and dependencies. Don't choose their order.
- The skeleton really goes request → quote → hold → confirmation, not one finished layer.
- Slices fit review capacity: PRs a week they imply vs what reviewers can do.
- At go/no-go, every week-1 criterion is checked by a named person; none quietly lowered.
- A plan ordered by layer, nothing end to end until late.
- "Run more sessions" as the answer to a slip.
- Go/no-go criteria edited in launch week to match the numbers.
Check yourself
2 minThat's the last episode, and there's no next one: your own project is. Tomorrow morning, write its goal as a number on one page, name its one-way doors, and lead.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Visual diagram, Analogy, Why it matters, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
Group & corporate bookings, week 1 to week 13 (you lead; Lina checks)
Take group bookings from Maya's numbers to a measured result in one quarter, with three squads directing Claude Code, and keep the evidence each stage requires.
- 1Brief: goal, drivers, criteria
Goal: 80% of requests quoted within 1 business hour (today: median 4 days); 150 companies invoiced monthly by week 13. Drivers: holds are a one-way door; invoices reuse the pinned chain path; ~120 reviewed PRs a week. Non-goals: travel policies, event spaces, card payment. Go/no-go criteria written now.
Why: Lina's check: "Could anyone argue about whether you succeeded?" With numbers and criteria, no.
- 2Spike, then ADRs
Two days on a throwaway branch: 60-room, 7-night holds work up to ~2,000 held nights per hotel; search p95 118 → 121 ms; only a scheduled job releases holds (added to the risk register). ADR-052: groups as a module with an import-boundary check, not the agent's microservice. ADR-053: invoices through the chain-invoicing seam and its golden tests.
Why: The agent's architecture was research. The decision came from measurements and drivers, with a "revisit if" line.
- 3Plan: skeleton, then slices
Claude Code's first plan was by layer. Reordered: walking skeleton in week 3 (one request → quote → hold → confirmation, one hotel, staging, flag off), then slices: quote approval, holds and expiry, company accounts, monthly invoices, partner rate approval. Pilot in week 7 (10 companies, 30 hotels in Lisbon and Madrid). Estimates as ranges.
Why: Every slice works end to end, so integration surprises arrive in week 3, not week 12.
- 4Rules that hold
src/groups/CLAUDE.md(golden path, test command, boundaries); holds insrc/inventoryare stop-and-ask, with CODEOWNERS and a hook that blocks agent edits there; max 2 agent sessions per engineer, each on its own branch or worktree; required checks with no admin bypass, including golden invoice tests.Why: Week 6 tested it: a session tried to "optimise" hold queries in src/inventory; the hook stopped it, and the change went to the inventory owners as a proposal.
- 5Deliver and report
Weekly status on outcomes: hill chart per slice, top risks, decisions needed. Week 5: one week behind on quote approval. You keep the WIP cap, move multi-city requests after the pilot, add contract tests between groups and billing. Pilot on time in week 7.
Why: Scope moved, gates didn't, and Karim read about the slip in Monday's update, not in a corridor.
- 6Go/no-go and ramp
Week 10: pilot quoted 74% within 1 h for two weeks (criterion ≥ 70%), zero invoice differences, kill switch rehearsed, but no on-call owner in the runbook. No-go for one day; owner named; go. Ramp 30% → 60% → 100% of companies, each step on the outcome dashboard.
Why: Criteria from week 1 weren't bent: the cheap missing one was met, the met ones weren't moved.
- 7Incident and retrospective
At 30%: 1,900 room-nights held by expired quotes in Lisbon (the expiry worker had failed to deploy; no heartbeat). Kill switch first; closed in 40 minutes. Week 13 result: 76% quoted within 1 h, 164 companies invoiced, zero invoice differences. Retro: three actions with owners: read-time expiry in the golden path, heartbeat on every scheduled job, "jobs monitored" in the go/no-go template.
Why: The risk noted at the spike came true; the kill switch from the criteria contained it; the retro turned it into rules for every future project.
| Stage | Evidence | What it caught |
|---|---|---|
| Brief | Numbers, drivers, non-goals, go/no-go, agreed | A quarter with no way to judge success |
| Spike + ADRs | Measurements; ADR-052, ADR-053 | An unneeded microservice and database; the silent-job risk |
| Plan | Skeleton in week 3; slices with ranges | Integration surprises pushed to the end |
| Rules | CLAUDE.md, hook, CODEOWNERS, required checks | An agent editing inventory holds |
| Delivery | Weekly status, WIP cap, contract tests | A one-week slip, handled by moving scope |
| Go/no-go | Criteria checked by named people | No on-call owner |
| Retro | 3 actions with owners and dates | Silent jobs guarding one-way doors |
Visual diagram
Group & corporate bookings: what you lead, and where the one-way doors are. Click a component, or follow the walkthrough.
Analogy
- Leading a mountain expeditionSummit, date, all safeLeading the projectGoal as numbers
- Leading a mountain expeditionScout the dangerous passLeading the projectSpike, then decide
- Leading a mountain expeditionCamps along the routeLeading the projectMilestones and slices
- Leading a mountain expeditionRope up on glaciersLeading the projectEnforced rules and checks
- Leading a mountain expeditionSummit push or turn backLeading the projectGo / no-go
- Leading a mountain expeditionDebrief afterLeading the projectRetrospective
Where it breaks: an expedition ends at the summit. A product keeps running after launch, so the alerts, owners and runbooks have to stay.
Why it matters
With agents, a team can produce a lot of code very fast. That's the danger.
Speed amplifies direction. A wrong choice in week 1, built by a dozen agent sessions, becomes a lot of wrong code by week 3.
People set the pace, not agents. Eight engineers can only review so much. More sessions just means a longer queue.
The goal is a number. Guests and companies don't care how many features shipped. They care that a quote now takes an hour, not four days.
Check your understanding
- 1.Retrospective with owned actions
- 2.Brief: goal as numbers, drivers, non-goals, go/no-go criteria
- 3.Go/no-go, ramp, incident response
- 4.Spike the riskiest unknown; ADRs for one-way doors
- 5.Plan: walking skeleton, then vertical slices and agent-sized tasks
- 6.Rules: CLAUDE.md files, hooks, permissions, required checks
- 7.Parallel delivery within review capacity; weekly status
Practice ladder
Which stage would have prevented it?
Debugging Warm-upAnother company's quarter-long project, built by agents, went badly. For each event, trace which stage of the leadership loop would have prevented it, and how.
- In week 11 the team discovered the payment provider couldn't split invoices by company department, a core requirement.
- Nothing worked end to end until week 10; the first full run failed in four places.
- An agent session refactored a shared pricing module "while it was there"; another team's tests broke for two days.
- Twelve agent sessions ran in parallel; PRs waited five days for review, then were approved in bulk.
- The CTO learned of a six-week slip from a customer.
- After launch, a cleanup job stopped silently; the same kind of failure had happened in their previous project.
Complete the go/no-go
Design PracticeComplete the go/no-go section of the group bookings brief, written in week 1.
- Outcome in pilot: ≥ ___% of requests quoted within ___ for ___ weeks
- Money: zero unexplained ___ differences against the ___
- One-way doors: ___ for holds rehearsed; no expired hold older than ___
- Operations: ___ written; ___ owner named; ___ for every scheduled job
- Ramp after go: ___% → ___% → 100% of companies, each step decided on the ___ dashboard
- Who decides: ___, after checking each line with ___
Lead the next quarter's first two weeks
Design StretchNext quarter: Long stays. Guests book 28+ nights at monthly rates; hotels want a deposit and a charge every month instead of one payment. Today ~300 long-stay bookings a month, mostly arranged by email; 1 in 5 has a payment problem.
Without help, write what you'd produce in weeks 1–2: (1) the goal as numbers, (2) four drivers and two non-goals, (3) the spike question for Claude Code with its time box, (4) the ADR question it informs, (5) the walking skeleton, (6) the top three risks with owner and trigger, (7) three go/no-go criteria.
What next for group bookings?
Decision StretchWeek 13 results:
| Metric | Target | Result |
|---|---|---|
| Requests quoted within 1 business hour | 80% (baseline ~5%) | 76% |
| Companies invoiced monthly | 150 | 164 |
| Invoice differences | 0 | 0 |
| Requests still quoted by hand | none set | 18% (multi-city events) |
Karim offers two options for next quarter: (A) keep all three squads on group bookings to reach 80%, add multi-city requests and travel policies; (B) hand group bookings to one squad (multi-city requests only, the cause of most manual quotes) and start Long stays with the other two.
Write your decision: "We chose X over Y because…, accepting the risk of…".
Explain it yourself
A friend asks: "If AI agents write all the code, what does a tech lead on a big project actually do all quarter?" Answer using the group bookings project.