Glossary — Principal Engineer Track

Staff+ — staff-plus: The individual-contributor levels beyond Senior: Staff, Senior Staff, Principal, Distinguished (names vary by company). The IC counterpart of the management track — leadership without direct reports.
Archetype — staff archetypes: Will Larson's four common shapes of the staff+ job: Tech Lead (guides one team/cluster), Architect (owns direction for a critical technical area), Solver (deployed onto the hardest problem of the moment), and Right Hand (extends an executive's scope). Companies hire and promote for a specific shape, whether they name it or not.
Leverage: Impact through others and through decisions, rather than through your own direct output. A Principal's work is judged by what the org ships and decides because of them — one good decision or document can outweigh a quarter of personal coding.
Scope: The blast radius of the problems you own: a feature → a team → several teams → the org. Level transitions are mostly scope transitions; "Principal-level scope" means problems that cross team and quarter boundaries — often ones nobody was assigned.
Glue work: Tanya Reilly's term for the coordination that makes projects actually succeed: noticing gaps, unblocking people, improving process, keeping cross-team work moving. Expected and rewarded at staff+ levels; career-damaging when done invisibly on the way there — it must be made visible and narratable.
Evidence trail: This course's term for the accumulated artifacts — scope maps, ADRs, design docs, SLO worksheets, strategy memos, incident reviews — that prove Principal-level operation. Doubles as a promotion packet and as interview story material.
Promotion packet — promo case: The written case for a level change: the problems you found and framed, the decisions you drove, and evidence of org-level impact. Committees grade what they can see — the packet is built from the evidence trail, not from memory, at the end.
Sponsor — promotion sponsor: A senior leader who actively argues your case in rooms you're not in — promotion committees, calibration meetings. Distinct from a mentor (who advises you) or your manager (who files the case): a sponsor spends their own credibility on your behalf. The promotion packet exists largely to arm them — committees promote on what advocates can say about you without you present.
Trade-off analysis — modern trade-off analysis: The core analytical method of staff+ architecture work, codified in Software Architecture: The Hard Parts: find what's entangled, analyze how dimensions trade against each other (when one improves, what degrades), then decide and document the why. The working tool is a qualitative table of options against dimensions in genuine tension — no winner row; the decision comes from weighting dimensions by business context. Corollary of the First Law: anything that looks free has an unidentified cost.
Blast radius — failure domain: The scope of damage when a component fails or a contract is broken: which users are affected, what data is at risk, which other systems are dragged down. A Principal states failure modes with their blast radius attached — "if Redis dies, every session drops and the DB inherits the read load" — because a fault you can bound is a fault you can design for.
Bottleneck: The single resource that caps a system's throughput at a given moment — a write-saturated primary database, a rate-limited third-party call. Everything else has headroom, so scaling anything other than the bottleneck changes nothing (the mistake behind "we doubled the servers and it didn't help"). Claims about it should be backed by evidence — saturation graphs, incidents, load tests — not folklore.
Design doc — design document, RFC: A short written proposal for a system change, structured to let reviewers disagree with you efficiently: problem and requirements (with scale numbers), constraints, the proposed design with its data flow, alternatives fairly weighed, failure modes with blast radius, and a rollout plan. A system design interview is this same document compressed into 45 spoken minutes. A core artifact of the evidence trail.
ADR — architecture decision record: A one-to-two-page record of one architecturally significant decision: context (the forces at play), the decision ("We will…"), status (proposed, accepted, superseded), and honest consequences — negative ones included. Introduced by Michael Nygard in 2011; kept numbered and immutable in the repo, so changed minds produce a superseding record, not an edit. The cheapest way to stop relitigating settled questions — and a named, dated evidence trail of the decisions you drove.
Design review: The structured stress-test a design gets before it becomes a decision: the doc circulates days ahead, the problem is reviewed before the solution, and reviewers ask questions ("what would have to be true for this to fail?") rather than issuing verdicts — so flaws surface while course changes are still cheap, and the author leaves smarter and still owning the design.
Replication lag — follower lag: The delay between a write landing on the leader and appearing on a follower replica. Reading a lagging follower is like reading yesterday's newspaper — nothing in it is wrong, it's just not current. Usually milliseconds; under load it stretches to seconds, producing user-visible bugs like vanishing comments. Scoped guarantees (read-your-own-writes, monotonic reads) fix specific anomalies at specific costs.
Partitioning — sharding: Splitting a dataset by key so each machine owns one slice, like an encyclopedia in volumes — used when the data or write traffic no longer fits one machine. Complementary to replication (real systems partition, then replicate each partition). Its signature failure is the hot partition: one famous key concentrates load on a single shard, and adding more shards doesn't help — relief requires reshaping the hot key itself.
Eventual consistency: The guarantee that replicas converge eventually: reads are fast and stay available through failures, but may return stale data in the meantime. The trade against strong consistency (which behaves as if there were one copy, at the cost of latency and availability). The Principal-level move: choose per feature, not per system — a like-counter tolerates staleness; an account balance doesn't.
Split brain: The failure where two nodes simultaneously believe they are the leader and both accept writes, producing contradictory data. Caused by the fact that, from inside a network, a dead machine and a slow network are indistinguishable — so naive "promote on silence" failover creates it. Prevented by majority quorums, at the cost of extra nodes and a write-refusing minority during partitions.
SLI — service level indicator: A quantified measurement of one aspect of a service's level, defined over real user interactions — e.g., the proportion of requests answered successfully in under 300 ms, measured at the load balancer. A good SLI is a ratio of good events to valid events and tracks what users experience, not internal proxies like CPU: a server can be perfectly healthy while every user request fails.
SLO — service level objective: The target you choose for an SLI over a window — "99.9% of requests good, over rolling 30 days." An internal promise, set jointly by product and engineering from what users need (not from current dashboards), and deliberately below 100%: each extra nine costs roughly ten times more and buys nothing users can perceive. Distinct from an SLA, the customer contract with penalties, which is set looser than the SLO.
Error budget: The gap between an SLO and perfection — at 99.9%, 0.1% of events may fail — treated as a resource the team deliberately spends on velocity: risky deploys, experiments, maintenance. Comes with a pre-agreed decision rule: budget remaining → ship; budget exhausted → freeze features and fix reliability. Its real power is organizational — the number is signed in advance, converting reliability from a recurring argument into a self-policing policy.
Incident Commander — IC: The single decision-maker and source of truth while a major incident runs, adapted from the emergency services' Incident Command System and popularized in software by PagerDuty. The IC coordinates — assigns tasks by name with time-boxes, gathers consensus via "any strong objections?", approves comms — and explicitly does not debug or read graphs; the role is separate from fixing precisely so that someone is always commanding.
Severity — SEV levels: A pre-agreed classification (commonly SEV-1 critical → SEV-5 cosmetic) that maps an incident to a response: who is paged, whether executives are notified, whether the org communicates publicly. A decision rule set in peacetime, never negotiated mid-incident; when unsure between two levels, treat it as the higher one and re-grade calmly in the postmortem.
Blameless postmortem — blameless incident review: A written incident analysis that assumes everyone acted with good intentions on the information they had — so the failure belongs to the system, not the people. "Human error" is where the analysis starts, never where it ends; strong reviews list multiple contributing factors across code, process, and detection, and produce systemic, owner-shaped action items. Blamelessness is practical, not just kind: people who fear blame hide the facts the fix depends on.
Observability: The ability to understand any state your system gets into — including ones you never predicted — by interrogating its telemetry from the outside, without shipping new code to do it. Contrast with monitoring, which answers questions you predicted in advance via dashboards and alerts. The working test: when a novel, weird failure arrives, can you slice your data ad hoc to isolate it?
High cardinality — high-dimensionality data: A field with a huge number of possible values — customer ID, app version, build ID. Traditional metrics systems choke on such fields (each value multiplies the stored time series), so they get dropped — yet they're precisely the fields that answer unknown questions like "which customers on which app version hit this?"
Percentile / p99 — tail latency: A latency percentile: p99 is the time within which 99% of requests complete — meaning 1 in 100 real users experiences worse. Principals report percentiles, not averages: the average is a number no actual user experienced, and the tail often belongs to your most valuable customers. With fan-out (one request → many backend calls), rare backend tails amplify into the typical user experience — which makes tails an architecture concern.
Strategy kernel — the kernel: Richard Rumelt's minimal logical skeleton of any good strategy: a diagnosis (an honest, evidenced account of the critical challenge), a guiding policy (the chosen approach — including what it rules out), and coherent action (concrete moves that carry out the policy and reinforce each other). Miss any part and you have a wish, a slogan, or a to-do list — not a strategy.
Guiding policy: The middle part of the strategy kernel: the overall approach chosen to address the diagnosis. Its defining property is exclusion — a real policy forbids reasonable options and would be contested by a skeptical peer. A policy nobody could disagree with ("use the right tool for the job") decides nothing and is fluff.
Core vs context — the core/context test: Geoffrey Moore's distinction (Dealing with Darwin, 2005): core is any activity that creates differentiation customers will pay for; context is everything you must do competently but that wins you no customers by being better than market standard. The build-vs-buy first cut: build core, buy context — and re-check over time, because core commoditizes into context.
Two-way door — Type 2 decision: Jeff Bezos's framing (2015 shareholder letter): most decisions are reversible two-way doors that deserve fast, lightweight decision-making; a minority are consequential, nearly irreversible one-way doors needing slow deliberation. The Principal-level move is noticing that reversibility is often a design choice — a vendor wrapped behind an interface you own is a two-way door; the same vendor woven through business logic is not.
Platform tax — premature platformization: The cost of building shared infrastructure before a real repeated need exists: roughly 3× build cost (Glass's rule of three), a team staffed to maintain it forever, and product teams slowed by an abstraction designed before its requirements were known. A classic staff+ failure mode, because a platform looks like scope; the antidote is waiting for ~three real consumers and extracting the platform from what they actually built.