OKRs point. Commitments deliver.

Every quarter, somewhere, an engineering organisation with beautifully written OKRs discovers it cannot say what it actually promised anyone. The objectives were inspiring, the key results were measurable, the check-ins happened — and when the CFO asks which of the things sales was told about will actually ship, the room reaches for a spreadsheet that does not exist.

The instinct is to blame the OKRs. They are innocent. They were never designed to carry that information, and the gap has a name.

Two different objects

An OKR is a direction with a measurement: where we are trying to move, and how we will know we moved. It deliberately does not say who does what, with how much capacity, by when — that abstraction is the feature, the thing that lets a hundred people align without a hundred rows of detail.

A commitment is a promise: this demand, this owner, this capacity, this target. It deliberately does not say why the work matters in the grand scheme — that context lives elsewhere. It says what was agreed, in terms specific enough to later check whether it was kept.

The two are not rivals and cannot substitute for each other, which is exactly how they end up misused: each is regularly asked to do the other's job, and each fails at it in a characteristic way.

Direction without promises

Run on OKRs alone and the quarter fills with motion nobody can audit. Work gets loosely associated with key results ("this supports KR2"), but nothing forces the question a promise forces: who, how much, by when, at the cost of what else. Dates get spoken in meetings and live nowhere. At quarter end the KRs moved or did not, and either way nobody can trace the result to specific promises kept or broken — so nothing specific is ever learned. The objective was met the way weather happens: genuinely, but unaccountably.

Promises without direction

The inverse failure is older: a commitment ledger with no direction becomes a feature factory. Every promise is individually well-formed — owned, sized, dated, closed — and the sum is strategically random, because the only prioritisation force is requester energy. Ranking by what the organisation is trying to change needs the direction stated somewhere; OKRs are a perfectly good somewhere.

The seam between them

The two systems meet at exactly one point: prioritisation. Direction decides the order in which decision-ready demands walk down each team's capacity line; the commitments are what come out the other side. That is the whole integration — no tooling, no mapping exercise, no OKR-to-epic hierarchy. A demand does not need to "belong" to a key result; the room ranking demands needs to know the direction, and the direction's authors need to read the ledger to see whether the quarter's promises actually serve it.

What to avoid is the popular middle thing: treating a key result as if it were a commitment. "Reduce onboarding time 30%" promises nobody anything — no owner gave capacity, no date was agreed, no readiness bar was cleared. When it slips there is nothing to examine, and when it lands nobody knows what to repeat.

Where DeliverySheet sits

The product holds the promise side only: demands, owners, team-given capacity, recorded exceptions, honest closes. It has no OKR feature and does not want one — set direction wherever your organisation already sets it. What it adds is the half that OKR tooling structurally cannot: a ledger where "what did we promise, and was it kept?" has an answer. Direction points. Commitments deliver. Keep both, and keep them separate.