OKRs need heartbeat metrics

OKRs are useful when a team is trying to change something important. They are much less useful when a team is protecting something important. That difference sounds small until planning season starts and every function is asked to produce objectives, key results, confidence scores, and quarterly narratives even when its main job is to keep the company running.

The thesis is simple: OKRs need heartbeat metrics, not forced objectives.

When leaders require every team to write OKRs, operational work gets disguised as strategy. Reliability becomes an objective. Billing accuracy becomes an objective. Data freshness becomes an objective. Customer support quality becomes an objective. The format looks tidy, but the company has lost a critical distinction between change work and continuity work.

Christina Wodtke makes this distinction sharply in her essay on why business as usual is a terrible name for vital work. Her alternative language, heartbeat work, is better because it treats operational health as something alive, visible, and worthy of management rather than as background noise beneath the strategy deck. The practical implication is not that operational teams should avoid measurement. It is that they need health metrics, review rituals, and escalation rules before they need artificial OKRs. Wodtke’s argument is worth reading in full.

Not every team needs an OKR

A good objective says: we are going to move from one state to another because the current state is no longer enough. It has direction, tension, and choice. A team entering a new market might need an OKR. A product group trying to reduce activation friction might need an OKR. A platform team replacing a fragile dependency might need an OKR if the work changes the risk profile of the business.

But a team that must keep payroll accurate, uptime stable, invoices correct, fraud queues moving, or data pipelines healthy may not need a quarterly objective for that work. It needs a heartbeat. The work is not less important because it is recurring. In many companies it is more important, because failure is immediately visible to customers, employees, regulators, or cash flow.

Forcing that team to invent an objective creates two problems. First, the language becomes performative. Keep the lights on becomes delight internal stakeholders with world-class operational excellence. Second, strategic capacity becomes harder to see. If the team spends 80 percent of its time protecting core operations, an OKR format may imply a freedom to change that the team does not actually have.

This is related to decision rights. If a team is accountable for a health metric but cannot change staffing, tooling, process, or risk tolerance, then the metric is only a reporting burden. As argued in Product operating models start with decision rights, operating models fail when responsibility and authority are split. The same is true for OKRs.

Heartbeat work needs health metrics

Heartbeat metrics are not vanity dashboards. They are the small set of measures that tell the organization whether a vital operating system is healthy enough to keep running without becoming the quarter’s strategic focus.

A health metric should have a clear owner, a normal range, a review cadence, and an escalation threshold. For a payments team, that might include authorization rate, settlement failures, chargeback backlog, and reconciliation latency. For a data platform team, it might include pipeline freshness, critical job failure rate, incident recovery time, and the number of downstream dashboards affected by known defects. For support, it might include first response time, reopening rate, backlog age, and escalation volume.

The point is not to measure everything. The point is to define what would cause the company to interrupt its strategic push.

That makes heartbeat metrics different from key results. A key result asks whether a strategic change is happening. A health metric asks whether the operating system can safely continue. One is a push. The other is a pulse.

This is why OKR reviews and operational reviews should not be collapsed into the same ritual. If every health metric is discussed as a key result, the room becomes a status meeting. If every objective is discussed like a health metric, the room becomes a maintenance meeting. Product leaders need both, but they need different questions.

For health metrics, ask: is the system inside its normal range, who owns the next action, and what threshold changes the plan? For OKRs, ask: are we learning fast enough, should the bet continue, and what decision becomes possible if we succeed? That last question connects OKRs to product bets. A roadmap that contains real bets should also show what evidence keeps, changes, or kills them, as in Roadmaps need bet ledgers.

When should a health metric become an OKR?

A health metric becomes an OKR when normal management is no longer enough.

If data freshness slips for one week and the team restores it within the agreed threshold, the metric stays in the heartbeat review. If freshness keeps degrading, customers lose trust in analytics, and the platform requires architectural change, then the work may deserve an objective. The objective is not maintain fresh data. The objective is to restore trust in decision data by changing the system that produces it.

That promotion rule matters. Without it, teams either hide operational pain because it does not fit the strategy, or they turn every red metric into an objective and destroy focus. The rule should be written before the quarter starts.

A simple rule can be enough:

• Green means the team manages the metric inside its operating review.
• Yellow means the owner reports the cause and expected recovery path.
• Red means leadership decides whether to interrupt OKR work, add capacity, reduce scope, or promote the issue into a strategic objective.

Notice the leadership decision. Escalation is not a request for more slides. It is a decision point about trade-offs. If the company says uptime is critical but never cancels feature work when reliability falls below threshold, the health metric is decorative. If the company says customer trust matters but treats support backlog as a local problem, the OKR system is lying about priorities.

Fix the review ritual

The operating change is straightforward: separate the planning inventory before writing any objective.

Start with one planning cycle. List the teams, systems, and recurring responsibilities. Classify each one as objective-led, health-metric-led, or escalation-led. Objective-led teams are actively changing a business outcome. Health-metric-led teams are protecting a vital service within agreed thresholds. Escalation-led situations are unhealthy systems that may need executive trade-offs before they can return to normal management.

Then ask each team for the right artifact. Objective-led teams write objectives and key results. Health-metric-led teams write health metrics, thresholds, owners, and review cadence. Escalation-led teams write the decision they need: more capacity, reduced demand, architectural investment, risk acceptance, or a temporary pause on another commitment.

This also improves morale. People know when their work is being respected on its own terms. The team running billing operations does not need to pretend that accurate invoices are an inspirational quarterly moonshot. The platform team does not need to rename incident reduction as transformation theatre. They need leaders to see the pulse of the business and to act when it weakens.

OKRs should remain a tool for strategic change. Heartbeat metrics should make vital continuity visible. The healthiest planning systems do not force every team into the same template. They decide what kind of work is in front of them, then choose the management ritual that fits.

Audit the next cycle before the templates go out. Which teams truly need objectives? Which teams need health metrics? Which red metric should have the authority to interrupt the plan? If those answers are unclear, the company does not have an OKR problem. It has a heartbeat problem.