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 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).
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.
“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.
In the unit I am taking command of, we value an environment of continual improvement, agile delivery, and rapid innovation and risk-taking. These are the philosophies and behaviors that will enable us to win, and that will enable our customers to win in competition and conflict against our adversaries. Each of these philosophies and behaviors requires a diversity of thought.
Diversity of thought breaks through group-think. Diversity of thought raises issues early, and solves them more quickly.
I recently finished The Unicorn Project and found it compelling, as was The Phoenix Project. I wanted to document some of the lessons it teaches, because they’re something I hope to keep in mind while leading a software development unit. These lessons are “the three ways” and “the five ideals”.
The Three Ways
My thoughts here are expansions of some of the excerpts at IT Revolution.
Flow/Systems Thinking
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
Flow/Systems Thinking
Consider the performance of an entire system instead of just a part. One way to look at “the system” is the entire flow of work from product owner, through dev, test, and release into availability for employment. Another way to look at “the system” is as the literal system people are building.
Before a recent off-site the boss set the expectations for the event. This struck me as an extremely useful tool. I particularly liked the ROE - I think stating these early got everyone out of their normal mode of working and into the mode conducive to the event. It seems like developing ROE and purpose like this is good to consciously do for many types of event. It’s not unlike a normal meeting agenda.
You do know what you’re talking about - you are the expert on some things, specifically, the things you’ve experienced. Remember that you know what you’re talking about there. But be careful to not generalize that and override your team because most of the time…
You don’t know what you’re talking about - listen to your experts when they’re describing their situation. They are the experts in their situation, that is why they work with you. Most of the time as a manager their situation is the relevant one. Most of the time they know what they’re talking about.