Rocks for Innovation: The Ninety-Day Experiment Contract

The bottom of the Vision/Traction Organizer is deliberately unglamorous: rocks — three to seven priorities per person per quarter — and the weekly meeting that checks them. I covered the funding half of this machinery in the one-year plan post: quarterly tranches, evidence at the gate, kills rewarded. What that post deferred is the craft question, and it’s where most adaptations quietly fail: how do you write a rock when the work is an experiment? A rock like “launch the pilot” is delivery-shaped — it can be completed while learning nothing. A quarter later you’ve hit 100% of your rocks and know nothing you didn’t know in January, which is the innovation-theater version of on-time delivery.

The fix is to treat the rock as a different kind of promise. An operational rock is a contract about output: done or not done. An innovation rock is a contract about evidence: at the end of ninety days, a named question will have a defensible answer, whichever answer it is. “Launch the pilot” becomes “we will know whether mid-market ops teams will connect their real payroll data to an unproven tool — with at least eight design-partner decisions as the evidence.” The second version can succeed by discovering a no. That asymmetry — the experiment rock is completed by the answer, not by the artifact — is the single edit that makes EOS’s execution layer safe for exploratory work.

Why the specification works: goals, grades, and Parkinson

The rock format looks folksy, but each of its constraints sits on top of real findings.

Specific beats vague — the most-replicated result in the goal literature. Locke and Latham’s program, summarized in their 2002 American Psychologist paper drawing on roughly four hundred studies, found that specific, difficult goals reliably outperform “do your best” instructions. A rock is a specific-difficult goal with a name attached; an innovation-theme like “make progress on AI” is a do-your-best instruction wearing a strategy costume. (Honesty note: nothing in that literature blesses ninety days specifically — the cycle length is a design choice, not a finding.)

The real argument for ninety days is Parkinson’s: “work expands so as to fill the time available for its completion” — the opening line of C. Northcote Parkinson’s essay in The Economist, 19 November 1955, and still the best one-sentence account of why annual innovation goals produce eleven months of setup and one month of panic. A quarter is long enough for a real experiment cycle — the sprint-scale and project-scale loops from the lab post fit inside it several times — and short enough that the deadline does the compressing Parkinson says deadlines do.

And the completion target should not be 100%. Wickman suggests healthy teams complete on the order of 80% of their rocks — and Google’s OKR practice, per the re:Work guidance and Doerr’s Measure What Matters, aims for average grades around 0.6–0.7, treating consistent 1.0s as evidence of sandbagging. Both systems converged on the same insight from opposite directions: a portfolio of commitments that always completes was never ambitious, and for experiment rocks this is doubly true — a quarter in which every hypothesis survived is a quarter in which nothing risky was tested. Track the completion rate; worry at both ends of it.

The weekly pulse: on-track, off-track, and nothing else

The rock’s enforcement mechanism is EOS’s Level 10 meeting — a weekly ninety minutes with a fixed, first-party-documented agenda: five minutes each of segue, scorecard, rock review, headlines, and to-dos, then a full hour of issue-solving, five minutes to conclude. The detail that matters most for innovation teams is the smallest: in the rock review, each owner says “on track” or “off track” — and nothing else. No narration, no context, no fifteen-slide update. Anything off-track drops to the issues list, to be solved in the hour reserved for solving (next post’s subject), not reported on in a status ritual.

Innovation teams need this discipline more than operational ones, because exploratory work is uniquely susceptible to status theater — the beautifully narrated update in which activity substitutes for evidence and nobody can quite tell whether the quarter’s question is closer to an answer. The binary check makes theater impossible: an experiment rock is on track if the evidence will exist by the gate, off track if it won’t, and the meeting’s structure physically separates reporting state from fixing it. Pair the rock review with the innovation scorecard from the one-year post — experiments concluded, assumptions retired — and the weekly meeting becomes what it’s supposed to be: the place where drift gets caught in seven days instead of ninety. The same mechanism, at a different altitude, is what quarterly planning does for the portfolio.

Writing an experiment rock: the four-line contract

The format I hold teams to — four lines, written at the quarterly session, graded at the next one:

The question, stated so a stranger can tell what’s genuinely unknown (“will mid-market ops teams connect real payroll data to an unproven tool?”). The evidence standard — what will count as an answer, decided before the quarter, because evidence standards negotiated after the data arrives always drift toward whatever the data shows (“eight design-partner decisions; five or more yes = validated”). The kill condition — the result that ends the line of inquiry, pre-committed, so the kill is an option expiring rather than a fight (“fewer than three willing even to trial: stop, write the memo”). The owner — one name, per EOS’s rule, because a rock owned by a team is owned by nobody.

Those four lines are the whole V/TO in miniature, which is why the organizer saves rocks for last: the question traces up through the one-year plan to the three-year picture; the evidence standard is innovation accounting at its smallest scale; the kill condition is the patience-with-falsifiability discipline from the ten-year target, scaled down to a quarter. One section of the organizer remains — the unglamorous list where everything that’s off-track, unresolved, or unsaid is supposed to go: the issues list, which for an innovation system turns out to be the most important page of all.