Performance Metrics Language

Option C — identifies the specific metric (P99), the specific endpoint (search), the before and after values, the improvement factor, and the cause.

Latency improvement narrative structure:

"We reduced [metric] on [endpoint/service] from [before] to [after] 
— a [factor]× improvement — by [change made]."

Calculating improvement factor:
1,400ms ÷ 320ms = 4.375× ≈ 4.4× improvement

Latency vocabulary:
• "reduced latency from X to Y" — the core phrase; "reduced" is active, clear
• "a Nx improvement" — improvement factor (divide before by after)
• "cut latency by X%" — percentage reduction: (1 − 320/1400) × 100 = ~77% reduction
• "latency came down from X to Y" — neutral, passive-ish
• "moved from X to Y on P99" — acceptable; less active than "reduced"

Specifying which percentile:
Always say P50, P95, P99 — never just "latency" in a performance review:
• "P50 improved from 80ms to 45ms — median user experience improved"
• "P99 dropped from 1.4s to 320ms — tail latency is no longer a concern"
• "P95 is still at 800ms — we haven't addressed the slow /report queries yet"

Option B — before/after numbers, improvement factor, and the specific architectural cause.

Throughput improvement structure:

"We increased [throughput metric] from [before] to [after] [units] 
— a [factor]× increase — by [change]."

Throughput vocabulary:
• "requests per second" / "rps" — standard unit for API throughput
• "transactions per minute" / "tpm" — used for financial or batch systems
• "events per second" — used for streaming/queue systems
• "messages per second" / "mps" — Kafka, RabbitMQ contexts
• "queries per second" / "qps" — database contexts

Common throughput improvement descriptions:
• "Went from 800 to 3,200 rps — 4× increase" — most natural phrasing
• "Increased throughput by 300%" — percentage language (800 → 3,200 is +2,400 = +300%)
• "We can now sustain peak traffic without autoscaling kicking in" — operational consequence
• "Unlocked 4× more capacity" — business-oriented framing

Note: "handled more traffic" (Option A) and "faster and can handle more load" (Option D) conflate latency (speed) with throughput (volume). They are different metrics:
• Latency: how long a single request takes
• Throughput: how many requests the system handles per unit time

Option B — before/after values, percentage reduction, cause, and SLO context.

Error rate narrative structure:

"We brought the error rate down from [before] to [after] 
— a [X%] reduction — by [cause]. 
We're now [within/approaching/breaching] our [X%] SLO target."

Calculating a percentage reduction:
(0.12 − 0.03) / 0.12 × 100 = 75% reduction

Error rate vocabulary:
• "brought the error rate down" — most professional phrasing
• "reduced the error rate by X%" — percentage-based
• "error rate dropped from X to Y" — passive/neutral
• "cut errors by X%" — informal but clear
• "we're within SLO" / "we've breached SLO" — connects metric to commitment

Describing SLO context:
• "Well within our SLO target of 0.1%" — healthy margin
• "Just under our SLO target" — meeting target, but with no margin
• "Still above our SLO target despite the improvement" — improvement made, but not yet compliant
• "This brings us back into SLO compliance" — recovering from a breach

Precision matters: "error rate" means errors per total requests as a percentage. Do not conflate with "number of errors" — you could have more errors but a lower error rate if volume increased.

Option B — specific metric (CPU utilization), specific value (78%), comparison to target (55%), gap (23 percentage points), diagnosis (CPU-bound), and recommended action.

Resource utilization narrative structure:

"[Metric] is at [X]% at [condition] 
— [X] [percentage points/times] above/below our [Y]% target — 
indicating [diagnosis]. 
We need to [action] before [consequence]."

Resource utilization vocabulary:
• "CPU utilization" — correct term (not "CPU usage" — though widely used)
• "memory utilization" / "memory pressure" — the latter implies approaching limits
• "disk IOPS" — I/O operations per second; disk-bound performance
• "network throughput saturation" — NIC near capacity
• "CPU-bound" — bottleneck is processing speed
• "memory-bound" — bottleneck is RAM capacity or bandwidth
• "I/O-bound" — bottleneck is disk or network I/O
• "sitting at X%" — present/persistent state (vs. "peaking at" for transient)
• "percentage points" vs. percent — "78% vs 55% = 23 percentage points difference, NOT 23%"; to say "23% higher" would be ambiguous and technically mean 55% × 1.23 = 67.65%

Option B — names the regression, quantifies it, identifies the specific endpoint, names the likely cause with evidence, and recommends action.

Performance regression vocabulary:
• "introduced a performance regression" — the standard phrase for "made things slower"
• "caused a regression in [metric]" — alternative form
• "performance degraded from X to Y" — describes the change
• "X× slower than baseline" — factor comparison
• "the query plan shows a full table scan" — evidence for the cause
• "missing index on [column]" — specific diagnosis
• "I'd recommend addressing this before merging" — actionable request, not a demand

PR performance review structure:
1. Name the regression: "this change introduced a regression in..."
2. Quantify: "from X to Y — a Nx slowdown"
3. Identify the cause: "the most likely cause is..."
4. Show evidence: "the query plan shows / the profiler trace shows"
5. Recommend action: "I'd recommend [fix] before merging"

Why "might be worse" (Option C) is insufficient:
In PR reviews, performance claims need numbers from actual tests. "Might be worse" without data is a feeling, not an observation — it will be dismissed or require the author to add their own numbers anyway.

Option C — translates technical metrics (P99 latency) into user experience language and then into business impact (revenue).

Translation chain for leadership presentations:

Technical metric → User experience description → Business impact

Example chain:
• Technical: "P99 latency reduced from 1.2s to 290ms"
• User experience: "customers on the slowest 1% of connections wait under 300ms instead of over a second"
• Business impact: "2.1% lift in completed checkouts → ~$180K/month"

Translation vocabulary:
• "P99" → "the slowest 1% of users / connections"
• "99th percentile" → "1 in 100 users"
• "error rate of 0.5%" → "1 in 200 transactions fails"
• "4× throughput increase" → "can serve 4× as many users simultaneously without adding infrastructure"
• "400ms reduction in median latency" → "the average page loads nearly half a second faster"

Connecting to business outcomes:
• "Google research shows 100ms of latency reduces conversion by ~1%" — cite known benchmarks
• "Our A/B test showed a [X]% lift" — your own data is most credible
• "At our current conversion rate, Y ms of improvement is worth approximately $X/month"
• "This reduces our infrastructure cost by $X/month by eliminating the need for 3 additional pods"

Leadership presentations live or die by the business translation. Engineers who can connect technical metrics to revenue or cost speak the language that decisions are made in.