OKRs have become the default goal-setting framework for technology companies. They are well-designed for what they do: aligning a team around ambitious targets, creating shared language for aspiration, and providing a periodic rhythm of reflection.
What they don’t do is create accountability for specific commitments.
The distinction that matters
An OKR says: “We want to increase user retention by 20%.”
A commitment says: “The growth team will deliver the new onboarding flow by March 15. The infrastructure team will maintain p99 latency below 200ms to support it. The design team will provide final assets by February 28. These terms are agreed and signed by the respective leads.”
The OKR describes a destination. The commitment describes a set of obligations between specific parties, with specific terms, and specific owners.
OKRs are aspirational. Commitments are enforceable.
Where OKRs fall short
OKRs are excellent for the top of the organizational stack: setting direction, communicating priorities, creating cultural alignment. But when you try to use them as execution infrastructure, you encounter a set of systematic failures:
Ownership diffusion. A key result like “reduce churn by 15%” doesn’t tell you who is responsible for each element of the work that would achieve it. Multiple teams share a vague relationship to the goal without any team owning a specific commitment.
No counterparty. An OKR is a statement made by a team to itself. There is no counterparty; There’s no other party who has accepted obligations in exchange, and whose acceptance creates mutual accountability.
Negotiation is implicit. OKRs are typically set by managers and presented to teams for acknowledgment. The negotiation that should happen, the back-and-forth that surfaces unrealistic expectations and hidden dependencies, is often skipped or made perfunctory.
Scoring is disconnected from consequences. A team that scores 0.7 on a key result “didn’t quite hit it.” What happens next? In most organizations: not much. The framework doesn’t specify consequences, so none are reliably applied.
What the Collaborate by Contract framework provides
The CBC framework addresses these failures directly.
It starts from the premise that organizational commitments are contracts: not in the legal sense, but in the structural sense. A commitment worth making is worth capturing with precision: parties, terms, owners, effective date, conditions, and lifecycle.
The CBC framework provides:
- Explicit counterparties. Every commitment has parties who have agreed and signed. There is no ambiguity about who is bound.
- Named term owners. Every term in an agreement has a designated person responsible for it.
- Negotiated acceptance. Commitments go through a draft-and-negotiate phase before they are signed. Concerns surface early, not late.
- Immutable record. Once signed, the agreement exists as a permanent record. Changes require re-negotiation, not unilateral revision.
Part 2
In Part 2, we walk through a concrete cross-team scenario: what OKRs leave ambiguous, and how CBC closes the gap with specific agreement structures.
