# OKR Design Audit — Engineering Team (12 people) **Time Horizon:** Q3 2026 | **Company Strategy:** Enterprise readiness + reducing churn from reliability issues --- ## TRACK 0: OKR CONTEXT & COMMON FAILURE RISKS | Dimension | Classification | Rationale | |-----------|---------------|-----------| | OKR maturity | Developing | INFERRED — single, cleanly-structured objective with reasonable KR count suggests some OKR experience, but lack of baselines/owners suggests process isn't fully mature | | Primary OKR failure risk | Output vs. outcome confusion (KR3) | INFERRED — deploy time is a process/velocity metric, not a reliability outcome | | Alignment direction | Bottom-up | INFERRED — the OKR doesn't explicitly reference "enterprise" or "churn," suggesting it was drafted from team-level priorities and not derived top-down from the stated strategy | | Time horizon fit | Uncertain | INFERRED — no baselines given for current P1 rate, uptime, or deploy time, so a single quarter's achievability can't be verified | **Failure mode priority map:** | Failure Mode | Priority | Evidence Type | Conf | |-------------|----------|---------------|------| | Objectives are outputs, not outcomes | LOW | STATED | 80 | | Key results are tasks, not measurable outcomes | MED | INFERRED (KR3 specifically) | 70 | | No line-of-sight from team OKRs to company strategy | MED-HIGH | INFERRED | 65 | | Too many OKRs — focus diluted | LOW | STATED | 90 | | KRs set to guarantee 100% achievement — no stretch | HIGH (unresolved) | INFERRED | 55 | --- ## TRACK 1: OBJECTIVE-BY-OBJECTIVE QUALITY AUDIT ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **OBJECTIVE: Improve platform reliability** ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Objective quality:** | Criterion | Assessment | Issue (if any) | Evidence Type | |-----------|------------|----------------|---------------| | Outcome-oriented (not output) | YES | Reliability is a genuine outcome, not a deliverable | STATED | | Inspirational and clear | NO | Generic phrasing — doesn't name who benefits (enterprise customers) or why it matters (churn) | STATED | | Achievable in stated time horizon | UNCLEAR | No baseline for incidents/uptime provided, so a one-quarter push can't be sized | INFERRED | | Aligned to company strategy | PARTIAL | Ties to "reliability issues" half of the strategy but doesn't touch "enterprise readiness" (SLAs, compliance, dedicated support) | INFERRED | **Objective score: 3/5 | Rewrite needed: YES** Rewritten objective: *"Deliver enterprise-grade reliability that eliminates the incidents driving customer churn"* **Key results audit:** | KR | Measurable? | Outcome (not task)? | Ambitious enough? | Owner clear? | Score (1-5) | Rewrite | Evidence Type | |----|------------|---------------------|------------------|-------------|------------|---------|---------------| | Reduce P1 incidents by 50% | YES | YES | Unclear (no baseline) | NO | 3 | "Reduce P1 incidents from [X/quarter baseline] to [Y] — a 50% reduction — owned by SRE/on-call lead" | INFERRED (owner, ambition) | | Achieve 99.9% uptime | YES | YES | Unclear — 99.9% is a common default SLA; if current uptime is already ≥99.9%, this KR guarantees near-100% achievement with zero stretch | NO | 2 | "Improve uptime from [baseline]% to 99.95%, aligned to enterprise SLA tier" | INFERRED | | Cut average deploy time to under 10 minutes | YES | NO — this is an engineering-velocity metric, not a reliability outcome. It may even cut the other way: faster deploys can mean more frequent changes and *more* incident risk | Unclear | NO | 2 | "Reduce Mean-Time-To-Recovery (MTTR) for P1 incidents from [baseline] to under [X] minutes" — reframes as a genuine reliability outcome | INFERRED | **Assumption ledger:** | Assumption | Where It Enters | If False — OKR Effect | |------------|----------------|----------------------| | Current baselines for P1 rate, uptime, and deploy time are lower than the stated targets | KR1, KR2, KR3 | Targets could already be met (no stretch) or be unrealistic for one quarter | | The team has full ownership of uptime and incident rate | KR1, KR2 | If dependent on third-party infra/vendors, these become health metrics the team can't fully move — a classic "not truly a KR" trap | | "Enterprise readiness" in company strategy is primarily a reliability problem | Track 2 alignment | If enterprise readiness also requires compliance, security certs, or dedicated support tiers, this OKR covers only part of the strategy | | Reducing deploy time improves reliability | KR3 | Faster deploys can increase change frequency and incident risk, working against the objective rather than for it | --- ## TRACK 2: STRATEGY ALIGNMENT MAP | OKR | Supports Company Priority | How | Alignment Strength | Evidence Type | |-----|--------------------------|-----|-------------------|---------------| | Improve platform reliability (all 3 KRs) | "Reducing customer churn from reliability issues" | Directly reduces incident frequency and downtime, the stated churn driver | Strong | STATED | | Improve platform reliability (all 3 KRs) | "Enterprise readiness" | Uptime/incident metrics support readiness but don't address enterprise-specific needs (contractual SLAs, compliance, dedicated support/escalation paths) | Partial | INFERRED | **Alignment gaps:** None of the three KRs is unaligned outright, but the OKR set skews entirely toward the churn half of the strategy and only weakly touches the enterprise-readiness half. **Missing OKRs:** No team-level OKR addresses enterprise-specific reliability commitments (contractual SLA guarantees, status-page/incident communication, dedicated infrastructure for enterprise tiers) — flagged as a possible coverage gap, though this may be intentionally owned by another team. --- ## TRACK 3: OKR PORTFOLIO ASSESSMENT | Dimension | Assessment | Finding | Evidence Type | |-----------|------------|---------|---------------| | OKR count | 1 objective, 3 KRs | Within optimal range (<5 Obj, <5 KR each), but a 12-person team running only one objective for the quarter may be under-scoped unless intentional | STATED/INFERRED | | Ambition level | Unclear | Can't classify stretch vs. safe vs. aggressive without baselines — 99.9% uptime in particular risks being a "safe" target already met | INFERRED | | Balance | Single-dimension (reliability only) | No growth, delivery, or team-health objective this quarter — may be a deliberate reliability sprint, but worth confirming it's intentional | INFERRED | | Measurability | 3 of 3 KRs have numeric targets | 100% measurable in form; due date is implicit (end of Q3) for all three | STATED | --- ## TRACK 4: COMPLETE REWRITTEN OKR SET **OBJECTIVE 1: Deliver enterprise-grade reliability that eliminates the incidents driving customer churn** - **KR 1:** Reduce P1 incidents from **[baseline needed]**/quarter to **[baseline × 0.5]** — a 50% reduction — owned by the on-call/SRE lead - **KR 2:** Improve platform uptime from **[current baseline]%** to **99.95%**, matched to the enterprise SLA tier — owned by the infrastructure lead - **KR 3:** Reduce Mean-Time-To-Recovery (MTTR) for P1 incidents from **[baseline]** minutes to under **[target]** minutes — owned by the incident-response lead *Note: "Cut average deploy time to under 10 minutes" is deliberately dropped from this objective — it's an engineering-velocity metric, not a reliability outcome. If deploy speed still matters this quarter, it belongs under a separate "Improve engineering velocity" objective, or as a supporting metric tracked alongside the OKRs rather than as a KR itself.* **Baselines required before targets can be finalized:** current P1 incident count/quarter, current uptime %, current MTTR. --- ## TRACK 5: OKR DESIGN INTEGRITY CHECK | Check | Status | Note | |-------|--------|------| | Every objective is an outcome, not an output | ⚠ | Objective itself is fine; original KR3 was output-shaped, resolved in rewrite | | Every KR has a specific number and due date | ⚠ | Numbers present, but real targets can't be locked in until baselines are supplied | | Total OKR count is ≤ 5 objectives | ✅ | 1 objective | | All objectives have a clear alignment to company strategy | ⚠ | Strong on churn, only partial on enterprise readiness | | Rewritten set is fully populated (no objectives left as-is that scored <3) | ✅ | Objective and all 3 KRs rewritten | | All INFERRED findings are labeled | ✅ | | **OKR CONFIDENCE: 55/100** — Structural quality can be assessed directly from the text, but ambition, achievability, and true alignment strength all hinge on baseline data that wasn't provided. **Biggest unknown:** Current baseline figures for P1 incident rate, uptime, and deploy time/MTTR. Without these, it's impossible to tell whether the targets are a genuine stretch, already achieved, or unrealistic for a single quarter. **STATED vs. INFERRED breakdown:** *STATED (directly evaluable from the text as given):* - The objective is outcome-oriented in form - KR1 and KR2 are outcome-shaped and numerically measurable - OKR count (1 objective, 3 KRs) is within the optimal range - The objective connects to the "reliability issues" half of company strategy *INFERRED (assumptions made due to missing information):* - OKR maturity level and alignment direction (top-down vs. bottom-up) - Achievability within Q3 2026 (no baselines given) - Whether 99.9% uptime represents a stretch or an already-met target - KR3 (deploy time) being a proxy/output metric rather than a reliability outcome - Partial (not full) alignment to "enterprise readiness" - Missing owner assignment on all three KRs - Possible coverage gap on enterprise-specific reliability commitments