"Collaborate by Contract" (CBC) is my framework; it's new, and I'm publishing it piece by piece. It's not an "industry standard" yet, but it's more than theory: it's how I've learned to get execution discipline in teams where vague goals and shifting priorities are the default. It doesn't need to be practiced by the entire org; as with any other type of agreement, you just need two willing participants.

At the simplest level:

A CBC agreement is a short written contract between leaders and reports. Ideally, person to person, but leader and team is fine too. It defines the objective, deliverables, dependencies, expectations, and outcomes (i.e., success criteria). Work doesn't start until all parties agree.

A journal of contracts is just the running log of those agreements. Think of it as the team/dept/org's public ledger, what was agreed, by whom, when, and why, and ideally the artifact captures the negotiations and tradeoffs made to arrive at the final agreement. Patterns show up quickly (who delivers, who misses, where scope creep hides). This makes performance reviews objective and enables meritocracy.

Okay, things change, and sometimes new info emerges: agreements aren't stone tablets. So, agreements might include predefined checkpoints or "if/then" clauses. Instead of pretending we never change, CBC forces us to renegotiate in daylight, with both sides explicit about the cost of changing.

What leaders commit to: clarity, timely decisions, and removing dependencies. If a leader misses their side, say they don't secure the promised resource or they blow their own deadline, that's a contract miss just like an IC failing to deliver code. Also, by signing the agreement, the leader is sayin,g "I agree with this plan/strategy." In CBC, credibility runs both ways.

It's early, and I'm still publishing examples and tooling. But the premise is simple: if you can't write it down, negotiate it, and sign it, it's not really a commitment, it's just vibes.

Also, no, it's not Waterfall, because it's more about documenting "expectations" and "outcomes" than about specifying particular work activities.

cc quag

Thank you for the description of CBC.

I'm curious about it and your thinking on how to track things over time and see what has surprised us since we got started. It is useful to note down every time you (or your team) sets an expectation with someone (or another team) and then make sure you don't forget about that. It's also useful to be deliberate when setting expectations.

Having a public journal could well work for noting down when expectations are set and whenever there is a meeting of minds. I've found when tracking things like this that the amount of data can quickly grow to the point where you can no longer quickly and easily reason about it. The success seems to live and die on the data visualization or UI/UX.