Lesson 13 · The Move
One ambiguous, realistic problem. The whole loop — diagnosis, architecture, operations, verdicts — end to end. Graded against a Principal-level rubric.
Twelve lessons in, you know the material. But there's a gap between knowing the material and operating at the level — and the gap is this: real problems don't arrive labeled "this is a strategy problem" or "this is an SLO problem." They arrive as a mess, all at once, under time pressure, with an executive waiting.1 The only way to close that gap is to do the whole loop on one problem, end to end, under realistic ambiguity. That's the capstone. Minimal new teaching today — a scenario, a rubric, and your move.
Meridian is a mid-size e-commerce company — roughly 200 engineers across 25 teams — whose ten-year-old monolithic platform made the company and is now straining under it. Checkout p99 latency has doubled in the past year, and nobody can say exactly why: the traces stop at the monolith's boundary, the dashboards were built for a smaller company, and the two engineers who understood the order pipeline best left in March. Growth is still good — which is precisely the problem, because every peak sale event is now a gamble.
Last quarter the gamble lost twice: two four-hour outages, both during promotional peaks. The postmortems, such as they are, describe the same mid-incident chaos — forty people in a call, no clear commander, three teams making conflicting changes, and recovery that happened more by luck than by procedure. Meanwhile the search team, frustrated with the aging in-house search, wants six engineers for a year to build a modern engine from scratch — while a credible vendor offer sits on the table at roughly a third of that cost. And in the absence of any platform direction, three separate teams have each quietly started building their own event bus. All three are half-finished. All three are "almost done."
You were hired three weeks ago as Meridian's first Principal Engineer. The CTO's brief, verbatim: "I need a plan. Two weeks." That's it. No scoping, no constraints, no definition of "plan." Whether this means a memo, an architecture, a hiring case, or all three — that ambiguity is not an oversight. It's the job. Deciding what the CTO actually needs is the first Principal-level move of the capstone.
You'll answer with a capstone portfolio of three artifacts — each one exercising a different module of this course, all three coherent with each other. Together they must be readable by a busy CTO in thirty minutes:
| Artifact | Length | Must contain | Draws on |
|---|---|---|---|
| 1 · Diagnosis & Strategy memo | 1 page | A Rumelt kernel: the diagnosis behind the symptoms, a guiding policy that forbids something, and coherent actions2 | L10 |
| 2 · Target Architecture & Migration doc | 2 pages | System map of today, target state, failure modes, one ADR for the most contested decision, and a migration sequenced so each step pays for itself | L03 · L04 · L05 · L06 |
| 3 · Operating Plan | 1–2 pages | SLOs for checkout and search, an error-budget policy, an incident-command structure, observability investments, and the build-vs-buy verdict on search3 | L07 · L08 · L09 · L11 |
This is the rubric your portfolio will be graded against — the same lens a promotion committee or a Principal interview loop applies. Grade each criterion on a three-point scale: Absent (not there), Asserted (claimed but not backed), Evidenced (shown with specifics a skeptic could check). "Asserted" is the trap — most strong-but-not-Principal work lives there.
| # | Criterion | Absent / Asserted / Evidenced |
|---|---|---|
| 1 | Diagnosis names the real problem behind the symptoms — not a restatement of them | ☐ / ☐ / ☐ |
| 2 | Strategy forbids something — a guiding policy you can violate, not a list of good intentions | ☐ / ☐ / ☐ |
| 3 | Architecture traces to strategy — every structural choice answers the diagnosis, not a résumé | ☐ / ☐ / ☐ |
| 4 | Every decision shows its trade-off and names the rejected alternative | ☐ / ☐ / ☐ |
| 5 | Migration steps are independently valuable — the plan survives being stopped at any step | ☐ / ☐ / ☐ |
| 6 | SLOs are user-anchored — defined from what a customer experiences, not what a server emits | ☐ / ☐ / ☐ |
| 7 | Incident structure has named decision rules — who commands, who decides what, before the pager fires | ☐ / ☐ / ☐ |
| 8 | Search verdict includes opportunity cost — what those six engineers don't build if they build search | ☐ / ☐ / ☐ |
| 9 | The whole package is readable by the CTO in 30 minutes — and each page earns its place | ☐ / ☐ / ☐ |
This is the final artifact of your evidence trail — and the strongest single piece in it, because it demonstrates the whole loop, not one skill. Budget six to ten focused hours across a week. Work in this order:
The feedback loop runs up to three rounds. Round one: I review the portfolio against the rubric, criterion by criterion, with specific fixes. Round two: I play Meridian's skeptical CTO — expect follow-ups like "why should I fund this instead of features?" and "what happens if I give you half the headcount?". Round three, optional but recommended: we run it as a mock Principal interview — you present the artifacts as if they were your real work history, and I probe the way a staff+ loop would.1 Three rounds of that, and this stops being coursework: it's a rehearsed, defensible body of work.
Three final scenarios — the hardest in the course, because each one crosses modules. No scrolling back, no rereading. If these feel effortful, good: that's retrieval doing its job.
Scenario A
A draft Meridian architecture doc proposes extracting checkout into services, adopting the vendor search, and consolidating on one event bus — each justified as "industry best practice, consistent with our microservices direction." The design itself is technically sound. What's the Principal-level flaw?
Scenario B
Three weeks into the quarter, a bad deploy burns Meridian's entire checkout error budget. The migration's next step — moving order-write traffic — is due next week, and the team argues it should proceed because the migration will improve reliability long-term. Your error-budget policy exists. What's the Principal move?
Scenario C
In a Principal interview, you're asked for your most significant technical decision. A candidate gives a crisp, deep account of consolidating three event buses into one — the architecture, the trade-offs, the rollout mechanics. Technically flawless. The interviewers score it below the Principal bar. Why?
A course ends; the practice doesn't. Three habits keep this material from evaporating. First, spaced retrieval: revisit the quizzes across all thirteen lessons one week from now, and again in a month — wrong answers tell you exactly what to reread. Second, re-do one artifact per month at work, for real: a genuine ADR in August, a real SLO worksheet in September, a strategy memo in October. Real stakes are the best spacing algorithm there is.
Not new picks: these are the five items from the whole course most worth returning to.