Running the Cadence

You have the task. It is small, scoped, and verifiable, with a definition of done you can actually check. One of those is a nice afternoon. The accountability the business is asking for is not a nice afternoon. It is a steady drumbeat of shipped work, the kind that lets you tell a customer "yes, that lands next week" and be right. That drumbeat has a name in this book: reliable execution. This chapter is about how you run it.

The mechanism is a cadence. A cadence is just a repeating cycle with fixed shapes: what gets picked up, how it moves, who checks it, and what happens to the result. Once the shape is fixed, the work flows through it without anyone reinventing the process each week. That predictability is the whole point. The Standish CHAOS data found that small, scoped projects succeed 61% of the time against 6% for "grand" ones (Standish CHAOS 2015). A cadence is how you keep your work small on purpose, forever, instead of letting it swell back into a grand project by accident.

The board

Everything visible, in one place. The board is where the cadence lives, and it has four columns.

A founder can read this board in ten seconds without knowing a line of code. You see what is moving, what is stuck, and what landed. You are not running the work. You are watching it run, which is exactly the position you want to be in.

Prioritisation: the top of the backlog earns its place

The backlog is ordered, not piled. Ordering is the part founders should care about most, because it is where engineering meets the business, and it is the one decision a board makes for you every single week: the task at the top is the next thing that gets built.

So what climbs to the top? The work tied to a business goal you can name. Not "refactor the billing module" but "stop the failed-payment emails that are churning customers this month." Every task on the board should trace to an outcome a commercial person recognises. If it cannot, it is either disguised maintenance, which is fine but should be labelled honestly, or it is someone's pet idea, which is the seed of the feature nobody asked for. Pendo found that 80% of features are rarely or never used (Pendo 2019). A great deal of that waste is decided at the moment of prioritisation, by what you let climb the list.

Reordering is cheap, and that is the quiet advantage of running task-shaped work. You can change your mind every cycle. The market moves, a customer escalates, a competitor ships something, and the response is to drag a new task to the top of the backlog, not to renegotiate a thousand-page contract. The spec graveyard is full of plans that were correct on the day they were signed and wrong by the time anyone built them. A reordered backlog is a plan that gets to stay correct.

Here is a slice of one, with the trace written in:

You do not need to understand how a card retry works. You need to agree that cutting a $4,000-a-month leak beats tidying an admin screen this week. That judgement is yours, and the board is built so you can make it.

Review and acceptance: the gate that protects the drumbeat

In Review is the most important column on the board and the one most teams quietly skip. A task is not done because an engineer says it is done. It is done when it has been checked against the definition of done written when the task was scoped, the one with the acceptance check at the bottom. That check is the contract. It is why the work was specified in plain terms before anyone started, so that "done" is a fact you can verify rather than an opinion you have to trust.

Acceptance is also where the task-by-task approval gate sits. One task is reviewed and accepted, and only then does the next begin. That sounds slow. It is the opposite. It means a problem surfaces while it is one task wide, not after it has been built on top of for a month. The cost of catching a defect in review is small. The cost of catching it three tasks later, woven into everything since, is the rework that quietly eats a quarter.

A definition of done you check in review is the cheapest insurance you will ever buy. It costs one conversation now and saves a rebuild later.

A worked acceptance, kept to the same ticket format used throughout the book:

TASK #1 — Retry failed card charges automatically for 3 days

Definition of done:
  - A declined charge is retried once a day for 3 days, then marked failed
  - The customer is emailed on final failure, not on each retry
  - Successful retries appear in the payments log with a "retry" tag

Acceptance check (run in review):
  - Force a test card to decline → confirm 3 retries over 3 days, then "failed"
  - Confirm exactly one customer email, sent on final failure
  - Confirm the payments log shows the retry tag

Status: ACCEPTED — checks passed, shipped to production 06 June.

Notice what acceptance is not. It is not a code review, which is an engineering concern that happens earlier and inside the team. It is the business-readable confirmation that the thing you asked for is the thing that shipped. You can read every line of that acceptance check without writing software. That is by design, and it is the difference between advice by the hour and hands on keyboard you can verify.

The feedback loop: shipped work writes the next task

The dashed arrow on the board, the one looping back from Shipped to Backlog, is where reliable execution compounds. Every shipped task teaches you something. The card-retry feature goes live and you learn that most declines are expired cards, not insufficient funds, which means the highest-value next task is a "your card is about to expire" reminder rather than anything you had planned. The work tells you what to build next. The board is built to catch that signal and turn it into the next top-of-backlog task while it is still fresh.

This is what a thousand-page spec cannot do. A spec is a guess made at the moment of least knowledge, the very start, and then defended against everything you learn afterward. A cadence inverts it. You ship the smallest useful thing, watch what happens, and let the result reorder the backlog. Each loop you know more, and the next task is better aimed than the last. The plan improves as the product ships, instead of rotting while it waits.

The rhythm itself stays boring, and boring is the goal. A typical cycle runs a few days per task. Daily, the board updates so a stuck task is visible the day it sticks, not the week it slips. Each cycle, a task is accepted and shipped, the loop feeds the backlog, and the top of the list gets re-checked against the goals that matter now. Nobody is heroic. Nothing is dramatic. Things just ship, on a beat you can set your calendar by, which is the only kind of delivery a founder can actually plan a business around.

That is the engine. The next question is the one a non-technical founder always asks, and should: how do you trust it is running without standing over it every day?

Next: how you see the cadence working without managing it, and who, exactly, is on the hook for each task.