Endurance training solved a problem that management has not: it worked out that effort and progress are different things, and it built the measurement to match. A training plan doesn't count how far you ran. It counts what the running cost you, weighted by intensity, accumulated over weeks, tracked against how much your body has adapted to absorbing. That's load. Output is the distance. Load is the price.
Almost every management system I've worked inside measures the distance. Shipped features, closed deals, tasks completed, hours logged. All output, all of it silent on what the output cost, and therefore silent on whether the pace is sustainable for one more month or already past the point where something is going to break.
Principle one: measure load, not output
The reason training uses load is that two sessions producing identical distances can cost wildly different amounts, and the cost is what determines whether you improve or dig a hole. Same in a company. Two weeks that both ship one feature are not the same week if one of them ran on three people's evenings.
The practical version I use: for anything on the calendar, I try to name what it costs, not what it produces. A decision that requires me to hold three contexts at once costs more than four routine reviews, even though the routine reviews take more clock time. Once you start scoring by cost rather than duration, the calendar reorganizes itself. You stop treating an hour as an hour.
This is also where output metrics quietly lie. A team can raise output for a quarter by raising load, which looks like improvement and is actually borrowing. In training that's called overreaching, and it works until it very suddenly doesn't. I've watched the organizational version of that arrive on schedule, roughly one quarter after the graph looked best.
Principle two: one hard focus per block
A training block has a single primary stress. You build aerobic base, or you build strength, or you sharpen for a race. You do not do all three well at once, and the athletes who try get mediocre at all of them, because the adaptations compete for the same recovery budget.
Companies do the three-at-once thing constantly, and defend it with the observation that all three matter. They do matter. That isn't the question. The question is whether attempting them simultaneously produces three partial adaptations instead of one real one, and in my experience it reliably does.
So I run blocks. A period of weeks where one thing is the hard focus, and everything else is explicitly maintenance: kept alive, not advanced. Naming the maintenance work as maintenance is most of the value. It removes the guilt that comes from a project not moving, and it stops people from quietly starting a second hard block inside the first.
Principle three: deload before you're forced to
A deload week is a planned reduction in load while everything else stays in place. You don't stop training. You lower the cost so adaptation can catch up with the stimulus you already applied. Skip enough of them and your body schedules one for you, usually at the worst possible moment and usually for longer than the planned version would have taken.
I broke a femur in April and got a very literal education in the forced version of this. Not from overtraining, but the recovery taught the same lesson from the other end: the pace you can hold is set by what you can absorb, not by what you can produce on your best day.
In a company, the deload is the week with no new initiatives. Not a holiday. Everything runs, nothing new starts, and the capacity that would have gone into starting things goes into finishing and consolidating. Every time I've scheduled one it has felt indulgent going in and obvious coming out, and every time I've skipped one the organization has taken it anyway, in the form of a month where nothing lands because everyone is spread across six half-finished things.
Putting it on a calendar
Concretely, the transfer looks like this. A quarter is a training cycle with one primary adaptation, stated out loud, with everything else labelled maintenance. Inside it, weeks carry an intentional load rather than whatever accumulates. Every fourth-ish week is lighter by design, and lighter means fewer new commitments, not fewer hours.
Recovery gets scheduled at the same priority as work, because in training that's not a wellness gesture, it's where adaptation physically happens. The equivalent in a company is the time spent consolidating what you just learned into systems and documentation. Skip it and the effort produced no durable capability, only output. That's the same argument as the delegation one: the handoff that includes the reasoning compounds, the one that doesn't gets repeated. I wrote that up in The Delegation Ledger.
Where the analogy breaks
It isn't a clean transfer and I don't want to oversell it. A body has one recovery budget and a company has many, distributed across people who don't fatigue in sync. My deload week is somebody else's peak. Training also has a fixed race date that forces honest planning, and most business timelines are negotiable in a way that lets you defer the reckoning indefinitely.
And load in training is measurable to a genuinely useful precision. The organizational equivalent is an estimate at best, which means the whole framework runs on judgment rather than data. That's a real limitation, not a detail. What survives the translation is the underlying claim, and I think it survives well: you adapt during recovery, not during effort, and any system that measures only effort will keep telling you to do more right up to the point where it stops working.
How much of my own load I've been able to move off the calendar entirely is covered in An Executive's Week on an AI Agent Fleet.
More on this pillar: Compounding CEO.
Ready to Transform Your AI Strategy?
Get personalized guidance from someone who's led AI initiatives at Adidas, Sweetgreen, and 50+ Fortune 500 projects.
