The Engineering OKR Check-In Template That Doesn't Become a Sprint Standup

I've run OKRs with engineering teams for about a decade, and the check-in is the part that breaks first. It quietly turns into a Jira review, somebody reads ticket statuses out loud, and the actual objectives go untouched for the whole quarter. This template is built to stop that. It pulls the conversation back to reliability and delivery signals, the numbers that tell you whether the system is actually getting better, not just whether last sprint closed.

By Max Bondarenko · Last updated June 2026

The template, up front

Here's the whole thing. Five questions, answered async, before anyone gets on a call. The trick with engineering is that the team already lives in dashboards and standups, so the check-in has to ask something those rituals don't. It asks about the objective's movement, not the sprint's. If your answers could be lifted straight from yesterday's standup, you're filling it out wrong.

The five questions

01Where does each key result sit right now, with the baseline and the target both stated? (For example: uptime moved from 99.5% to 99.7% against a 99.95% target; MTTR went from 4h to 3h heading toward 45m.)
02Which reliability or delivery signal moved this week, and was it because of work we did or noise in the system?
03What did we ship toward this objective that a customer or another team can actually feel, separate from tickets closed?
04What's the one thing blocking the slowest key result, and who owns clearing it by next check-in?
05Is any target now wrong, too soft, too hard, or measuring the wrong thing, and should we revise it this week?

Why each question is there

Question one forces the baseline-and-target framing every single week. I'm strict about this because a key result with no baseline is just a wish. "Improve uptime" tells me nothing. "99.5% to 99.95%" tells me we're chasing roughly a 10x cut in allowed downtime, which is a real engineering project with real tradeoffs. Same with MTTR. Going from 4 hours to 45 minutes isn't a tweak, it's better alerting, runbooks, and probably on-call changes. Stating both numbers every week keeps the team honest about distance left.

Question two is the one that separates engineering check-ins from everything else. Reliability numbers are noisy. Uptime can look great for three weeks because nothing stressed the system, then collapse on one bad deploy. Deploy frequency can spike because someone split one change into nine PRs. So I make the team say whether the movement was earned or accidental. The week I learned this lesson the hard way, a team I ran celebrated MTTR dropping from 4h to under an hour against a 45m target, and it turned out we just hadn't had a real incident that month. The next sev-1 took five hours because nobody had touched the runbook. The number lied, and we believed it because we didn't ask why it moved.

Question five is the most important one and the one teams skip. Revise a wrong target early, in week 4, not week 12. If you set deploy frequency at "once a day" and by week four you're shipping twice a day with no quality cost, the target was too soft and it's giving you a false sense of progress. Fix it now while there's runway. If you set 99.95% uptime against a 99.5% baseline and a hard dependency makes that physically impossible this quarter, say so in week 4 and renegotiate. Don't grind toward a number you already know you'll miss and then write a sad retro about it. Targets are hypotheses. Check-ins are where you test them. Question three exists for the opposite failure: a team can hit every metric and still ship nothing a human notices, so I make them name the felt outcome.

Scoring: keep it to three states

I don't use 0.0-to-1.0 decimal scoring in weekly check-ins. It invites debate about whether something is a 0.6 or a 0.7, which wastes the meeting. Three states, each with a forced action. The point of a status isn't to grade the team, it's to trigger the next move. A status with no action attached is just a color on a slide.

On track	The key result is moving at the pace needed to hit target by quarter-end (for example, uptime up 0.1 point per week from a 99.5% baseline toward 99.95%). Action: do nothing new. Protect the work that's working and don't add scope.
Behind	Moving in the right direction but too slow to land the target on time (MTTR down from 4h to 3h, but it'll miss the 45m target at this rate). Action: name the single biggest accelerant and reallocate one person to it this week, or formally lower the target in question five.
At risk	Flat, going backwards, or blocked by something the team can't clear alone (deploy frequency stuck at 3 per week against a daily target because the staging pipeline is down). Action: escalate the specific blocker to the owner who can unblock it, with a date, before the next check-in.

Weekly status, and the one action each state demands

How to actually run it

Async by default. The five questions get answered in writing before any call, by the person who owns each key result, not by a manager summarizing. That writing is the work. If people fill it in honestly, half the weeks you won't need a meeting at all, and that's the goal. When you do meet, it's 25 minutes, not an hour, and only the leads who own key results plus whoever can clear an escalated blocker need to be there. The whole squad does not need to sit through this.

Skip the live meeting any week where everything is "on track" and nobody raised a blocker. Reading the written answers is enough, and protecting the team's focus is more valuable than the ritual. Run it weekly during normal quarters, but go to twice a week if you're in the middle of a hard reliability push where a number like MTTR is swinging day to day. And keep it separate from sprint planning, on a different day if you can. The moment the OKR check-in and the sprint review share a calendar slot, the OKRs lose, every time. The urgent ticket talk always crowds out the quarter-level conversation.

Questions people actually ask

How is an engineering OKR check-in different from a sprint standup?

A standup is about tickets and the next day or two; the OKR check-in is about whether the quarter's objectives are actually moving. If your check-in answers sound like your standup, you're tracking activity instead of outcomes. I force the difference by asking for reliability and delivery signals with baselines and targets, like uptime from 99.5% to 99.95%, which no standup ever covers.

Should I score reliability key results weekly when the numbers are so noisy?

Score them, but always ask whether the movement was earned or just luck. Uptime can look perfect for weeks simply because nothing stressed the system, then crater on one bad deploy. I once had a team celebrate MTTR drop from 4h to under an hour against a 45m target, and it was really just a quiet month; the next real incident took five hours because the runbook had rotted.

What metrics belong in an engineering OKR check-in?

Reliability and delivery signals you can put a baseline and target on: uptime (say 99.5% to 99.95%), MTTR (4h to 45m), deploy frequency (3 per week to daily), change failure rate, lead time for changes. Avoid vanity counts like tickets closed or lines shipped. The test is simple: would a customer or another team feel it if this number moved?

When should I change a target instead of just missing it?

Decide in week 4, not week 12. If you're crushing a target with no quality cost, say deploy frequency already at twice a day against a daily target, it was too soft and it's hiding real progress, so raise it. If a hard dependency makes a number like 99.95% uptime impossible against a 99.5% baseline this quarter, renegotiate it openly instead of grinding toward a miss. Targets are hypotheses, and the check-in is where you test and revise them early.

Stop running check-ins in a spreadsheet

Okiar is free during beta. Voice check-ins, AI projections, team health — live in minutes.

Start free →