Choosing the Next 12-Month Focus with a Learning Plan
What This Concept Is
The specialization decision is produced by a rubric, not an epiphany. The rubric has three axes:
- Strength -- real evidence you can already do the work (from concept 10).
- Interest -- honest assessment of whether you want to do more of this work for a year.
- Market -- whether teams hiring today consider this track valuable.
Score each track 1-5 on each axis. Multiply or sum the axes to get a total. Treat the top score as a starting hypothesis, not an oracle. Then translate the hypothesis into a 12-month plan with quarterly objectives and concrete artifacts.
The rubric's virtue is not precision; it is visibility. It makes the axes separable. A hidden preference for "I want to be a distributed systems person" shows up as an interest-5 paired with a strength-2, and the rubric surfaces that the pick is a study plan rather than a specialization. Same score, very different interpretation, and now reasonable.
The 12-month plan half of this concept is where the rubric produces something executable. A decision without a plan degrades over weeks; a plan without a decision loses coherence. The two halves need each other -- the rubric picks the direction, the plan makes the direction produce evidence.
Why It Matters Here (In the Capstone)
Without a structured rubric, specialization decisions are made by mood. Mood picks the thing you read about most recently. A rubric separates the axes so that weaknesses are visible: a track strong in interest but weak in strength is a study plan, not a current specialization.
This concept is where all of Cluster 4 lands. Its output is an actual 12-month plan, filed as a graduation artifact. The plan then lives on past graduation and becomes the defining document of your first post-degree year. Treated well, it is also the single document you will cite most often in interviews -- "here is what I picked, here is why, here is what I have shipped against it so far."
Concrete Example: Filled Rubric
| Track | Strength (1-5) | Interest (1-5) | Market (1-5) | Total (sum) |
|---|---|---|---|---|
| Backend | 4 | 3 | 4 | 11 |
| Distributed | 3 | 5 | 4 | 12 |
| Platform | 2 | 3 | 4 | 9 |
| Infra / SRE | 3 | 3 | 4 | 10 |
| Data | 2 | 2 | 5 | 9 |
| Security | 2 | 3 | 4 | 9 |
Reading this grid: Distributed (12) edges out backend (11). Interest pulled the tiebreaker. The candidate picks distributed as the 12-month focus, with backend as the supporting adjacent track.
The grid also reveals honest facts: data has the highest market score but the lowest combined, so the temptation to chase market alone gets exposed. Platform and security score identically but for different reasons, which the owner now has to reason about explicitly.
Concrete Example: 12-Month Plan From the Rubric
Once the pick is made, produce a plan with four quarterly objectives, each anchored on an artifact:
| Quarter | Objective | Artifact |
|---|---|---|
| Q1 | Reimplement a replicated log from a paper | small Raft library with a blog post |
| Q2 | Extend capstone with a second node and failover | case study extension + runbook |
| Q3 | Study one distributed DB end-to-end | deep-dive post on its consensus + storage layer |
| Q4 | Ship a small open-source contribution to a distributed project | merged PR + writeup |
Each artifact is visible (repo, post, PR). That is the shape of a plan that survives contact: observable outputs at a quarterly cadence.
Concrete Example: The Defense Paragraph
The rubric's output is a single paragraph defending the top pick against the runner-up. Here is a worked example for the grid above:
"I'm picking distributed over backend for the next 12 months. On strength they are close, but my evidence is deeper in backend (4 vs 3). The decisive axis is interest: the systems I read about for fun and the problems I return to mid-capstone are all distributed (consensus under partition, at-least-once delivery semantics, replication topologies). Market is tied at 4; neither track loses on that axis. The risk is that 'interest without strength' produces a study plan rather than a specialization -- which is why Q1 and Q2 are deliberately skill-building rather than shipping. If by month 6 I have not shipped one distributed artifact, I drop back to backend with a distributed specialty, which the rubric also supports."
That paragraph is the graduation artifact. A rubric without it is numbers without a commitment.
Common Confusion / Misconceptions
Picking by one axis. Picking by market alone is the most common mistake -- it produces year-one unhappiness and year-two pivots. Picking by interest alone (no strength, no market) produces a hobby, not a career direction. Picking by strength alone risks being stuck in what your past happened to emphasize.
Making the plan so ambitious it implodes in quarter 2. A 12-month plan with four visible artifacts beats a 12-month plan with twelve. If the plan cannot survive a month of unexpected work, it is not a plan.
Treating the pick as irrevocable. It is not. The rubric is re-run at 12 months. If the evidence flipped, the pick flips. Build the review date into the calendar at commit time.
Using the rubric to rationalize. If you already know the answer and are filling the grid to justify it, the grid will quietly flex to match. The discipline is to fill strength and market honestly first, then check whether interest fell where you expected.
How To Use It (In Your Capstone)
The decision sequence:
- Fill the rubric from your strength grid (concept 10) and track definitions (concept 11).
- Compute totals. Note the top two tracks.
- Write a paragraph defending the top pick against the runner-up in your own words.
- If the defense is weaker than you expected, the runner-up might be the real answer.
- Turn the pick into a 12-month plan with one objective per quarter, each anchored on a visible artifact.
- Pick a review cadence (monthly self-review, quarterly peer review).
- File the rubric, defense paragraph, and plan to a single
library/raw/specialization/plan.md; set a 12-month reminder to re-run the rubric.
Check Yourself
- Are all 18 cells of your rubric filled with a real number, not a shrug?
- Can you defend your top pick against the runner-up in writing?
- Is your 12-month plan one objective per quarter, with a visible artifact for each?
- Did you fill strength and market first, or did interest flow to match an already-decided pick?
- What specific evidence at month 6 would tell you the pick is wrong? (Write it down now.)
- Is the plan tight enough to survive a month of unexpected work? If not, cut one objective.
Mini Drill or Application (Capstone-scoped)
Three drills:
- Fill, tot, and defend. Fill the rubric for yourself now. Compute the totals. Write a 150-200 word paragraph defending the top pick against the runner-up. Read it back 24 hours later. If the defense still holds, ship the 12-month plan.
- Plan-skeleton. Draft your own version of the quarterly table with one objective per quarter, each with a named artifact. If any artifact is "learn X," rewrite it as "ship Y that requires X" -- visible outputs only.
- Off-ramp sentence. Add one sentence to your plan starting with "I will drop this track if, by month 6...". Make it specific and measurable. Commit it alongside the plan.
File the rubric, defense paragraph, and plan under library/raw/specialization/plan.md. Set a 12-month reminder to re-run the rubric; the pick is a hypothesis with a review date, not a marriage.
Transfer / How This Synthesizes Prior Semesters
The rubric-plus-plan shape is a direct application of several disciplines that come from earlier semesters:
- S7 M05 ADRs & reviews -- the defense paragraph is structurally an ADR (Context, Decision, Consequences, Alternatives). Writing it that way makes the specialization pick defensible the same way an architecture decision is defensible.
- S8 M01 system design methodology -- the rubric is a constraint-first design: list the axes, score them, then choose, rather than choose and justify later.
- S8 M05 technical leadership & strategy -- "plans must produce observable artifacts" is the exact pressure the quarterly-artifact column in the plan enforces; learn-X plans fail this test and become study plans by default.
- S10 M05 c4 concept 10 -- strength grid -- the rubric's strength column is only as honest as the grid feeding it; a shaky grid produces a shaky pick.
- S10 M05 c5 concept 15 -- gap list -- the gap list is the mirror artifact: what the plan builds, and what the plan leaves open.
- S3 M05 applied design & code review -- the off-ramp sentence ("I drop this track if by month 6...") is the same "fail-closed" design discipline applied to a personal plan.
The transferable instinct: commitments are only credible when they come with a review date and a stop condition. That is true of architectures, of projects, and -- as concept 12 insists -- of career direction.
See also (integrative)
- S10 M05 c4 concept 10 -- Strength grid: rubric is only as honest as the grid feeding it.
- S10 M05 c4 concept 11 -- Specialization options: glossary; concept 12 rates what concept 11 defines.
- S8 M05 -- Technical leadership & strategy: "plans must produce observable artifacts."
- S7 M05 -- ADRs and reviews: defense paragraph is structurally an ADR.
- S10 M05 c5 concept 15 -- Gap list: mirror of the plan.
- External -- Career advice (lethain.com/career-advice): five-dimensional frame (finance / learning / people / pace / prestige).
- External -- Career advice in 2025 (lethain.com/career-advice-2025): market signal shifts; re-run the rubric.
- External -- Writing engineering strategy (staffeng.com/guides/engineering-strategy): "good strategy is boring" -- the plan should read boringly concrete.
- External -- Finding the right company to reach Staff (lethain.com/finding-the-right-company): the market axis interacts with company choice.
- External -- Staff archetypes (staffeng.com/guides/staff-archetypes): archetype choice orthogonal to track choice.
Source Backbone
Portfolio assessment packages evidence from the whole curriculum. These books provide the technical and professional backbone for the narrative.
- Software Engineering at Google - engineering evidence, review, and team-scale standards.
- Fundamentals of Software Architecture - architecture vocabulary and tradeoff defense.
- Building Secure and Reliable Systems - security and operational evidence standards.