Deloads Are Tech-Debt Sprints

Week three of a good training block feels brilliant. The muscle-up that was a grind is suddenly smooth, the handstand holds are creeping up, and every session you feel like adding one more set. Week four is meant to be a deload: half the volume, lighter progressions, mobility and an easy run. It feels like a waste. You’re strong right now, so why stop?

Because the thing that’s improving fastest isn’t the thing that breaks.

Tendons lag muscles

Muscle adapts in days. Tendons and other connective tissue adapt over weeks. If strength runs ahead of the tissue that has to transmit it, you get a fun few weeks and then a niggle that becomes a tendon injury that becomes two months off. I’ve followed that arc more than once: plateau → frustration → overtraining → injury. The deload exists to stop the fast system from writing cheques the slow system can’t cash.

Code moves faster than the organisation

Software teams have the same mismatch. Features are the muscle: visible, satisfying and quick to grow. The connective tissue is everything that has to carry them — the build pipeline, the test suite, dependency versions, docs, on-call knowledge, the mental model each person holds of the system. It adapts slowly, and nobody claps when it does.

Push features for long enough without letting that tissue catch up and you see the team equivalent of a tendon flare:

• lead time creeps up even though everyone is “busy”;
• change failure rate rises and hotfixes become normal;
• one person becomes the only one who understands a module;
• upgrades get postponed until they’re a migration project of their own;
• people are tired in a way a weekend doesn’t fix.

Those are the signals a coach looks for too: stalled progress, sloppy form, aches that don’t settle. I’d watch the first two through DORA Metrics and the rest through conversations.

A deload is planned, not earned

The key word in a good programme is scheduled. You don’t deload when you’re injured; that’s rehab. You deload every fourth or fifth week whether you feel you need it or not, because by the time you feel it you’re late.

So the engineering version isn’t “we’ll tidy up when things calm down”. Things never calm down. It’s a short, recurring, protected block:

• Cadence: roughly one week every four to six sprints, on the calendar before the quarter starts.
• Scope: dependency upgrades, flaky tests, dead feature flags, slow CI steps, docs that lie, the alert everyone mutes.
• Lower intensity, not zero: a deload isn’t a holiday. You still train, just lighter. The team still ships, just nothing that adds load.
• Max test afterwards: finish a deload with a benchmark. In the gym that’s a max hold or rep test; for a team it’s checking whether lead time, build time or incident load actually moved. If nothing changed, the deload was the wrong shape.

Where the metaphor breaks

Muscles recover by default during a deload; code doesn’t. Tech debt only shrinks if someone deliberately pays it down, so an engineering deload needs a short, prioritised list — otherwise it becomes a week of everyone doing whatever they fancy.

It also breaks on visibility. Nobody asks why you’re lifting lighter this week. A product manager will absolutely ask why nothing shipped. That’s why I frame it in delivery terms (“this week buys us faster lead time next month”) rather than hygiene terms (“the code is messy”).

Takeaways

• Treat recovery as part of the programme, not a reward for finishing it.
• Watch the slow-adapting system (pipelines, knowledge, people), not just the fast one (features).
• Book the deload before you need it, keep it lighter rather than empty, and measure afterwards.
• End a block early if progress stalls; pushing through a plateau is how the injury happens.

Related: Progressive Overload and Incremental Migration is the other half of the same programme — small increases, then consolidation. Hypertrophy and Skill Phases: Build vs Harden Cycles zooms out from the week to the quarter.