Small structural changes beat adding more: lessons from Shaolin training

Jesse Enkamp spent 24 hours training with the Headmaster of Shaolin Temple Europe and while it's about kung fu, the underlying principles map directly to building products.

The master demonstrated something that applies far beyond martial arts: small structural adjustments often deliver more stability than adding raw power. And invisible internal mechanics matter more than what observers see from the outside.

The horse stance test

The master had the practitioner stand in a horse stance - a basic position common across martial arts. In the typical karate version, the practitioner lost balance easily when pushed. Then the master made three small adjustments: tuck the tailbone, round the spine slightly, relax the shoulders. Same stance, but now the force redirected straight down into the ground. Significantly harder to move.

The master's point: you can train for twenty years and build strong legs, but without proper structure, you won't develop rooting. Strength without structure just means working harder to achieve less stability.

Teams add features when the real problem is architecture. A poorly structured codebase doesn't get more stable by adding more code. A confusing user flow doesn't get clearer by adding more options. The answer is often adjusting what's already there.

Circular motion versus straight lines

Chinese martial arts favour circular movements over straight-line techniques. Straight movements have a beginning and an end - you invest energy, execute, stop, then invest energy again. Circular movements maintain momentum. Each motion feeds into the next without stopping points.

Development cycles work the same way. Stop-start sprints where you plan, build, stop, then plan again create friction at every transition. Teams that maintain momentum, where discovery feeds directly into building, and shipping feeds directly into the next discovery - move faster with less effort. Eliminate the dead stops where energy dissipates.

Conditioning isn't about eliminating pain

Shaolin training includes body hardening - repeatedly striking surfaces to condition limbs. The practitioner's arms were inflamed after hundreds of repetitions. The master applied an ancient ointment, then reframed the purpose: it's not about eliminating pain, it's about changing your relationship to discomfort and knowing when to push through versus when to heal.

Building products means getting comfortable with specific types of discomfort. Shipping incomplete features feels wrong when you're used to polishing. Deleting code you spent weeks writing feels wasteful. Ignoring feature requests from loud users feels risky.

The skill isn't eliminating discomfort. It's distinguishing between productive discomfort (shipping fast, saying no, simplifying) and destructive discomfort (burnout, compounding technical debt, ignoring real user problems).

The closed door student problem

The master observed that from a distance, two people might stand in identical positions, but one is stable and the other isn't. The difference is internal - invisible to observers. This is why certain knowledge was historically reserved for "closed door students" who trained closely enough to learn the structural details that don't show up in the visible form.

Two teams might use identical tools, follow similar processes, and ship comparable features. But one team's work holds up under pressure while the other's doesn't. The difference is invisible from the outside: how they structure decisions, how they communicate trade-offs, when they choose to refactor versus ship.

You can copy the visible form - the tools, the process, the rituals, but without understanding the internal adjustments that make those forms effective, you're mimicking motions without the mechanics.

Three things that transfer

Structure beats strength. Small adjustments to how you're already working often deliver more than adding capacity, features, or process.

Maintain momentum rather than optimising individual phases. Eliminate the stopping points where energy dissipates between activities.

The most important mechanics are invisible from the outside. Two teams might ship similar features using similar tools, but one codebase becomes easier to change over time while the other calcifies. One team's decisions stick while the other's get revisited endlessly. The difference isn't visible in standups or roadmaps.

The practitioner left understanding that what looked like power was usually something simpler: knowing where to tuck, where to relax, and where to redirect force instead of resisting it. Same applies to building. The teams that look effortlessly stable aren't necessarily more talented. They've just learned which small adjustments compound and which efforts are wasted fighting physics.