Capstone: Operate at Principal Level

⏱ ~10 min read · 🎧 9 min listen · ✎ 3 quizzes · 🧪 ~180 min lab

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.¹ 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.

The scenario: Meridian

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.

Your deliverable: a three-artifact portfolio

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:

The Principal-level rubric

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.

🧪 Lab: the capstone itself

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:

1. Diagnose first, design second. Write artifact 1 before touching architecture. If the memo takes less than two hours, your diagnosis is probably a symptom restated — interrogate it again.
2. Write artifact 2 — map today's system honestly (including what you'd have to go find out), pick your most contested decision for the ADR, and sequence the migration so Meridian is better off after every single step.
3. Write artifact 3 — SLOs, error-budget policy, incident command, observability, and the search verdict. The verdict must commit: build or buy, with numbers.
4. Self-grade against the rubric — all nine criteria, honestly marked Absent / Asserted / Evidenced. Fix the Absents before you submit; flag the Asserteds.
5. Submit in chat — all three artifacts plus your self-grades.

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.¹ Three rounds of that, and this stops being coursework: it's a rehearsed, defensible body of work.

You are a seasoned Principal Engineer reviewing my work: a capstone portfolio for the Meridian scenario (a 200-engineer e-commerce company: checkout p99 doubled with traces stopping at the monolith boundary, two commanderless four-hour outages, a build-vs-buy fight over search, and three teams each half-building their own event bus). The portfolio has three artifacts: a Diagnosis & Strategy memo, a Target Architecture & Migration doc, and an Operating Plan. Run up to three rounds:

ROUND 1 — Grade each rubric criterion Absent / Asserted / Evidenced ("Asserted" = claimed but not backed; "Evidenced" = specifics a skeptic could check), with one sentence of evidence per grade, and compare against my self-grades:
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 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, before the pager fires.
8. Search verdict includes opportunity cost — what those six engineers don't build.
9. The whole package is readable by a CTO in 30 minutes — each page earns its place.
Be skeptical — challenge the weakest claim first, and finish with the single highest-leverage improvement.

ROUND 2 — After I revise, play Meridian's skeptical CTO: "why should I fund this instead of features?", "what happens if I give you half the headcount?", and 2–3 follow-ups of your own.

ROUND 3 (only if I ask) — Run a mock Principal interview: I present these artifacts as my real work history and you probe the way a staff+ loop would.

My Meridian capstone portfolio and self-grades follow below.

Check yourself — the whole course at once

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.

What now — after the course

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 next month, a real SLO worksheet the month after, a strategy memo the month after that. Real stakes are the best spacing algorithm there is.

• Join the peer network. Staff+ engineers consistently name their peer community as their most valuable resource⁴ — join the Rands Leadership Slack (email invites@randsinrepose.com) and follow LeadDev StaffPlus, the community built specifically for staff+ ICs.
• Keep filling the evidence trail. The Lesson 12 packet is a living document now, not a course artifact. Every real ADR, incident review, and strategy memo you write goes into it — the promotion packet assembles itself if the trail never stops.