The Inherited Load

For eighteen years, teams tried to win the Kremer Prize for human-powered flight. They built elegant aircraft, tested cautiously — one or two flights a year — and failed. Then Paul MacCready's team deleted a requirement nobody had questioned: the aircraft must not break.

They built the Gossamer Condor from Mylar and aluminum tubes. It broke constantly. They repaired it in hours and flew again. Four hundred test flights in one year. Twelve major redesigns. Teams who'd spent years protecting their aircraft had completed maybe a dozen flights total.

The Gossamer Condor didn't win by being better-engineered. It won by carrying less.

---

The Addition Reflex

When a project stalls, the instinct is to add. More engineers. Better tools. Longer hours. Another review process. Occasionally someone suggests simplifying, and everyone nods — then adds a simplification initiative to the roadmap.

Zack Anderson's framework from hardware engineering — where delays cost millions and physics doesn't negotiate — makes the alternative concrete: six methods for moving fast in the physical world, and every one of them is a subtraction.

Delete requirements before optimizing. Design experiments that answer one question, not miniatures that prove everything. Insource uncertainty, outsource what's already solved. Replace mechanical complexity with software. Compress physical distance. Keep teams small enough to share context by default.

The shared principle: reduce the mass of the learning loop. Not by pushing harder. By carrying less.

---

The Constraints You Didn't Choose

Most constraints arrive as inheritance, not decision.

Anderson's team at ClearMotion discovered this when they studied actual driving data across hundreds of vehicles. The peak force requirements their entire industry designed around — textbook scenarios representing extreme conditions — turned out to demand roughly five times what real-world driving actually requires. Every competitor was engineering for a scenario that almost never occurs.

That single subtraction opened an entirely new design space. Simpler architecture, lower cost, faster response, better real-world performance. Not by engineering harder within the constraint — by questioning whether the constraint was real.

SpaceX made the same move with avionics. Space-grade radiation-hardened components cost 100 to 1,000 times more than commercial equivalents. The conventional wisdom treated this as physics: space is harsh, components must be hardened. SpaceX treated it as an assumption. They designed system-level resilience through triple-redundant voting with commercial parts. The requirement they deleted wasn't "survive radiation." It was "survive radiation at the component level."

The constraint you inherited looks like physics. Most of the time, it's precedent. Someone solved a problem one way, that solution became the standard, and every subsequent team designed around it without asking whether it still applies.

---

The Mass of the Loop

Delete a requirement and the learning loop gets lighter. But requirements aren't the only mass.

Prototypes carry mass when they try to prove everything at once. Boom Supersonic's XB-1 demonstrator was one-third scale and answered exactly three questions: supersonic inlet efficiency, carbon-fiber thermal performance, and digital stability augmentation. Each risk retired in sequence before scaling to the full-size aircraft. NASA's X-planes operated the same way for decades — X-1 through X-15 were never production aircraft. They were hypotheses with wings.

Distance carries mass. Toyota made engineers stand in chalk circles watching factory floors for hours. Not punishment — bandwidth. An engineer absorbing vibration, timing, and waste patterns in person captures information no written report transfers. ClearMotion put build labs behind glass walls adjacent to engineering desks and moved machine shops in-house, collapsing two-week external fabrication cycles to same-day turnaround.

People carry mass. Lockheed's Skunk Works built the SR-71, U-2, and F-117 with 10 to 25 percent of normal program headcount. ClearMotion noticed productivity visibly dropped beyond thirty people — more silos, slower context-sharing, physical separation breaking the spontaneous problem-solving that small teams take for granted.

Each of these looks like a different optimization. But they're the same move: find the mass in your learning loop and remove it. The constraint might be a requirement, a prototype scope, a geographic distance, or an org chart. The principle doesn't change.

---

Reading the System

The most instructive methods in Anderson's framework aren't the subtractions. They're the repositionings.

When an experienced supplier called a sensing challenge "physically impossible," ClearMotion solved it in a month — through computation, not hardware. Google DeepMind cut data center cooling energy by 40 percent without new equipment — optimizing 120 variables through neural networks. When Tesla needed to protect Model S batteries from road debris, they didn't recall vehicles for physical skid plates. They pushed an over-the-air update that raised ride height at highway speeds. Software solved a geometry problem at zero marginal cost.

The Sidewinder missile team at China Lake kept fabrication, testing, and design tightly co-located under their own control. Engineers sketched ideas in the morning, machined parts that afternoon, tested immediately. In that environment — where shop technicians had standing to influence design — a technician named Sidney Crockett suggested rollerons: passive gyroscopic stabilization through spinning metal wheels on tail fins. An elegant solution that could only emerge where the boundary between thinking and building had been deliberately erased.

These methods aren't subtracting mass. They're positioning work where reality cooperates instead of resists. Shift complexity into software where iteration costs approach zero. Keep unknowns close where learning speed matters most. Let proven processes run where they're already efficient. This is alignment over force. Don't command the wave. Read it, position yourself, and let physics do the carrying.

---

The Seeing Problem

The hardest part of this framework isn't the deletion. It's the seeing.

None of these subtractions were obvious. Every one required sustained attention to how the system actually works — not how everyone assumes it works. That's why "move fast" advice usually defaults to addition. Addition is visible. Hiring is visible. Process is visible. A new tool is visible. Subtraction requires understanding the system deeply enough to know what's load-bearing and what's inherited — and that understanding comes only from the kind of patient attention that looks, from the outside, like doing nothing.

The fastest teams aren't the ones that push hardest. They're the ones that see which constraints are real.

The next time something feels slow, resist the addition reflex. Don't ask how to go faster. Ask what you're carrying that you didn't choose.

---