How to Build an Operating Cadence That Scales
Most cadences are built by asking how often to meet. A cadence that survives the company changing size is built from decision rights instead, and the calendar comes after.
A cadence that scales is built from decision rights, not meeting frequency.
Most companies design a cadence by asking how often the leadership team should meet. That question produces a frequency: weekly, monthly, quarterly. It does not produce a cadence that survives the company changing size, because frequency was never the variable that mattered.
The variable that matters is which decisions get their final word in which forum. We have written before about what a cadence is actually scheduling — the resolution at which a company can notice a problem and act on it. Noticing the problem is only half the design. A cadence scales when it survives the company doubling in size without a full redesign, and it survives doubling only if it was built around decision rights rather than around a slot on the calendar.
Frequency is downstream, not upstream
Get the sequence backwards and every reorganisation becomes a calendar exercise: a new meeting, a new owner, the same confusion about who actually holds the last word. Get it the right way round and the calendar becomes almost incidental — a scheduling detail applied after the harder decision has already been made.
The calendar is the easy part. The hard part is saying, in writing, which forum loses the argument.
Start with a decision inventory, not a calendar.
The build begins with a list, not a template. Every decision the company makes on repeat — pricing exceptions, hiring above a level, roadmap tradeoffs, discount approval — gets a line: what it is, who currently decides it, and how long the last three instances took to resolve once the evidence arrived.
This inventory is uncomfortable in a specific way. It surfaces decisions with no clear owner, decisions with two owners who each believe they hold the final word, and decisions that get made in whichever room the most senior person happens to be standing in. None of that is visible from an org chart or a meeting list. It is only visible from the decisions themselves.
- Pricing exceptions above a stated discount threshold.
- Hiring above a given level or compensation band.
- Which features enter the roadmap for the next release.
- Whether to renegotiate a contract that misses target margin.
A useful inventory rarely stops at four lines. It tends to surface the same decision showing up twice under different names — a discount exception and a margin waiver turn out to be the same call, made by two different people who have never compared notes — and that duplication is itself a finding worth keeping.
The inventory is the design document
The inventory, not an org chart, is what a scalable cadence gets designed from — it shows how many genuinely distinct decision types the company runs, which is almost always fewer than the number of standing meetings. A company with four real decision types and eleven recurring forums is not badly organised. It is running a cadence inherited from a smaller company's fear of missing something.
Each forum gets one loop and one class of decision, not the other way round.
Once the inventory exists, group the decisions by how long it takes to learn whether the last one was right: same-week signals, quarter-length signals, year-length signals. Assign each group exactly one forum, and give that forum explicit final say over its group — not advisory input, not an escalation path, final say. What each of those three tiers is actually built to carry is a narrower question than it looks, and most rebuilds get it only half right.
This is where most rebuilds default back to old habits. It feels safer to let the fast forum also weigh in on the slow decisions, just to keep everyone aligned, and to let the slow forum occasionally overrule the fast one when a number looks alarming. Every one of those crossings reopens a decision that was supposed to be closed, at the exact moment proximity to whoever is in the room supersedes the design that was meant to replace it.
One forum, one jurisdiction
The design holds only if a decision type has exactly one forum with final say over it, ever. A company climbing from $10M to $100M runs this test constantly, because a founder's continued presence keeps offering an informal second forum for everything — that specific failure is its own piece. The underlying rule is general: a cadence that lets two forums claim the same decision has not built one cadence. It has built two, and it will pay for both.
Build the reopening clause in before the redesign, not after.
A cadence built for a fixed size is finished the day the company changes size. The scaling requirement is a mechanism that says, on a schedule and without anyone having to raise a hand, that a decision's jurisdiction is due for a recheck.
This is not a full review of the whole cadence — that is the audit companies avoid because it takes a strategy day nobody wants to spend. It is a smaller, cheaper habit: whenever the company crosses a threshold that changes who has context — a headcount doubling, a new layer of management, an office opened in a second country — the decision inventory gets rerun, not redesigned from scratch. A useful trigger list is short enough to keep on one page and specific enough that nobody has to interpret it in the moment a threshold is crossed.
Dated, not permanent
Attach a review date to the reopening clause itself. An undated handover drifts back to its old owner within a quarter, quietly, the same way a decision that was supposed to have moved drifts back to the founder's room once nobody can point to when it moved. A cadence that scales is not a better fixed design. It is a design with a stated mechanism for becoming a different design later.
Where building this becomes the work itself.
The build described here — a decision inventory, loop grouping, one forum per decision type, a dated reopening clause — is mechanical enough to run without outside help, and most leadership teams could complete the inventory in an afternoon if they made the time for it. That is precisely the constraint that stops them: the team doing the redesign is the same team whose calendar is already full.
This is what we run in consulting engagements that start from a cadence problem: build the inventory, assign the loops, write the jurisdiction list, set the review dates, and hand the discipline back to the team that owns it. That is the company-level build; the same mismatch shows up one level down, inside a single team coordinating on no agreed rhythm at all — why a team needs a cadence of its own. It sits inside the wider argument under operating cadence — that a company's real operating model is whatever its calendar has been built, on purpose or by accident, to notice.