Hypertrophy and Skill Phases: Build vs Harden Cycles

For a long time my training had one setting: more. More sets of pull-ups, more handstand attempts, more skills on the list. Progress came in bursts and then stopped, and my joints started complaining. What fixed it was the most boring idea in programming: periodisation.

Two kinds of block

An intermediate calisthenics plan usually alternates mesocycles of five or six weeks:

• Hypertrophy (build) phase. More volume, more strength work, a couple of skill sessions to keep the pattern alive. You’re building raw capacity: muscle, work tolerance, the engine.
• Skill (harden) phase. Volume drops, intensity and practice frequency go up. Three skill sessions and one short strength session a week. You’re turning capacity into clean, repeatable technique.
• A deload between them, so the next block starts fresh.

The rule that made it click: you can’t push more skill and more hypertrophy at once. Skill work is neural and wants you fresh; high volume leaves you tired. Try to maximise both and you get mediocre volume and sloppy skill — and very grumpy elbows.

Platform teams try to max both, too

Platform roadmaps often look like a training plan written by an over-excited beginner. This quarter: three new capabilities, and improve reliability, and migrate everyone to the new pipeline, and write the docs. Every goal is reasonable. Together they compete for the same recovery budget: the team’s attention, review capacity and tolerance for change.

A build/harden cadence makes the trade-off explicit:

	Build block	Harden block
Goal	new capability, new users	reliability, adoption, depth
Typical work	new golden path, new self-service API, first agent integration	SLOs and alerting, migrations, docs, performance, removing the old path
Success looks like	first teams using it	most teams using it, fewer incidents, faster lead time
Risk if you skip it	the platform stagnates	the platform becomes a collection of half-adopted experiments

Communicating the cadence

The hardest part isn’t planning the blocks; it’s explaining them. What’s worked for me:

• Name the phase out loud. “This is a harden block” sets expectations better than a list of tickets.
• Keep a maintenance dose of the other. In a skill phase you still do one short strength session so you don’t lose it. In a harden block, keep a small slot for discovery so the next build block isn’t starting cold.
• Agree the exit criteria up front. A harden block ends when its targets are met (an SLO holding for a month, adoption above an agreed share), not when everyone’s bored of it.
• Put a deload between blocks. Short and planned.

Where the metaphor breaks

Bodies have fixed recovery limits; teams can, briefly, add people. But adding people mid-block is like adding a new exercise mid-mesocycle: it costs coordination before it pays back.

Also, a training block has one athlete with one goal. A platform serves many teams with competing priorities, so one team’s “harden” is another’s “you’re blocking my feature”. A visible calendar of blocks helps people plan around it rather than be surprised by it.

Takeaways

• Decide what this block is for: building capacity or turning it into reliable skill.
• Keep a maintenance dose of the other, and put a deload between blocks.
• Measure build blocks by first adopters and harden blocks by broad adoption and reliability.
• If everything is a priority, you’re running a beginner’s plan with an advanced athlete’s goals.

Related: Skill Trees as Platform Capability Maps for deciding which capabilities to build; You Can’t Serve Two Masters for why fewer goals per block works.