Most companies love to set "goals." OKRs, KPIs, mission statements, annual plans — it's all the same theater. The problem? Goals are vague, slippery, and conveniently easy to fudge when things go sideways. A goal is "launch the new platform." A contract is "ship the API gateway by June 15th, with auth, rate limiting, and docs reviewed by the security team." One is a wish. The other is an agreement.
If you want accountability, ditch the aspirational fluff and start operating with contracts.
Why Contracts Beat Goals
- Goals are wish lists. They read like New Year's resolutions: noble intent, zero binding force.
- Contracts are agreements. They define the who, what, and when — with no wiggle room for interpretive dance.
- Goals invite spin. You can "mostly achieve" a goal. You can't "mostly deliver" a contract. It's done or it isn't.
- Contracts clarify expectations. Success criteria, deadlines, owners. No manager ever has to ask, "So what does done look like?"
Breaking It Down
- Commitment vs. Expectation
- Commitment = what you will do.
- Expectation = what might happen if the commitment is fulfilled.
- Example: Commitment: launch the website. Expectation: people will visit it. Only the first belongs in a contract. The second is hope dressed as strategy.
- Ownership
- Contracts name names. Not "the team will deliver." Alice will deliver.
- This makes performance evaluation possible: was the contract kept or broken?
- Success Criteria
- Every contract answers: How do we know it's done?
- Example: "The API gateway is deployed to production, passes security review, and has public documentation." Not "The API gateway is improved."
- Enforceability
- Contracts allow for accountability: missed dates, broken commitments, failed reviews.
- With goals, you argue semantics. With contracts, you have receipts.
Examples in Practice
- Startup Chaos: A founder says, "Our goal is to increase user signups by 50% this quarter." The growth engineer signs a contract: "Ship referral program v1 by March 15, with working invite links, unique codes, and tracking in analytics." The outcome (users sign up) may or may not happen, but the contract (build the system) either does or doesn't. No ambiguity.
- Enterprise Bureaucracy: A CIO announces the "goal" of modernizing infrastructure. Translation: months of steering committees, endless slide decks, and no ownership. A real contract would be: "Decommission the on-prem DB2 cluster by October 31 and migrate 100% of workloads to AWS Aurora." Now the work is specific, measurable, and enforceable — no hiding behind vague intentions.
Contrast: Goals vs. Contracts
- OKR Theater: "Objective: Deliver world-class reliability. Key Result: Maintain 99.99% uptime." Sounds impressive. Totally useless. Who owns it? How is it delivered? When? By what means?
- Contract Reality: "Site Reliability Engineering will implement multi-region failover for core APIs by December 1. Success = documented failover test demonstrating under 2 minutes recovery time." That's real. That's enforceable.
Takeaway: If you want execution, stop treating goals like gospel and start treating commitments like contracts. Goals let people hide behind intention. Contracts strip away the excuses and force outcomes.
Contracts are where clarity meets accountability. Everything else is wishful thinking.