OKRs, KPIs & Measuring the Team

Leads inherit dashboards, OKR slides, and opinions about what “good” means. Your job is to separate three layers: the mission (why we exist), OKRs (what changes this cycle), and KPIs (how the system is doing continuously). Confusing them produces vanity goals, gamed numbers, and busy teams that do not move outcomes.

Domain knowledge here is measurement design: pick few outcomes, pair them with honest counters, and protect the team from targets that punish learning.

OKRs: outcomes for a cycle

Objectives and Key Results are a cycle tool (usually a quarter). An Objective is qualitative and motivating. Key Results are measurable evidence that the objective moved. Keep the set small: three objectives is often too many for one team.

• Objective: direction in plain language (not a metric).
• Key Results: 2-4 measures or milestones that prove progress.
• Owner: one accountable driver per OKR set.
• Time box: a cycle with a mid-point check, not a yearly wish list.
• Scoring: use honest grades; 0.7 on a hard KR can be success if ambition was real.

1. Start from user or business outcomes, not from a backlog dump.
2. Draft KRs that a skeptic can audit (data source + definition).
3. Kill or park work that does not map to a KR or to agreed KTLO.
4. Review weekly: blockers and learning, not slide cosmetics.

KPIs: the health of the system

KPIs (key performance indicators) are ongoing signals about how the machine runs. They are not the same as OKRs. You do not “finish” a KPI; you watch it, set thresholds, and investigate when it breaks.

• Product KPIs: activation, retention, conversion, latency the user feels.
• Delivery KPIs: DORA-style deploy frequency, lead time, change fail rate, restore time.
• Reliability KPIs: SLO burn, error budget, incident count by severity.
• Team health KPIs: on-call load, review lag, hiring funnel time (use carefully).
• Quality KPIs: escaped defects, flaky test rate, support ticket themes.

1. Pick a short KPI set tied to your mission (usually under 10).
2. Define owner, source, and “what we do if red.”
3. Separate leading indicators (early) from lagging outcomes (late).
4. Never turn every KPI into a personal performance weapon.

OKR vs KPI vs task (keep them straight)

Use this split in planning conversations so stakeholders stop mixing ambition with telemetry.

• Mission / north star: long-lived purpose and primary outcome (rarely changes).
• OKR: cycle ambition with KRs that may include KPI movement or milestones.
• KPI: continuous health; alert and diagnose; do not “complete” it.
• Task / project: how you move a KR; belongs in the backlog, not as a fake KR.

If everything is an OKR, nothing is a priority. If everything is a KPI target, people will game the graph.

Design metrics that teams can own

Good measures are influenced by the team, hard to game, and connected to user value. Pair quantity with quality. Pair speed with safety. Publish definitions so debates are about reality, not spreadsheet folklore.

1. Write a one-line definition and data source for each metric.
2. Add a counter-metric (for example, speed + change fail rate).
3. Baseline before you set targets; targets without baseline are theater.
4. Review gaming risk: what bad behavior would raise this number?
5. Align metrics with team topology: stream teams own outcome KPIs; platforms own adoption and reliability of the paved road.

Operating rhythm for goals and metrics

• Quarterly: set or refresh OKRs with product and stakeholders.
• Monthly: deep KPI review and one experiment on a red signal.
• Weekly: OKR progress + risks in the team written update.
• Incident/postmortem: check whether KPIs would have warned you earlier.
• Hiring and capacity: connect headcount asks to OKR load and KPI pain, not vibes.