Gumption Does Not Compile

A note on the physics of software delivery and who gets blamed for the weather.

“Americans in 1950 rediscovered something that since Hiroshima they had forgotten: you may fly over a land forever; you may bomb it, atomize it, pulverize it and wipe it clean of life—but if you desire to defend it, protect it, and keep it for civilization, you must do this on the ground, the way the Roman legions did, by putting your young men into the mud.”

— T.R. Fehrenbach, This Kind of War: The Classic Military History of the Korean War

I know. War analogies in the boardroom are cliche. Information Technology is not warfare, and I want to be clear that I am not pretending otherwise.

But something has been weighing on me more and more as budgets get tighter and resources get scarcer. I keep reaching for this Fehrenbach quote, one I first encountered as a cadet in a course on Korea, Vietnam, and the Military Experience, because it captures something I have been struggling to name cleanly. Something I have started just calling physics.

There is a physics to software delivery. And no amount of optimism, authority, or calendar manipulation changes it.

The Room and the Work

Here is a scene I know well. A conference room, or more likely a video call. Several customers. The usual IT work aligners. Maybe a developer or engineer in the room, maybe not. Maybe a manager with enough firsthand knowledge to translate, maybe not. There are timelines discussed. Commitments made. Slides advanced.

And then the meeting ends.

After all the squeezing and cajoling, after all the alignment and the nodding, there is still work that needs doing. Real work. Work with dependencies and constraints and accumulated decisions that stretch back years. Work that exists entirely outside the conference room and entirely outside the slide deck.

Someone has to go do it.

That gap between the announcement and the work is where I keep feeling the weight of Fehrenbach’s words. You can fly over the territory forever. You can bomb it with roadmaps, pulverize it with planning frameworks, wipe the whiteboard clean and draw a new picture. But if you want working software running in production, serving real users, someone has to sit down at a keyboard.

Which brings me to my own version of the quote:

“You may plan it, announce it, and celebrate it from the boardroom — but if you want working software in production, someone has to put their hands on a keyboard. Vision is not a deployment pipeline.”

The Physics Nobody Wants to Discuss

Fehrenbach’s point about Korea wasn’t just tactical. It was about a fundamental misreading of what air power could accomplish. A belief that enough force projected from a safe distance could substitute for the harder, slower, more costly work of ground presence. The technology was real. The capability was real. The mistake was believing it could replace something it could not.

And here is the part worth sitting with: airpower was genuinely transformative. It changed warfare permanently. Nobody serious disputes that. The mistake wasn’t believing in airpower. The mistake was believing it repealed the physics of ground combat.

I see the same pattern in IT leadership regularly. The technology is real. The vision is often genuinely good. The mistake is believing that a confident announcement can compress a critical path. That enthusiasm can substitute for headcount. That a new deadline can negotiate with technical debt.

Right now, AI is playing the role of airpower in this analogy. And I want to be careful here, because I work in this space and I believe in what AI can do. It is genuinely transformative. It is changing how software gets built, how teams operate, how organizations think about productivity. I am not dismissing it.

But I am watching something happen in boardrooms that concerns me. AI has given a new generation of ambitious announcements a fresh layer of justification. We can move faster now. The team can do more with less. AI will handle it. The timelines that were already optimistic have gotten more optimistic. The headcount that was already lean has gotten leaner. And somewhere in the gap between the announcement and the work, the physics is still sitting there, unchanged, waiting.

AI does not eliminate complexity. It does not pay down technical debt. It does not replace the judgment of an experienced engineer who understands why a system behaves the way it does. It is a powerful tool in the hands of capable people. It is not a substitute for those people.

It cannot. Complexity has mass. Dependencies are not suggestions. A system that took three years to get into its current state will not be modernized in a fiscal quarter because the budget cycle demands it, AI or otherwise.

This is not pessimism. This is physics.

Who Gets Blamed for the Weather

Here is the part that weighs on me most.

When the gap between the announcement and the reality becomes undeniable, there is usually a search for an explanation. And the explanation rarely lands on the people who set the timeline. It lands on the engineers and the technical teams. The people who were never in the room when the promise was made, or who were in the room but not listened to, or who raised the concern and were told to find a way.

They get blamed for the weather.

They were handed an impossible forecast and asked to perform accordingly. When the storm arrived on schedule, because it was always going to arrive on schedule, their failure to prevent it becomes the story.

I have watched talented people absorb this repeatedly. I have watched teams lose confidence not because they failed at the work, but because they were set up to fail at the optics. There is a meaningful difference between those two things, and it matters enormously for retention, culture, and the long-term health of any technical organization.

What I’m Not Saying

I am not saying executives should not set ambitious goals. I am not saying that urgency is wrong or that engineering teams are beyond accountability. Tension between aspiration and execution is healthy and often necessary.

What I am saying is that there is a cost to consistently divorcing the announcement from the reality of what delivery requires. That cost is borne by the people doing the work. And at some point, those people leave. Or worse, they stay and stop caring.

The legions still have to go into the mud. The engineers still have to put their hands on the keyboards. No roadmap, no reorg, no reframe changes that.

Acknowledge the physics. Protect the people doing the work. And when things don’t go as announced, be honest about where the accountability actually lives.