Rampart's Build-Fight Cycle: The Ancient Fix for Modern Burnout

One-line summary

A 2023 tech CEO rediscovered a 1990s arcade game called Rampart to solve his team's burnout: the game mechanically enforces strict alternation between repair phases and execution phases—something modern work tools have erased.

A 2023 tech CEO rediscovered a 1990s arcade game called Rampart to solve his team's burnout: the game mechanically enforces strict alternation between repair phases and execution phases—something modern work tools have erased. Modern culture celebrates simultaneous multitasking as resilience, but burnout stems specifically from the brain's inability to perform defensive repair and offensive creation simultaneously. By artificially recreating Rampart's forced boundary—whether through company-wide rules or personal rituals—knowledge workers can restore sustainable performance through sequential phase-switching.

In 2023, the CEO of a tech company called Zeta Interactive sent a memo to his engineering staff. It was titled “The Rampart Rule: Build and Fight Phases.” From 10 a.m. to 2 p.m. each day, the memo declared, no one was allowed to fix bugs, refactor code, or apply quick patches. Those hours were for building new things only. Repair work had to wait. This wasn’t a productivity hack from a management guru. The CEO, Mark Pincus, got the idea from a 1990 arcade game called Rampart. In it, you defend a castle. The game forces a strict alternation: first a “build phase” where you repair your walls, then a “fight phase” where you fire cannons at invading ships. The software of the game literally will not let you do both at once. Pincus realized his team was trying to do both at once, all day, every day. They were constantly patching leaks while also being asked to steer the ship. The result wasn’t agility; it was cognitive gridlock. This touches a deeper truth. The modern mantra of continuous integration and agile response suggests we should always be repairing and executing simultaneously. We celebrate the engineer who squashes a bug while in a planning meeting, or the marketer who redesigns a campaign asset between customer calls. We call this resilience. But the feeling of burnout isn’t just about having too much to do; it’s the specific failure of trying to perform two mutually exclusive cognitive modes at the same time. One mode is defensive, analytical, and repair-oriented—fixing, optimizing, shoring up. The other is offensive, focused, and execution-oriented—creating, advancing, engaging. They use different parts of the brain and require different kinds of attention. Doing both at once means doing neither well. History understood this forced choice. A medieval garrison under attack could not simultaneously rebuild a breached section of wall and repulse scaling ladders on the opposite side. They had to sequence their efforts: defend fiercely, then use a lull to repair. The architecture of the castle and the reality of physics enforced the boundary. Our digital tools have erased it. Slack, Jira, and always-on connectivity make it possible—even expected—to be in perpetual reactive repair while also trying to produce original work. We’ve lost the ritualized “build phase.” The takeaway isn’t a vague plea for balance. It’s that sustainable performance requires artificially recreating the boundary the game and the castle took for granted. You can legislate the build phase back. It might look like a team-wide rule, like Zeta’s “combat hours.” Or it could be a personal ritual: a ninety-minute block every morning where you close all communication channels and only work on repair, refactoring, and system care—no new execution allowed. The key is the forced alternation, the acknowledgment that these are separate, sequential tasks. You are not failing to multitask; you are obeying a deeper rule of how focused work actually gets done. The game, the castle, and now the memo all point to the same principle: you must choose your phase. Build, then fight. Never both.

Rampart's Build-Fight Cycle: The Ancient Fix for Modern Burnout · Soulstrix