The senior lexicon

Listen to a principal engineer in a design review and you hear a specific vocabulary: tradeoff, constraint, non-goal, blast radius, failure mode, one-way door. These are not decoration. Each word compresses a concept the discussion needs, and using them precisely is a large part of what "sounding senior" actually is, because the words force the thinking. This chapter is that vocabulary, organized by what the words do.

Words that frame decisions

• Tradeoff. The load-bearing word of all design conversation: what you give up to get what you want. Senior speech makes tradeoffs explicit and named: "We're trading write latency for read fan-out cost." A proposal described with no tradeoffs is either trivial or not yet understood.
• Constraint. A fact you must design around, as opposed to a preference. "The 300ms budget is a constraint; the ORM is a preference" is a sentence that reorganizes an entire argument.
• Non-goal. What this effort deliberately does not attempt (Chapter 4). Saying "multi-region is a non-goal for v1" converts a future accusation ("you ignored multi-region") into a recorded decision.
• Scope, and its pathologies: scope creep (the quiet accumulation of extra goals; "this is scope creep, let's park it") and descope (the deliberate removal of goals to protect a date; "we can hold Friday if we descope the audit table").
• One-way door vs. two-way door. Amazon-origin, now universal: irreversible versus reversible decisions. The operational rule attached to the words: two-way doors should be decided fast by the people closest to them; one-way doors deserve slow scrutiny. "Is this a one-way door?" is among the highest-value questions in any review.
• MVP-thinking phrases: "What's the smallest version of this that teaches us something?", "thin slice", "walking skeleton". All aim the conversation at sequencing rather than totality.
• "What would have to be true?" The consultant-origin reframe that converts "I don't believe your plan" into a checklist: "For B to win, what would have to be true about traffic growth?" It de-personalizes disagreement instantly, which is why Chapter 5's toolbox quietly relies on it.

Words that describe systems under stress

• Failure mode. How a thing fails, as a designed-for category: "the interesting failure mode is partial write." Asking "what are the failure modes?" is the senior version of "will it work?"
• Blast radius. How much is affected when it fails: "a bad config here has company-wide blast radius." Often paired with containment: "can we shrink the blast radius with per-tenant rollout?"
• Single point of failure (SPOF). The component whose death takes everything with it.
• Critical path. Borrowed from project scheduling into both meanings: the latency path requests actually traverse, and the dependency chain that determines the ship date. "Review from platform is now on the critical path" is precise escalation language (Chapter 10).
• Degradation and graceful degradation. Losing capability partially and on purpose, versus outright failure: "under load we degrade to cached recommendations rather than erroring."
• Backpressure. The system's ability to push back on producers instead of drowning: "there's no backpressure between ingestion and the workers; that's the outage."
• Headroom / capacity / bottleneck / hot path. The performance family: slack remaining, total limit, the narrowest constraint, the code that runs most often. "We have 2x headroom on CPU but the bottleneck is IOPS" is a complete capacity story in one sentence.
• Idempotent. Safe to apply twice. Beloved in retry discussions: "make the handler idempotent and the retry policy stops mattering."
• Race condition / deadlock / thundering herd. The concurrency bestiary; "thundering herd" (everyone retrying at once) earns its keep in any caching or outage conversation.
• Drift. Slow divergence from intended state: config drift, schema drift, "staging has drifted from prod, which is why the test lied."

Words that describe change over time

• Tech debt. Deliberate or accidental shortcuts whose interest you pay on every change. Senior usage is specific, not moral: "this module's debt is that config and code deploy together" beats "this code is bad."
• Migration path. How you get from here to there without stopping the world: "the design is fine; it's missing a migration path."
• Backward compatible / breaking change. Whether existing consumers survive your change unmodified. "Is this breaking?" is often the entire review.
• Deprecate, then sunset. Mark as discouraged-but-working, then remove. "Deprecated in Q3, sunset in Q1" is a complete lifecycle plan.
• Feature flag / rollout / rollback / canary. The safe-change toolkit: toggle without deploy, percentage release, undo, and the small early slice (named for the coal-mine bird) that detects trouble first.
• North star. The long-term direction that near-term steps should point toward: "the north star is one queue per tenant; this PR is a step, not the destination."
• Forcing function. An external constraint that compels action by a date: "the cert expiry is a useful forcing function for the migration."
• Second-order effects. The consequences of the consequences: "first-order, caching cuts DB load; second-order, staleness bugs and cold-start storms." Reaching for second-order effects unprompted is a strong seniority tell.
• Local optimum. Best-in-the-neighborhood but not best overall; usually deployed to argue for a bolder move: "tuning the pool is a local optimum; the global fix is killing the N+1 pattern."

Discussion-steering phrases

The verbal moves that organize conversations, with honest tone notes, because several live on the border of corporate cliché:

The pattern in the tone notes: phrases earn wear. Each was vivid once, became a default, and now signals fluency at best and filler at worst. Use the worn ones sparingly and the precise ones (timebox, steelman, non-goal) freely, and when a plain verb exists, notice that "dig into" outperforms "double-click on" with every audience that matters.

Don't be confused: "leverage", "utilize", and "use" mean the same thing in almost every engineering sentence, and "use" wins. "Utilize" adds syllables, not meaning; "leverage" as a verb is business-dialect that many strong writers deliberately avoid. The same de-inflation applies to "learnings" (prefer "lessons" or "what we learned") and "actionable insights" (prefer saying the action). Senior writing is conspicuously plain; inflated vocabulary reads as junior precisely because it tries to read as senior.

Calibration words

The quiet machinery of senior speech is uncertainty grading. A principal engineer almost never says a bare "yes" or "no" to a hard question; they attach a confidence level, cheaply:

• "Almost certainly" / "very likely" / "likely" / "50-50" / "unlikely" / "I'd be surprised."
• "I'm confident about the design; the estimate is soft."
• "High confidence, weakly held data: one benchmark run."
• "I'd put maybe 70% on the migration finishing clean."

And its partner, the explicit knowledge boundary: "I know the write path well; the replication side I'm guessing about, so weight accordingly." Speech with calibration marks is what allows others to build on your statements safely, which is the actual point of sounding senior: not impressiveness, but load-bearing reliability. The fastest way to acquire the habit is to notice every time you are about to state a guess in the grammar of a fact, and add the one word that marks it: "probably", "I think", "unverified".

👉 The concepts are in place; what remains is raw vocabulary. Next, the word list: the precise adjectives for praising and criticizing work (succinct, rigorous, brittle, egregious), the discussion words (orthogonal, moot, canonical), the AI-era additions (hallucination, grounding), and the chat glyphs (o/, /s, s/x/y/) that carry meaning nobody explains. On to Chapter 14.