We rarely make opportunity cost explicit in the military. Because we never think about opportunity cost, risk aversion seems safe.
Opportunity cost - the lost potential gain from an alternative, when a different one is chosen.
Common sources:
Failure to delegate authority
Bureaucratic processes
Delay
Failure to innovate
Recently the Acquisition Transformation Strategy has instructed the military to deliver capabilities to operators earlier - to take on more acquisition risk, in order to buy down operational risk. It is not immediately clear how to judge acquisition risk vs operational risk. Opportunity cost is one way they may be compared. When senior leaders ask us to take acquisition risk to lower operational risk, opportunity cost is the missing yardstick.
I find it fascinating to see how quickly, and in how many directions, practical AI ideas are multiplying right now. I installed OpenClaw recently and set up some daily prompts - show me interesting information, mine some RSS feeds I like - it has helped me learn new things each day… But I did not expect the breadth of different agent orchestration and LLM architectures it would present to me regularly.
I just finished listening to Safi Bahcall’s Loonshots (thank you Libby) because friends kept telling me it was fantastic, and was fundamental to how they think about the innovation we’re all striving towards. They weren’t kidding. The book gave me language for dynamics I’d been managing by intuition, especially during my time with the Shadow Warriors, and showed me how they might maintain success indefinitely.
Bush–Vail Rules and the Artist/Soldier Divide
The Bush–Vail rules hit hard (https://www.infermuse.com/how-to-nurture-loonshots/). They basically say: safeguard your artists (loonshot teams), empower your soldiers (scale teams), and don’t mash them into one bureaucracy. That maps almost perfectly onto how I saw the Shadow Warriors vs. the acquisition command I was embedded in. The Shadow Warriors are artists building weird prototypes, and the acquisition folks are concentrated on keeping the lights on by getting the basics out into the field. I’d sensed mixing those two groups too tightly was dangerous, but Bahcall gave me the structural argument I’d been missing. On the acquisition side I regularly campaigned for less oversight, but the book reminded me there’s a point where “less bureaucracy” can undercut quality (although we can cut a ton of bureaucracy before we reach that point, currently).
A recent Red Hat post about “specification-driven development” caught my interest. I’ve tried bolting AI onto my personal development practices. It doesn’t look like whispering an idea into an LLM then compiling the response… I can’t give the LLM my brain and have it replace all my work beyond the idea.
I have had success when providing a description of the end result, then working alongside an agent to refine and move towards that result iteratively. For me, personally, that’s a significantly different pattern for development than usual.
I remember finding Clapton at the animal shelter near the San Antonio zoo. He was pacing around his small area, it looked like he had a lot of energy. I was looking for a dog who would be, in part, a running buddy. I took a couple dogs out for a walk that first day, but out of all of them Clapton struck me as “the one”.
I came back the following two days and took different dogs for a walk, each time also taking Clapton. At one point there were children playing in one of the dog play areas, and I decided to see how he’d do around them. They wanted to play with him and he was interested in playing with them, it seemed like he liked kids well enough, although he was generally indifferent about people.
Working through a course on “International Security Studies”, I got absorbed in some reading about methods of analyzing international relations. I dove into a rabbit hole and am now able to put my own beliefs and worldview on this into concrete terms.
I’m annoyed by Google’s Analytics. It works great, but it’s heavy and overkill for my needs. Not to mention that it’s very privacy-intrusive. It’s not like I don’t give Google all my data already, but perhaps you don’t make that same choice, and you shouldn’t be forced into it simply by visiting my website.
I’ve been looking for a solution that lets me see what content folks are looking at and where they’re coming from, while being extremely cheap, and easy to maintain. All while reducing the privacy impact. I toyed with building something, but got lost in the “what is the cheapest way I can leverage AWS for this” trade-space.
“Disruption” is commonly thought of as a bad thing…
Disruption: disturbance or problems which interrupt an event, activity or process.
But to teams that yearn for change to their status-quo, like many in the 90th, disruptive innovation can be welcome.
Disruption: radical change to an existing industry or market due to technological innovation.
Disruptive innovation is something that many would not expect to exist inside the government, much less the Department of Defense. While we may occasionally drive innovative technological disruptions through investments, purchasing, or policy, it’s generally industry that is doing the innovative disruption.
This post documents some thoughts I have about accountability within my organization, and how I plan to speak to the team about accountability.
Accountability is vital in an organization. Within an organization members must be able to work together with trust. Trust often manifests as the belief that individuals will operate within a set of expectations. When behaviors deviate from those expectations, trust within a team is broken. When behavior deviates from expectations, accountability can bring team trust back into balance.
Almost everybody experienced the dreaded “team project” during high school. When the teacher picked the team members and you divvied up work you almost certainly had that one member, “Skip”, who did not pull their weight. Your team assigned them an entire section of writing, but the night before the project was due they didn’t turn anything in. They didn’t pick up their phone. They didn’t respond to email. You may have spent an all-nighter fixing the problem they caused just so your grade wouldn’t suffer.
I am fortunate enough to lead the 90th Cyberspace Operations Squadron, a unit that delivers software to enable cyberspace operations for combatant commands and the military services. Testing is a vital part of delivering software successfully, but there are many philosophies around how to do so. Our needs around testing are somewhat unique. This post describes how we need to shape our thinking for the future.
Today
Today we are in a fortunate position regarding test. We’ve got a history of delivering excellent capabilities that meet warfighter needs. We deliver them more quickly than anybody else, and our connections to operators mean they’re on target.