In Part 1, we looked at the structural limitations of OKRs as execution infrastructure. In this part, we work through a concrete scenario to show how CBC agreements handle the same situation with greater clarity.
The scenario
An engineering team is rebuilding a critical authentication service. The migration must be zero-downtime. It involves the infrastructure team, the security team, and a downstream product team whose service depends on the auth API.
Using OKRs:
Engineering sets a key result: “Complete auth service migration with zero downtime by Q2.”
What happens in practice:
- The infrastructure team doesn’t know exactly what they’ve committed to provide (new hardware? higher availability? specific network configs?).
- The security team has a vague understanding that they need to review something, but no defined deliverable or deadline.
- The product team is waiting for the new API, but has no visibility into what changes they should plan for or when.
- When the migration slips, there’s no clear record of what was agreed, so the retrospective is a debate about who said what.
Using CBC:
The engineering team creates an AllSign agreement with three parties: Infrastructure, Security, and Product.
The agreement includes:
- Term 1 (Infrastructure): Provision dedicated migration environment with specified hardware specs by March 15. Owner: Priya K., Infrastructure Lead.
- Term 2 (Security): Complete security review of new auth architecture by March 22. Owner: Marcus W., Security Lead. Blocking condition for migration execution.
- Term 3 (Product): Update API client to support new token format by April 1. Owner: Ryan K., Product Lead.
- Term 4 (Engineering): Execute zero-downtime migration cutover between April 5 and April 12. Owner: Dana L., Engineering Lead.
All parties negotiate the terms. Security pushes back on the March 22 deadline and gets it extended to March 29. Product confirms the April 1 client update is achievable. Everyone signs.
What changes
The differences are concrete:
Before migration begins: Every party knows exactly what they’ve committed to, what others have committed to, and what the sequence of dependencies looks like.
During execution: When Infrastructure delivers the environment on March 14 (one day early), that fact is recorded in the agreement audit trail. When Security completes their review on March 28 (one day early), that’s recorded too.
When something slips: If Product misses the April 1 deadline, there is a clear record of what was agreed, who agreed to it, and what the downstream impact is. The conversation is about the gap between commitment and execution, not about who said what in a meeting three months ago.
After the migration: The audit trail shows every party’s performance against their commitments. The organization has a record that doesn’t depend on anyone’s memory.
The underlying difference
OKRs optimize for alignment at the goal level. They are appropriate for strategic planning, where the goal is to create shared direction without over-specifying execution.
CBC agreements optimize for accountability at the execution level. They are appropriate for cross-team commitments, where the cost of ambiguity is measured in slipped deliverables and strained relationships.
The two aren’t mutually exclusive, but if you’re fostering a culture of autonomy, ownership, and accoutability, CBC (and by extension, AllSign) are objectively better.
