Cadence is a feature, not a meeting

Most operations don't break from bad decisions. They break from decisions that arrive three days late. Here is how to engineer the timing.

When people say cadence, they usually mean the calendar: the Monday standup, the Thursday review, the monthly business review. But the cadence that actually matters is not how often you meet. It is how fast a decision can travel from the moment the data changes to the moment someone acts on it. Most teams have quietly tied that second clock to the first, and it costs them more than any single bad call ever will.

Here is a version I watched at a mid-size marketplace ops team. A delivery zone runs short on supply. The dashboard shows it Monday morning, clear as day. But the call to move incentives into that zone waits for the Thursday supply review, because that is when supply gets discussed. By Thursday the gap is three days old, and three days of a thin zone is three days of orders that quietly route somewhere else. Put a number on it: about 40 orders a day in that zone go unfilled, at roughly $25 of contribution each, so about $1,000 a day. A three-day lag is $3,000 per incident, and two incidents in a week is not unusual. Call it $6,000 a week, north of $300,000 a year. None of that was a bad decision. The decision was correct. It was just three days late.

Here is the method I use to fix it. Four steps, in order.

1. List the recurring decisions, not the recurring meetings. Most weekly meetings exist to make two or three real decisions. Write those decisions down. Everything else on the agenda is status, and status does not need a room.

2. Give each decision a trigger, not a timeslot. A decision should fire when a condition is met (a zone drops below X, a refund rate crosses Y), not when Thursday arrives. The calendar is a bad trigger because the world does not schedule its problems around your standup.

3. Set a latency budget per decision. Ask one question: how stale can this decision be before it stops mattering. Some can wait a week. The expensive ones cannot wait a day. The budget tells you which decisions to wire first.

4. Wire the trigger to the data, not to a person's memory. This is the integration glue. The signal crosses the threshold, the owner gets the decision in front of them within the hour, with the context already attached. Nobody has to remember to check.

The before and after is the whole argument. Before: the signal surfaces Monday, the decision lands Thursday, and the average lag across a week of signals sits near three days. After: the threshold trips, the owner gets pinged the same morning with the zone, the size of the gap, and the recommended move, and the decision lands in hours. The lag drops from three days to under one. On that same two-incident week you recover roughly two of the three lost days per incident, about $4,000 of the $6,000. Run the math across a year (40 orders x $25 x 2 days recovered x 2 incidents x 50 weeks) and it is about $200,000 that was leaking purely on timing.

And the meeting? Keep it. The Thursday review still happens. It just stops being the place decisions wait. It becomes the place you review the exceptions the triggers flagged and the judgment calls no rule should make on its own. The meeting gets shorter and sharper, because it is finally doing the one thing a room of people is actually good at.

Now the part that matters beyond this one team. This is the same wall every AI project hits. Standing up an alert is the easy 30%: any dashboard can email you when a number moves. The other 70% is the unglamorous part, which decisions deserve a trigger, what the latency budget is, who owns the exception, and how the signal reaches the person with the context to act. Skip it and you get more alerts, not faster decisions, which is how teams end up with 200 notifications and the exact same three-day lag.

Cadence is not how often you meet. It is how fast a decision moves once the data changes, and that is something you build into the stack, not something you put on a calendar.