There's a moment every revenue org has learned to love. The quarter is short. Someone stays late, calls in a favour, rewrites the deck at midnight, and the number lands. The room applauds. The save becomes a story, and the story becomes the culture.
The comforting lie. The lie is that execution is a character trait — that some teams simply have more of it. It's comforting because it requires no redesign. If execution is a virtue, the fix is exhortation: try harder, care more, own it. You can deliver that fix in a Monday meeting and feel like you've acted.
But virtue doesn't survive turnover, scale, or a bad month. Systems do. A team that hits its number because one person is exceptional has not built anything. It has rented an outcome.
Why heroics feel like progress. Heroics are legible. They have a protagonist, a deadline, and a visible result. Systems are the opposite: they are boring, distributed, and their success looks like nothing happening. Nobody gets promoted for the crisis that didn't occur.
So orgs over-reward the save and under-invest in the cause. Over a few quarters this compounds into a specific failure mode: high effort, high variance, no forecastability. The team is busy and the outcome is a coin flip.
The save is not the success. The save is the evidence of a gap.
The test that tells you which one you have. Three questions. Answer them about last quarter, honestly, before you read on.
- 01If the person who saved the quarter had been on leave, would the number still have landed?
- 02Can you name the step in the process where the risk first became visible — and who owned it?
- 03If you ran the same quarter again, would you get the same result, or a different one?
Three yeses is a system. Any no is a virtue — and virtue is not a plan. The second question is the sharpest of the three: if the risk was only visible in hindsight, you don't have an execution problem, you have an instrumentation problem.
Build for repetition, not heroics. A system is four unglamorous things: a named owner, a defined trigger, a written standard, and a review that actually changes the standard. Miss any one and you're back to effort.
Owner means a person, not a function. Trigger means the work starts on a signal, not on a memory. Standard means the second time is faster than the first because someone wrote down what good looked like. Review means the standard is a living document, not a wiki page nobody has opened since onboarding.
Done well, this reads as a downgrade in ambition. It isn't. Repetition is what lets you increase ambition safely, because you know what the machine produces before you ask it for more.
What to actually do this week. Take the single save your team is proudest of from the last ninety days. Write one page: what the trigger should have been, who should have owned it, and what standard would have made the save unnecessary. Then put the trigger in the calendar and the standard in the doc.
One page. One trigger. One owner. That's the whole intervention. Do it four times and the variance in your quarter starts to fall — not because anyone tried harder, but because less of the outcome depends on trying.
See you next issue.