The first agreement is where CBC stops being theory and starts being practice. This is the moment you move from vague promises to explicit commitments. If you skip this step or treat it like paperwork, you’re back in OKR-land: everyone nods in meetings, nobody actually agrees on what “done” means, and three months later you’re shocked by the gap between intent and outcome. Drafting the first agreement together is how you prove CBC is real: clarity before freedom, commitment before execution.

Break the Agreement Down

Every CBC agreement has five non-negotiable components. If one is missing, it’s not an agreement — it’s a wish list.

• Objective: Why this work exists, stated in plain English.
  • Wrong: “Improve engagement.”
  • Right: “Increase weekly active users by shipping feature X to production by May 31.”
• Deliverables: The tangible things that must exist when this is done.
  • Wrong: “Explore approaches.”
  • Right: “Produce a working feature with A/B tested rollout to 20% of users.”
• Dependencies: What this work relies on — other teams, resources, approvals.
  • Wrong: Assume infra will “be ready.”
  • Right: “Infra team delivers API endpoint Y by April 15. If not, fallback is pre-computed data.”
• Ownership: A named person, not a group. No “the team” or “engineering.”
  • Wrong: “Backend team.”
  • Right: “Priya is accountable for backend delivery. John owns frontend delivery.”
• Success Criteria: How we’ll know it’s done, in measurable, verifiable terms.
  • Wrong: “Customer adoption.”
  • Right: “Feature used by 5% of total active users within 30 days post-launch.”

The Process of Drafting

• Sit down with your direct report and co-author the agreement. Don’t dictate it, don’t let them guess at it. Draft together.
• Push for specifics until the agreement is so clear a third party could read it and know what “done” means.
• Write it down — half-remembered agreements aren’t agreements.
• Both sign off. “Yes, I agree to this” isn’t symbolic; it’s binding.

Example: Startup 1-1 Scenario

Imagine you’re leading a small engineering team at a Series A startup. A product manager says, “We need a referral program.” Under OKRs, that becomes an aspirational key result: “Launch referral program to boost user acquisition by 20%.” Three months later, you’ve got mockups, half-baked code, and arguments about what counts as “launched.”

With CBC, you and your engineer draft an agreement:

• Objective: Launch a referral program to drive new user signups.
• Deliverables: A production-ready feature that allows users to send referral links, tracks signups, and issues credits.
• Dependencies: Marketing provides copy by April 10; Design delivers assets by April 15.
• Ownership: Alex owns end-to-end engineering delivery.
• Success Criteria: Feature live in production by May 31, with at least 200 users using referral links within 30 days.

That’s not vague “momentum” — that’s an actual contract. When May 31 arrives, there’s no debate. The agreement was either fulfilled or not.

CBC vs. Traditional Approaches

• OKRs/KPIs: Encourage aspirational goals but allow scope creep, fuzzy accountability, and post-hoc excuses.
• CBC: Locks clarity upfront, names ownership, and sets hard criteria before a line of code is written.

Takeaway

Drafting the first agreement together isn’t bureaucracy — it’s execution insurance. CBC forces you and your direct report to get real about what will be done, by whom, and how success is measured. Do this once, and you’ll never look at vague OKRs the same way again.