the Tech OODA Loop

I've been to a number of meetings with senior policy makers, all understand the concept of the OODA Loop (observe-orient-decide-act). And the need to get inside your adversaries OODA loop: i.e., if you make decisions faster than they are you win. (also good if you can accelerate)

But things break down when then the DoD acquisitions process gets the CONOP.

Simply, right now our tech OODA loop is woefully out of date through process, law and legislation.

Military acquisitions processes are based on assumptions of an industrial era, i.e. we want to optimize the building of a tank/ship to save money on construction in both labor and material. What does optimization of design mean for software?

Front loading optimization early in the life-cycle of a military capability makes sense for hardware, but for software??? Software is about failure - until it works.

Software is optimized while it is being built, but mainly occurs at the end of 'construction' once you know it works.

Why does this matter? Software is what runs the military and not being able to rapidly incorporate new ideas into the collective of military systems leaves the US at a disadvantage when our enemies grab and install versus how we do it: need/req's/allocate funds/design/construct/test/reconstruct/test deploy/throw away/blame contractors/start over.

The interplay of assumptions between industrial versus digital systems is something that must be fixed if the US military is to keep our edge (and not break the bank).

in the industrial age of war the quote was:
- amateurs talk tactics, professional talk logistics

in the digital age:
- amateurs talk technologies, professionals talk acquisition's

We need to adapt the OODA loop concept to the acquisitions cycle