Steve Blank joined me on the Acquisition Talk podcast to discuss the urgency of defense innovation in a world of authoritarian peer competitors. Steve is a serial entrepreneur, a founder of Hacking 4 Defense, a member of the Defense Business Board, a former Air Force officer, and a leader of the lean methodology movement. The conversation takes us to number of important areas, including:
- Why the Chinese couldn’t have done more damage to national defense than the Pentagon’s own requirements
- How agile programs like ABMS and Kessel Run are educating leadership
- Whether defense accelerators are stuck doing “innovation theater”
- How no startup could afford to deal with the DoD without a fanatical billionaire
- How most people who think they’re visionaries are actually hallucinating
When Steve talks to defense staffers, they think “lean” refers to reducing headcount — and therefore less budgets, jobs, and influence. He explains how that is exactly wrong. Lean is a completely different way of doing business that can be contrasted with the 20th century model defined by waterfall. The difference between lean processes and waterfall is demarcated to some degree by a generational gap. The junior grades seem to get it. The question is whether the leadership can get on-board before we reach a crisis point. Steve points to Chris Brose’s new book as a wake up call that the United States might not win the next major war without a new way of approaching acquisition.
While there are some hopeful signs that defense leaders are beginning to understand 21st century commercial business practices, he cautions how tacking small changes on a much larger system will not make progress. The entirety of defense acquisition process needs to be revamped, including the industrial base. Existing prime contractors are essentially sheet-metal benders, Steve argues, and software-native firms would be able to out-compete them in hardware if given a fair chance. But many in the commercial sector think the $1 million SBIR grants given to startups where everyone’s a winner without a transition oath into billion-dollar programs is deterimental. The goal isn’t to show up on the field, Steve says, but to win the game.
Podcast annotations
This waterfall engineering versus agile, I think for people in the commercial world, no one builds fixed features spec’ed up front not understanding that the problem’s going to change, you don’t truly understand the problem until you get out of the building iteratively and interactively. Something as simple as you know, gee, what do you mean we didn’t build minimally viable products of those elevators for the Ford-class carrier?
This is an area Steve is taking the lead in creating a new generation of engineers who take lean methodology seriously through Hacking 4 Defense. I listened in on Stanford’s H4D Lesson’s Learned presentation on June 12, 2020 and was struck by the sophistication of the student projects. Not only did they create fascinating solutions, such as in lightweight batteries, computer vision, and automated scheduling, they actually went out and did literally 100+ interviews with operators and leaders to better understand the problem. This led to reformulations of the original problem statements, iterative learning through a dozen MVPs, and improved outcomes. Incredibly impressive.
If students across the country can perform at this level of sophistication, so can the Department of Defense more broadly. But the requirements process enshrined in policy necessitates something of a crystal ball as to what technologies and environments will prevail over the course of decades:
If we’re doing something that’s big and complex that’s new, we might want to think about how do we build a process that’s agile — that allows us to build things incrementally and iteratively and at every step testing our assumptions… with the users and the customers and warfighters and everybody a piece at a time. And that’s called agile. There’s known ways to do this for hardware, software, complex systems, etc., that basically reduces the amount of money and time spent to get the product delivered correct.
The biggest examples, and they’re so beaten up I’m sorry to pick on them, but the Ford-class carriers and the F-35s. You would think those are requirements and acquisition programs that were run by the Chinese because nothing could have set our country back so much as spending the time, money and resources. Eventually of course they’re going to be great systems.
Steve goes on to talk about how even for the most complex systems we can break the problem down. Of course, even with the waterfall process the DoD has followed, it turns out there are many dozens of versions of the F-35. Each of them require slightly different production and maintenance procedures. With hindsight, it is obvious the DoD could have afforded the time and cost to build competing prototypes from a family of iteratively evolving subsystems. The bigger question, as Steve points out, is whether newer versions of 20th century platforms are really what is needed:
My point is, it’s not just shiny object tech, it’s that the whole class of systems we need to build are radically different than the things we built in the 20th century. And more importantly, and for me this is the big one, it’s not just an acquisition problem. These new systems will create a whole new set of operational concepts. We won’t use robotics on the battlefield the same way we were using men and people. We won’t use drone swarms exactly like we were using aircraft.
And so the iteration is not only important because it helps us achieve desired technological end-states faster. Iteration allows us to interact with the operators to experimentally test out new ways of fighting. The best technology can’t just be rammed down the throats of the user, because it might not reach product-mission fit.
I’d like to mention that the DoD is moving in this direction, and Steve sees it as well and is very hopeful. One area where the DoD is starting to rapidly update complex systems on par with how Tesla is pushing updates to its cars is how kubernetes was successfully deployed onto an F-16, allowing containerized software to be written and updated to the jet continuously. And if it could be done on a decades-old F-16, then it can be done of any number of platforms, meaning that the same code can be deployed and work exactly the same on different systems through a continuous integration/continuous delivery pipeline.
As Steve explains, moving to this kind of continuous delivery model is not in the business interest of the current prime contractors:
If you do waterfall and you’re a prime contractor, you want to make sure you have fixed requirements and fixed systems because every change is a new major contract. Being able to upgrade a system with a touch of a button like your Tesla can or some of our other systems is an anathema to a prime whose business model is predicated on low-cost bidding for the initial system and then make the money on the upgrades. That business model doesn’t allow you to build agile and upgradeable systems because you’ll go broke, or more importantly you’ll lose the deal.
That part about losing the deal is important. Northrop used to be known as the closest airframer in the US to the former European version of lean design/manufacturing (e.g., Dassault). However, when Northrop built the F-20 Tigershark to be effective, low-cost, and extremely maintainable, the DoD didn’t want anything to do with it. Primes simply cannot afford to lose major winner-take-all deals by “doing the right thing.” They have to play the waterfall game the DoD puts in front of them.
Thanks, Steve Blank!
I could go on for a long time annotating this podcast because there’s tons more to learn from Steve throughout the episode, but I’ll stop there. Make sure you listen to the whole thing! I’d like to thank Steve Blank for joining me on the Acquisition Talk podcast. Be sure to sign up for Steve’s newsletter and blog. He’s put out an enormous amount of important material, not just on defense but for commercial startups. One thing you can’t miss out on is his “Secret History of Silicon Valley,” truly excellent. Learn more about Hacking 4 Defense here and Stanford’s Lean LaunchPad here, read his books on business and innovation, listen to his recurring podcast, watch his numerous videos,
Great stuff, as usual Eric.
Mucho gracias, Chad!