LLMs and Generative AI in the enterprise.
Inspire, develop, and guide a winning organization.
Understand the unique values and behaviors of a successful organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how to enhance collaboration and performance in large-scale organizations through Flow Engineering
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Just as physical jerk throws our bodies off balance, technological jerk throws our mental models and established workflows into disarray when software changes too abruptly or without proper preparation.
Sure, vibe coding makes you code faster—that’s the obvious selling point. But if you think speed is the whole story, you’re missing out on the juicy stuff.
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
January 26, 2026
In 1944, the Office of Strategic Services—the precursor to the CIA—published a guide on how to quietly sabotage enemy organizations from within. The instructions were devastatingly simple: bog down processes with paperwork, send every decision through a committee, reward caution over action, and insist on strict adherence to procedure.
The manual’s tactics weren’t designed to destroy infrastructure. They weaponized process itself. Among the recommended methods:
Nearly eighty years later, the Department of Defense still faces foreign threats. But according to Jenn Spykerman’s eye-opening paper “Breaking the Sabotage Cycle” in the Fall 2025 Enterprise Technology Leadership Journal, some of the most persistent sabotage is self-inflicted. The tactics described in that CIA manual—delays by committee, rigid process, over-documentation—no longer require an enemy to deploy them. We’ve internalized the playbook.
Consider how closely modern software acquisition practices mirror those 1944 recommendations:
“Refer all matters to committees” has become governance structures that require multiple layers of approval for every technical decision.
“Insist on perfect documentation” manifests as financial processes that demand complete requirements before releasing any funding.
“Multiply paperwork in plausible ways” appears as testing and security reviews that generate volumes of compliance artifacts but delay working software.
“Apply all regulations to the last letter” shows up in oversight mechanisms that reward documentation completeness over operational utility.
“Advocate caution and urge reasonableness” translates to acquisition processes that discourage engagement with innovative commercial vendors.
The irony is profound. In the effort to build better software for warfighters, defense organizations have inadvertently created systems that undermine the very outcomes they seek. They’re not just failing to move fast—they’re actively institutionalizing delay.
When software acquisition moves at the speed of bureaucracy rather than the speed of relevance, real consequences follow. Capability gaps widen as threats evolve faster than responses. Warfighters make do with tools that slow them down rather than speed them up. Innovation partners choose to work elsewhere, taking their best ideas with them. Program managers burn out trying to deliver mission value through process-heavy systems.
The Department of Defense’s most costly software failures haven’t stemmed from bad intentions or poor engineering. They’ve come from following a sabotage playbook—unintentionally, but faithfully.
Take the $1.1 billion failure of the Expeditionary Combat Support System (ECSS). Conceived as a modern logistics solution for the Air Force, ECSS followed the traditional process playbook: formalize requirements through JCIDS (Joint Capability Integration and Development System), commit to a fixed plan, and structure progress around milestone reviews.
For seven years, teams tried to deliver against specifications that were outdated before the first line of code was written. Governance changed. Requirements multiplied. Users resisted a system they had no part in shaping. In the end, not a single operational capability was delivered.
The ECSS story isn’t an outlier. It’s the logical outcome of forcing software through a pipeline built for hardware—when documentation is prioritized over deployment, when paper success replaces user feedback, and when process rewards stability over speed.
The Software Acquisition Pathway (SWP) was created to break this pattern. Established through DoD Instruction 5000.87, the SWP provides an alternative acquisition framework specifically designed for software-intensive programs. Unlike traditional acquisition pathways that require lengthy documentation and rigid milestone reviews, the SWP emphasizes:
It doesn’t ask permission to work differently—it provides the authority to reverse the sabotage cycle and put mission outcomes back at the center.
The Navy Forge offers a compelling contrast to the ECSS failure. As a government-led software development team, Navy Forge builds and deploys mission-ready capabilities directly within government infrastructure. Their success comes from several key principles:
Leadership Continuity: Captain Brian Phillips and Mr. Ryan Moore retained longer-than-usual assignments, providing stability through transformation.
Selective Team Building: They hand-picked team members based on culture fit and passion, not just credentials.
Empowered Structure: They created a flatter, more inclusive organizational model with delegated authority.
Reduced Bureaucracy: They intentionally trimmed governance boards that stifled innovation.
“Hit Singles, Not Home Runs”: Rather than swinging for massive breakthroughs, they focused on small, tangible wins each sprint—user-visible functionality that sailors could see and use immediately.
As Captain Phillips put it: “We focused on small deliveries that were achievable and moved out on them.” Demonstrating value through delivery proved more effective than endless consensus-building. Or as the team often said: “We just did stuff.”
A similar transformation unfolded across the Potomac at the CIA. Former Assistant Director Sheetal Patel described the dysfunction her team inherited: “There was always a needs document every year for In-Q-Tel…but often [a specific problem statement] was just one person’s pet project. By the time the technology was identified, that person had moved on and nobody else had bought into the requirement.”
Her team’s response? They fundamentally changed how the agency prioritized technology requirements. They replaced stovepiped efforts with centralized vetting. Requirements had to pass through all five directorates, with actual sign-off to confirm real agency needs.
Just as importantly, Patel didn’t wait for perfect documentation before acting. She advocated for pilot projects—small, high-leverage experiments that could demonstrate value quickly. In a resource-constrained environment, “money can be found if it’s a game changer,” but only if people see the impact.
And to get that impact? You need users involved from the beginning. As Patel explained: “We went directly to the data owners, not the program managers.” The result wasn’t a spreadsheet—it was real pilots leveraging tools people trusted and delivering insights in language users could understand.
Traditional acquisition processes were designed for hardware programs with predictable timelines and fixed requirements—jet engines, tanks, satellites. Software operates differently. It evolves. It’s iterative, adaptive, and thrives on continuous feedback loops with real users.
The mismatch isn’t accidental—it’s structural. Hardware programs reward planning and precision. Software programs reward speed, learning, and responsiveness. When we apply hardware-era governance to software-era delivery, we don’t just create friction—we create failure.
JCIDS, introduced in 2003 after 9/11, was a rational attempt to bring jointness, traceability, and analytical rigor to the military’s fractured approach to requirements. But in trying to prevent another systemic failure, the Department inadvertently created a new one. What began as a system to prevent chaos evolved into bureaucracy that delays progress in the name of consensus.
Software can’t wait for perfect requirements. By the time you’ve documented everything, the mission has changed, the threat has evolved, and your specifications are obsolete.
Every recommendation from that 1944 sabotage manual has a Software Acquisition Pathway antidote:
The Software Acquisition Pathway isn’t just a new set of procedures. It’s a systematic reversal of self-sabotage. It’s a return to the military’s core principle: mission first.
You don’t need to be in defense or government to benefit from these insights. Every large organization faces the same tension between governance and speed, between risk management and innovation, between process and progress.
Ask yourself: Where are we following the sabotage playbook?
If any of these sound familiar, you’re not alone. But you do have a choice.
Traditional acquisition asks: “Did we follow the plan?” Modern software delivery asks: “Did we solve the problem?” That’s not just a process change—it’s a philosophical revolution that puts mission outcomes back at the center.
The good news? You don’t need to transform your entire organization overnight. The Navy Forge succeeded by “hitting singles”—small wins that built credibility and momentum.
Start with one problem. Solve it differently. Show it works. Scale from there.
Identify a pilot program where you can:
Document what works. Share the results. Let success speak louder than PowerPoint presentations.
Every organization faces the same decision: continue following the sabotage playbook inadvertently, or deliberately choose a different path. The choice isn’t between risk and safety—both approaches carry risk. The choice is between the risk of moving too slowly and the risk of moving thoughtfully fast.
In 1944, the CIA understood that the most effective way to weaken an enemy was to corrupt its processes from within. Nearly eighty years later, we’re doing it to ourselves.
The tools, frameworks, and authority exist to break the cycle. The success stories prove it’s possible. The mission demands it. And the stakes—whether measured in national security, competitive advantage, or organizational survival—are too high to keep following a sabotage manual.
It’s time to stop weaponizing process against ourselves. It’s time to remember that in a world increasingly defined by software, the speed of delivery determines the speed of response.
The warfighters we serve—and the customers we’re trying to reach—deserve better than systems designed to slow them down. They deserve software that accelerates their mission, amplifies their capabilities, and adapts as quickly as the threats they face.
Stop following the sabotage playbook. Start writing a different story.
This blog post is based on “Breaking the Sabotage Cycle: A Practical Guide to the Software Acquisition Pathway” by Jenn Spykerman, with contributions from Bryon Kroger, Ryan Moore, Sheetal Patel, Captain Brian Phillips, and Lieutenant Colonel Melissa Sayers, published in the Enterprise Technology Leadership Journal Fall 2025.
Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.
No comments found
Your email address will not be published.
First Name Last Name
Δ
In 1944, the Office of Strategic Services—the precursor to the CIA—published a guide on…
A version of this article originally appeared at Hyperadaptive.Solutions. Why AI initiatives fail and…
Studies show 20-55% productivity gains from AI code generation. Organizations are mandating AI adoption.…
The headlines scream about GenAI transforming everything. Tech leaders promise revolutionary productivity gains. Vendors…
