The Red Queen Problem – Innovation in the DoD and Intelligence Community

“…it takes all the running you can do to keep in the same place. ”
The Red Queen Alice in Wonderland

Innovation, disruption, accelerators, have all become urgent buzzwords in the Department of Defense and Intelligence community. They are a reaction to the “red queen problem” but aren’t actually solving the problem. Here’s why.


In the 20th century our nation faced a single adversary – the Soviet Union. During the Cold War the threat from the Soviets was quantifiable and often predictable. We could specify requirements, budget and acquire weapons based on a known foe. We could design warfighting tactics based on knowing the tactics of our opponent. Our defense department and intelligence community owned proprietary advanced tools and technology. We and our contractors had the best technology domain experts. We could design and manufacture the best systems. We used these tools to keep pace with the Soviet threats and eventually used silicon, semiconductors and stealth to create an offset strategy to leapfrog their military.

That approach doesn’t work anymore. In the 21st century you need a scorecard to keep track of the threats: Russia, China, North Korea, Iran, ISIS in Yemen/Libya/Philippines, Taliban, Al-Qaeda, hackers for hire, etc. Some are strategic peers, some are near peers in specific areas, some are threats as non-state disrupters operating with no rules.

In addition to the proliferation of threats, most of the tools and technologies that were uniquely held by the DoD/IC or only within the reach of large nation states are now commercially available (Cyber, GPS, semiconductors, analytics, centrifuges, drones, genetic engineering, agile and lean methodologies, ubiquitous Internet, crypto and smartphones, etc.). In most industries, manufacturing is no longer a core competence of the U.S.

U.S. agencies that historically owned technology superiority and fielded cutting-edge technologies now find that off-the-shelf solutions may be more advanced than the solutions they are working on, or that adversaries can rapidly create asymmetric responses using these readily available technologies.

The result is that our systems, organizations, headcount and budget – designed for 20th century weapons procurements and warfighting tactics on a predictable basis – can’t scale to meet all these simultaneous and unpredictable challenges. Today, our DoD and national security agencies are running as hard as they can just to stay in place, but our adversaries are continually innovating faster than our traditional systems can respond. They have gotten inside our OODA loop (Observe, Orient, Decide and Act).

We believe that continuous disruption can only be met with a commitment to continuous innovation.

Pete Newell and I have spent a lot of time bringing continuous innovation to government organizations. Newell ran the U.S. Army’s Rapid Equipping Force on the battlefields of Iraq and Afghanistan finding and deploying technology solutions against agile insurgents. He’s spent the last four years in Silicon Valley out of uniform continuing that work. I’ve spent the last six years teaching our country’s scientists how to rapidly turn scientific breakthroughs into deliverable products by creating the curriculum for the National Science Foundation Innovation Corps – now taught in 53 universities. Together Pete, Joe Felter and I created Hacking for Defense, a nationwide program to teach university students how use Lean methodologies to solve defense and national security problems.

The solution to continuous disruption requires new ways to think about, organize, and build and deploy national security people, organizations and solutions.

Here are our thoughts about how to confront the Red Queen trap and adapt a government agency to infuse continuous innovation in its culture and practices.

Problem 1: Regardless of a high-level understanding that business as usual can’t go on, all agencies are given “guidance and metrics (what they are supposed to do (their “mission”) and how they are supposed to measure success). To no one’s surprise the guidance is “business as usual but more of it.” And to fulfill that guidance agencies create structure (divisions, directorates, etc.) designed to execute repeatable processes and procedures to deliver solutions that meet the requirements of the overall guidance.

Inevitably, while all of our defense and national security agencies will tell you that innovation is one of their pillars, innovation actually is an ill-defined and amorphous aspirational goal, while the people, budget and organization continue to flow to execution of mission (as per guidance.)

There is no guidance or acknowledgement that in our national security agencies, even as we execute our current mission, our capabilities decline every year due to security breaches, technology timing out, tradecraft obsolescence, etc. And there is no explicit requirement for creation of new capabilities that give us the advantage.

Solution 1: Extend agency guidance to include the requirements to create a continuous innovation process that a) resupplies the continual attrition of capabilities and b) creates new capabilities that gives us a mission advantage. The result will be agency leadership creating new organizational structures that make innovation a continual process rather than an ad hoc series of heroic efforts.

Problem 2: The word “Innovation” actually describes three very different types of activities.

Solution 2: Use the McKinsey Three Horizons Model to differentiate among the three types. Horizon 1 ideas provide continuous innovation to a company’s existing mission model and core capabilities. Horizon 2 ideas extend a company’s existing mission model and core capabilities to new stakeholders, customers, or targets. Horizon 3 is the creation of new capabilities to take advantage of or respond to disruptive technologies/opportunities or to counter disruption.

We’d add a new category, Horizon 0, which kills ideas that are not viable or feasible (something that Silicon Valley is tremendously efficient at doing).

These Horizons also apply to government agencies and other large organizations. Agencies and commands need to support all three horizons.

Problem 3: Risk equals failure and failure is to be avoided as it indicates a lack of competence.

Solution 3: The three-horizon model allows everyone to understand that failure in a Horizon 1/existing mission activity is different than failure in a Horizon 3 “never been done before” activity. We want to take risks in Horizon 3. If we aren’t failing with some efforts, we aren’t trying hard enough. An innovation process embraces and understands the different types of failure and risk.

Problem 4: Innovators tend to create activities rather than deployable solutions that can be used on the battlefield or by the mission. Accelerators, hubs, cafes, open-sourcing, crowd-souring, maker spaces, Chief Innovation Officers, etc. are all great but they tend to create innovation theater – lots of motion but no action. Great demos are shown and there are lots of coffee cups and posters, but if you look at the deliverables for the mission over a period of years the result is disappointing. Most of the executors and operators have seen little or no value from any of these activities. While the activities individually may produce things of value, they aren’t valued within the communities they serve because they aren’t connected to a complete pipeline that harnesses that value and turns it into a deliverable on the battlefield where it matters.

Solution 4: What we have been missing is an innovation pipeline focused on deployment not demos.

The Lean Innovation process is a self-regulating, evidence-based innovation pipeline. It is a process that operates with speed and urgency, where innovators and stakeholders curate and prioritize their own problems/Challenges/ideas/technology. It is evidence based, data driven, accountable, disciplined, rapid and mission- and deployment-focused.

The process recognizes that Innovation isn’t a single activity (an incubator, a class, etc.) it is a process from start to deployment.
The canonical innovation pipeline:

As you see in the diagram, there are 6 steps to the innovation pipeline: sourcing, challenge/curation, prioritization, solution exploration and hypothesis testing, incubation and integration.

Innovation sourcing: a list of problems/challenges, ideas, and technologies that might be worth investing in. These can come from hackathons, research groups, needs from operators in the field, etc.

Challenge/Curation: innovators get out of their own offices and talk to colleagues and customers with the goal of finding other places in the DoD where a problem or challenge might exist in a slightly different form, to identify related internal projects already in existence, and to find commercially available solutions to problems. It also seeks to identify legal issues, security issues, and support issues.

This process also helps identify who the customers for possible solutions would be, who the internal stakeholders would be, and even what initial minimum viable products might look like.

This phase also includes building initial minimal viable products (MVPs.) Some ideas drop out when the team recognizes that they may be technically, financially, or legally unfeasible or they may discover that other groups have already built a similar product.

Prioritization: Once a list of innovation ideas has been refined by curation, it needs to be prioritized using the McKinsey Three Horizons Model.

Once projects have been classified, the team prioritizes them, starting by asking: is this project worth pursing for another few months full time? This prioritization is not done by a committee of executives but by the innovation teams themselves.

Solution exploration and hypotheses testing: The ideas that pass through the prioritization filter enter an incubation process like Hacking for Defense/I-Corps, the system adopted by all U.S. government federal research agencies to turn ideas into products.

This six- to ten-week process delivers evidence for defensible, data-based decisions. For each idea, the innovation team fills out a mission model canvas. Everything on that canvas is a hypothesis. This not only includes the obvious – is there solution/mission fit? — but the other “gotchas” that innovators always seem to forget. The framework has the team talking not just to potential customers but also with people responsible for legal, support, contracting, policy, and finance. It also requires that they think through compatibility, scalability and deployment long before this gets presented to engineering. There is now another major milestone for the team: to show compelling evidence that this project deserves to be a new mainstream capability. Alternatively, the team might decide that it should be spun into its own organization or that it should be killed.

Incubation: Once hypothesis testing is complete, many projects will still need a period of incubation as the teams championing the projects gather additional data about the application, further build the minimum viable product (MVP), and get used to working together. Incubation requires dedicated leadership oversight from the horizon 1 organization to insure the fledgling project does not die of malnutrition (a lack of access to resources) or become an orphan (continue to work with no parent to guide them).

Integration and refactoring: At this point, if the innovation is Horizon 1 or 2, its time to integrate it into the existing organization. (Horizon 3 innovations are more likely set up as their own entities or at least divisions.) Trying to integrate new, unbudgeted, and unscheduled innovation projects into an engineering organization that has line item budgets for people and resources results in chaos and frustration. In addition, innovation projects carry both technical and organizational debt. This creates an impedance mismatch between the organizations that can be easily be resolved with a small dedicated refactoring team. Innovation then becomes a continuous cycle rather than a bottleneck.

Problem 5: The question being asked across the Department of Defense and national security community is, “Can we innovate like startups in Silicon Valley” and insert speed, urgency and agility into our work?

Solution 5: The reality is that the DoD/IC is not Silicon Valley. In fact, it’s much more like a large company with existing customers, existing products and the organizations built to support and service them. And much like large companies they are being disrupted by forces outside their control.

But what’s unique is, that unlike a large company that doesn’t know how to move rapidly, on the battlefields of Iraq and Afghanistan our combatant commands and national security community were more agile, creative and Lean than any startup. They wrote the book on how to collaborate (read Team of Teams) or adopt new technologies (see the Rapid Equipping Force.) The problem isn’t that these agencies and commands don’t know how to be innovative. The problem is they don’t know how to be innovative in peacetime when innovation succumbs to the daily demands of execution. Part of the reason is that large agencies are run by leaders who tend to be excellent Horizon 1 managers of existing people, process and resources but have no experience in building and leading Horizon 3 organizations.

The solution is to understand that an innovation pipeline requires different people, processes, procedures, and metrics, then execution.

Problem 6: How to get started? How to get leadership behind continuous innovation?

Solution 6: To leadership, incubators, cafes, accelerators and hackathons appear to be just background noise unrelated to their guidance and mission. Part of the problem lies with the innovators themselves. Lots of innovation activities celebrate the creation of demos, funding, new makerspaces, etc. but there is little accountability for the actual rapid deployment of useful tools. Once we can convince and demonstrate to leadership that continuous innovation can solve the Red Queen problem, we’ll have their attention and support.

We know how to do this. Our country requires it.
Let’s get started.

Lessons Learned

  • Organizations must constantly adapt and evolve, to survive when pitted against ever-evolving opposition in an ever-changing environment
  • Government agencies need to both innovate and execute
  • In peacetime innovation succumbs to the demands of execution
  • We need explicit guidance for innovation to agencies and their leadership requiring an innovation organization and process, that operates in parallel with the execution of current mission
  • We need an innovation pipeline that delivers rapid results, not separate, disconnected innovation activities

Office of Naval Research (ONR) Goes Lean

The Office of Naval Research (ONR) has been one of the largest supporters of innovation in the U.S. Now they are starting to use the Lean Innovation process (see here and here) to turn ideas into solutions. The result will be defense innovation with speed and urgency.

—-

Here’s how the Office of Naval Research (ONR) was started. In World War II the U.S. set up the Office of Scientific Research and Development (OSRD) to use thousands of civilian scientists in universities to build advanced technology weapons (radar, rockets, sonar, electronic warfare, nuclear weapons.) After the war, the U.S. Navy adopted the OSRD model and set up the Office of Naval Research – ONR. Since 1946 ONR has funded basic and applied science, as well as advanced technology development, in universities across the U.S. (Stanford’s first grants for their microwave and electronic lab came from ONR in 1946.)

Rich Carlin heads up ONR’s Sea Warfare and Weapons Department. He’s responsible for science and programs for surface ships, submarines, and undersea weapons with an annual budget of over $300 million per year.

Rich realized that while the Department of Defense DoD spends a lot of money and has lots of requirements and acquisition processes, they don’t work well with a rapid innovation ecosystem. He wanted to build an innovation pipeline that would allow the Navy to:

  • Create “dual-use” products (build solutions that could be used for the military but also sold commercially, and attract venture capital investments.) “Dual-use” products reduce the cost for defense adoption of products.
  • Test if the Lean Innovation process actually accelerates technology adoption and an innovation ecosystem.
  • Use best practices in contracting that accelerate awards and provide flexibility and speed in technology maturation and adoption.

Today ONR has taken the Lean Innovation process, adapted it for their agency, and is running pilots for defense innovation teams.

Lean Innovation is a Process
The Lean Innovation process is a self-regulating, evidence-based innovation pipeline. It is a process that operates with speed and urgency. Innovators and stakeholders curate and prioritize their own problems/Challenges/ideas/technology.

The process recognizes that Innovation isn’t a single activity (an incubator, a class, etc.). It is a process from start to deployment.

The ONR pipeline has all the steps of the canonical innovation pipeline:

Innovation sourcing: a list of problems/challenges, ideas, and technologies that might be worth investing in.

Problem/Challenge Curation: innovators get out of their own offices and talk to colleagues and customers with the goal of finding other places in the DoD where a problem or challenge might exist in a slightly different form, identifying related internal projects already in existence, and finding commercially available solutions to problems. They also seek to identify legal issues, security issues, and support issues.

This process also helps identify who the customers for possible solutions would be, who the internal stakeholders would be, and even what initial minimum viable products (MVPs) might look like.

This phase also includes building initial MVPs. Some ideas drop out when the team recognizes that they may be technically, financially, or legally unfeasible or they may discover that other groups have already built a similar product.

Prioritization: Once a list of innovation ideas has been refined by curation, it needs to be prioritized using the McKinsey Three Horizons Model. Horizon 1 ideas provide continuous innovation to a company’s existing business model and core capabilities. Horizon 2 ideas extend a company’s existing business model and core capabilities to new customers, markets or targets. Horizon 3 is the creation of new capabilities to take advantage of or respond to disruptive opportunities or disruption. We added a new category, Horizon 0, which refers to graveyard ideas that are not viable or feasible.

Once projects have been classified, the team prioritizes them, starting by asking: is this project worth pursing for another few months full time? This prioritization is not done by a committee of executives but by the innovation teams themselves.

Solution exploration and hypotheses testing: The ideas that pass through the prioritization filter enter an incubation process like Hacking for Defense/I-Corps, the system adopted by all U.S. government federal research agencies to turn ideas into products.

This six- to ten-week process delivers evidence for defensible, data-based decisions. For each idea, the innovation team fills out a mission model canvas. Everything on that canvas is a hypothesis. This not only includes the obvious -is there solution/mission fit? — but the other “gotchas” that innovators always seem to forget. The framework has the team talking not just to potential customers but also with regulators, and people responsible for legal, contracting, policy, and finance support.  It also requires that they think through compatibility, scalability and deployment long before this gets presented to engineering. There is now another major milestone for the team: to show compelling evidence that this project deserves to be a new mainstream capability. Alternatively, the team might decide that it should be spun into its own organization or that it should be killed.

Incubation: Once hypothesis testing is complete, many projects will still need a period of incubation as the teams championing the projects gather additional data about the application, further build the MVP, and get used to working together. Incubation requires dedicated leadership oversight from the horizon 1 organization to insure the fledgling project does not die of malnutrition (a lack of access to resources) or become an orphan (no parent to guide them).

Lean Innovation Inside the Office of Naval Research (ONR)
To come up with their version of the innovation pipeline ONR mapped four unique elements.

First, ONR is using Hacking for Defense classes to curate “Problem Statements” (ONR calls them Challenge/Opportunity Statements) to find solution/mission fit and commercial success.

Second, they’re using existing defense funding to prove out these solutions depending on the level of technical maturity. (There are three existing sources for funding defense innovation: COTS/GOTS validation (testing whether off-the-shelf  products can be used); Concept Validation and Technology Advancement; and SBIR/STTR funds – there’s over >$1B per year in the DoD SBIR program alone.)

Third, they are going to use Pete Newell’s company, BMNT and other business accelerators to apply Lean Launchpad Methodologies to build the business case for resulting prototypes and products and to attract private investments.

Fourth, they are going to use grants, purchase orders and Other Transaction Agreements (OTAs) to attract startups and nontraditional defense contractors, speed the award process, and provide startups the flexibility to pivot their business model and prototype/product solution when necessary.

BMNT and Hacking for Defense serve as the essential crosslink for tying together the assets already available in DoD to implement the Lean Innovation process for defense innovation.

Lessons Learned

  • The Office of Naval Research has been funding innovation in universities for 70+ years
  • They are piloting the Lean Innovation Process to move defense innovation forward with speed and urgency

National Security Innovation just got a major boost in Washington

Two good things just happened in Washington – these days that should be enough of a headline.

First, someone ideal was just appointed to be Deputy Assistant Secretary of Defense.

Second, funding to teach our Hacking for Defense class across the country just was added to the National Defense Authorization Act.

Interestingly enough, both events are about how the best and brightest can serve their country – and are testament to the work of two dedicated men.

Soldier, Scholar, Entrepreneur
Joe Felter was just appointed Deputy Assistant Secretary of Defense for South and Southeast Asia. As a result, our country just became a bit safer and smarter. That’s because Joe brings a wealth of real-world experience and leadership to the role.

I got lucky to know and teach with Joe at Stanford. When we met, my first impression was that of a very smart and pragmatic academic. And I also noticed that there was always a cloud of talented grad students who wanted to follow him. (I learned later I was watching one of the qualities of a great leader.) Joe had appointments at Stanford’s Center for International Security and Cooperation (CISAC), where he was the co-director of the Empirical Studies of Conflict Project and at the Hoover Institute where he was a research fellow. I learned he’d gone to Harvard to get his MPA at the Kennedy School of Government in conflict resolution. But the thing that really caught my attention: his Stanford Ph.D thesis in Political Science had the world’s best title: “Taking Guns to a Knife Fight: A Case for Empirical Study of Counterinsurgency.” I wondered how this academic knew anything about counterinsurgency.

This was another reminder that when you reach a certain age, people you encounter may have lived multiple lives, had multiple careers, and had multiple acts. It took me a while to realize that Joe had one heck of a first act before coming to Stanford in 2011.

As I later discovered, Joe’s first act was 24 years in the Army Special Operations Forces (SOF), retiring as a Colonel.
His Special Forces time was with the 1st Special Forces Group as a team leader and later as a company commander. He did a tour with the 75th Ranger Regiment as a platoon leader. In 2005, he returned to West Point (where he earned his undergrad degree) and ran the Combating Terrorism Center. Putting theory into practice, he went to Iraq in 2008 as part of the 75th Ranger Regiment, in support of a Joint Special Operations Task Force. In 2010 Joe was in Afghanistan as the Commander of the Counterinsurgency Advisory and Assistance Team. At various points his Special Forces career took him to countries in Southeast Asia where counterinsurgency was not just academics.

Ironically, I was first introduced to Joe not at Stanford but through one of his other lives – that of an entrepreneur and businessman – at the company he founded, BMNT Partners. It was there that Joe and I along with another retired Army Colonel, Pete Newell, came up with the idea of creating the Hacking for Defense class. We combined the Lean Startup methodology – used by the National Science Foundation to commercialize science  – with the rapid problem sourcing and solution methodology Pete developed on the battlefields in Afghanistan and Iraq when he ran the US Army’s Rapid Equipping Force.

My interest was to get Stanford students engaged in national service and exposed to parts of the U.S. government where their traditional academic path and business career would never take them. (I have a strong belief that we’ve run a 44-year experiment with what happens when you disconnect the majority of Americans from any form of national service. And the result hasn’t been good for our country. Today if college students want to give back to their country, they think of Teach for America, the Peace Corps, or Americorps or perhaps the US Digital Service or the GSA’s 18F. Few consider opportunities to make the world safer with the Department of Defense, State Department, Intelligence Community or other government agencies.)

Joe, Pete and I would end up building a curriculum that would turn into a series of classes — first, Hacking for Defense, then Hacking for Diplomacy (with the State Department and Professor Jeremy Weinstein), Hacking for Energy, Hacking for Impact, etc.

Hacking For Defense
Our first Hacking for Defense class in 2016 blew past our expectations – and we had set a pretty high bar. (See the final class presentations here and here).

Our primary goal was to teach students entrepreneurship while they engaged in national public service.

Our second goal was to introduce our sponsors – the innovators inside the Department of Defense and Intelligence Community –  to a methodology that can help them understand and better respond to rapidly evolving asymmetric threats. We believed if we could get teams to rapidly discover the real problems in the field using Lean methods, and only then articulate the requirements to solve them, then defense acquisition programs could operate at speed and urgency and deliver timely and needed solutions.

Finally, we also wanted to show our sponsors in the Department of Defense that students can make meaningful contributions to understanding problems and rapid prototyping of solutions to real-world national security problems.

The Innovation Insurgency Spreads
Fast forward a year. Hacking for Defense is now offered at eight universities in addition to Stanford – Georgetown, University of PittsburghBoise StateUC San Diego, James Madison University, University of Southern Mississippi, and later this year University of Southern California and Columbia University. We established Hacking for Defense.org, a non-profit to train educators and provide a single point of contact for connecting the DOD/IC sponsor problems to these universities.

By the middle of this year Hacking For Defense started to feel like it had the same momentum as when my Lean LaunchPad class at Stanford got adopted by the National Science Foundation and became the Innovation Corps (I-Corps). I-Corps uses Lean Startup methods to teach scientists how to turn their discoveries into entrepreneurial, job-producing businesses. Over 1,000 teams of our nation’s best scientists have been through the program. It has changed how federally funded research is commercialized.

Recognizing that it’s a model for a government program that’s gotten the balance between public/private partnerships just right, last fall Congress passed the American Innovation and Competitiveness Act, making the National Science Foundation Innovation Corps a permanent part of the nation’s science ecosystem.

It dawned on Pete, Joe and me that perhaps we could get Congress to fund the national expansion of Hacking for Defense the same way. But serendipitously, the best person we were going to ask for help had already been thinking about this.

The Congressman From Science and Innovation
Before everyone else thought that teaching scientists how to build companies using Lean Methods might be a good for the country, there was one congressman who got it first.

In 2012, Rep. Dan Lipinski (D-Il), ranking member on the House Research and Technology Subcommittee, got on an airplane and flew to Stanford to see first-hand the class that would become I-Corps. For the first few years Lipinski was a lonely voice in Congress saying that we’ve found a better way to train our scientists to create companies and jobs. But over time, his colleagues became convinced that it was a non-partisan good idea. Rep. Lipinski was responsible for helping I-Corps proliferate through the federal government.

While Joe Felter and Pete Newell were thinking about approaching Congressman Lipinski about funding for Hacking for Defense Lipinski had already been planning to do so. As he recalled, “I was listening to your podcast as I was working in my backyard cutting, digging, chopping, etc. (yes, I do really work in my backyard,) when it dawned on me that funding Hacking for Defense as a national program – just like I did for the Innovation Corps – would be great for our nation’s defense when we are facing new unique threats. I tasked my staff to draft an amendment to the National Defense Authorization Act and I sponsored the amendment.”

(The successful outcome of I-Corps has given the Congressman credibility on entrepreneurship education among his peers. And it doesn’t hurt that he has a Ph.D and was a university professor before he ended up in Congress.)

Joe Felter and Pete Newell mobilized a network of Hacking for Defense supporters. Joe and Pete’s reputations preceded them on Capitol Hill, but in part a testament to the strength of Hacking for Defense, there’s now a large network of people who have experienced and believe in the program, and were willing to help out by writing letters of support, reaching out to other members of Congress to ask for support, and providing Congressman Lipinski’s office with information and background.

Congressman Lipinski led the amendment. He brought on co-sponsors from both sides of the aisle: Representatives Steve Knight (R-CA 25), Ro Khanna (D-CA 17), Anna Eshoo (D-CA 18), Seth Moulton (D-MA 6) and Carol Shea-Porter (D-NH 1).

On the floor of the House, Lipinski said, “Rapid, low-cost technological innovation is what makes Silicon Valley revolutionary, but the DOD hasn’t historically had the mechanisms in place to harness this American advantage. Hacking for Defense creates ways for talented scientists and engineers to work alongside veterans, military leaders, and business mentors to innovate solutions that make America safer.”

Last Friday the House unanimously approved an amendment to the National Defense Authorization Act authorizing the Hacking for Defense (H4D) program and enabling the Secretary of Defense to expend up to $15 million to support development of curriculum, best practices, and recruitment materials for the program.

This week the H4D amendment moves on to the Senate and Joe Felter moves on to the Pentagon. Both of those events have the potential to make our world a much safer place – today and tomorrow.

We Have A Moral Obligation

I was in Boston and was interviewed by The Growth Show about my current thinking about innovation in companies and government agencies.The interviewer was great and managed to get me to summarize several years of learning in one podcast.

It’s worth a listen.

At the end of the interview I got surprised by a great question – “What’s the Problem that Still Haunts You?”  I wasn’t really prepared for the question but gave the best answer I could on the fly.

Part of the answer is the title of this blog post.

Listen to the entire interview here:
Taking the Lean Startup From Silicon Valley to Corporations and the State and Defense Department

Or just parts of the interview:
1:20  Failure and Lessons Learned

Hacking for Defense @ Stanford 2017 – Lessons Learned Presentations

We just finished our second Hacking for Defense class at Stanford. Eight teams presented their Lessons Learned presentations.

Hacking for Defense is a battle-tested problem-solving methodology that runs at Silicon Valley speed. It combines the same Lean Startup Methodology used by the National Science Foundation to commercialize science, with the rapid problem sourcing and curation methodology developed on the battlefields in Afghanistan and Iraq by Colonel Pete Newell and the US Army’s Rapid Equipping Force.

Goals for the Hacking for Defense Class
Our primary goal was to teach students entrepreneurship while they engaged in a national public service. Today if college students want to give back to their country they think of Teach for America, the Peace Corps, or Americorps or perhaps the US Digital Service or the GSA’s 18F. Few consider opportunities to make the world safer with the Department of Defense, Intelligence Community or other government agencies.

Our second goal was to teach our sponsors (the innovators inside the Department of Defense (DOD) and Intelligence Community (IC)) that there is a methodology that can help them understand and better respond to rapidly evolving asymmetric threats. That if we could get teams to rapidly discover the real problems in the field using Lean methods, and only then articulate the requirements to solve them, could defense acquisition programs operate at speed and urgency and deliver timely and needed solutions.

Finally, we also wanted to show our sponsors in the Department of Defense and Intelligence community that civilian students can make a meaningful contribution to problem understanding and rapid prototyping of solutions to real-world problems.

The Class
Here’s a brief description of the Lean Methodology our students used:

If you can’t see the video click here

Our mantra to the students was that we wanted them to learn about “Deployment not Demos.” Our observation is that the DOD has more technology demos than they need, but often lack deep problem understanding.  Our goal was to have the students first deeply understand their sponsors problem – before they started building solutions. As you can imagine with a roomful of technologists this was tough. Further we wanted the students to understand all parts of the mission model canvas, not just the beneficiaries and the value proposition. We wanted them to learn what it takes to get their product/service deployed to the field, not give yet another demo to a general. This meant that the minimal viable products the students built were focused on maximizing their learning of what to build, not just building prototypes.

(Our sponsors did remind us, that at times getting a solution deployed meant that someone did have to see a demo!)

The Hacking for Defense class was designed as “fundamental research” to be shared broadly and the results are not subject to restriction for proprietary or national security reasons. In the 10 weeks the students have, Hacking for Defense hardware and software prototypes don’t advance beyond a Technology Readiness Level 4 and remain outside the scope of US export control regulations and restrictions on foreign national participation.

Results

  • Eight teams spoke to over 800 beneficiaries, requirements writers, program managers, warfighters, legal, security, customers, etc.
  • Seven out of the eight teams realized that the problem as given by the sponsor really wasn’t the problem. Their sponsors agreed.
  • Received from a problem sponsor mid-live stream broadcast “we are working funding for this team now.”
  • Over half the student teams have decided to continue working on national security projects after this class.

This is the End
Each of the eight teams presented a 2-minute video to provide context about their problem and then gave an 8-minute presentation of their Lessons Learned over the 10-weeks. Each of their slide presentation follow their customer discovery journey. All the teams used the Mission Model Canvas, Customer Development and Agile Engineering to build Minimal Viable Products, but all of their journeys were unique.

The teams presented in front of several hundred people in person and online.

21st Century Frogman

If you can’t see the video click here

 

The video of the team presenting is below.  You can see all their slides right below this video.

If you can’t see the video click here

 


If you can’t see the presentation slides click here

.

.

VA Companion

If you can’t see the video click here

 

The video of the team presenting is below.  You can see all their  slides right below this video

If you can’t see the video click here

 


If you can’t see the presentation slides click here

.

.

Austra Lumina

If you can’t see the video click here

 

The video of the team presenting is below.  You can see all their  slides right below this video

If you can’t see the video click here

 


If you can’t see the presentation slides  click here

.

.

Xplomo

If you can’t see the video click here

 

The video of the team presenting is below.  You can see all their slides right below this video

If you can’t see the video click here

 


If you can’t see the presentation slides click here

.

.

Seacurity

If you can’t see the video click here

The video of the team presenting is below.  You can see all their slides right below this video

If you can’t see the video slides click here

 

If you can’t see the presentation click here

.

.

Surgency

If you can’t see the video click here

The video of the team presenting is below.  You can see all their slides right below this video

If you can’t see the slides click here

 

 


If you can’t see the presentation slides click here

.

.

Broadcom

If you can’t see the video click here

 

The video of the team presenting is below.  You can see all their slides right below this video

If you can’t see the slides click here

 


If you can’t see the presentation slides click here

The Innovation Insurgency Spreads
Hacking for Defense is now offered at eight universities in addition to Stanford – Georgetown,  University of Pittsburgh, Boise State, UC San Diego, James Madison University, University of Southern Mississippi, and later this year University of Southern California and Columbia University. We established Hacking for Defense.org a non-profit, to train educators and to provide a single point of contact for connecting the DOD/IC sponsor problems to these universities.

The Department of Defense has expanded their use of Hacking for Defense to include a classified version, and corporate partners are expanding their efforts to support the course and to create their own internal Hacking for Defense courses.

Another surprise was how applicable the “Hacking for X…” methodology is for other problems. Working with the State Department we offered a Hacking for Diplomacy class at Stanford.

Both the Defense and Diplomacy classes created lots of interest from organizations that have realized that this “Hacking for X…” problem-solving methodology is equally applicable to solving public safety, energy, policy, community and social issues internationally and within our own communities. This fall a series of new “Hacking for X…” classes will address these deserving communities. These include:

If you’re interested in learning how to apply a “Hacking for X…” class in your workplace or school we’ve partnered with the 1776 incubator in Washington DC to offer a 2-day “Hacking for X…” certification course 26-27 July for those interested in learning how. Sign up here.

It Takes a Village
While I authored this blog post, these classes are a team project. The teaching team consisted of:

  • Joe Felter a retired Army Special Forces Colonel with research and teaching appointments at Stanford’s Center for International Security and Cooperation (CISAC), the Hoover Institution, and the dept. of Management Science and Engineering. Joe is the incoming Deputy Assistant Secretary of Defense for South and Southeast Asia.
  • Pete Newell is a retired Army Colonel currently a Senior Visiting Research Fellow at the National Defense University’s Center for Technology and National Security Policy and CEO of BMNT Partners.
  • Steve Weinstein a 30-year veteran of Silicon Valley technology companies and Hollywood media companies.  Steve is CEO of MovieLabs the joint R&D lab of all the major motion picture studios.

Our teaching assistants were all prior students: Issac Matthews our lead TA, and Melisa Tokmak, Jared Dunnmon, and Darren Hau.

We were lucky to get a team of 25 mentors (VC’s and entrepreneurs) who selflessly volunteered their time to help coach the teams. Thanks to the team Lean Startup mentors: Paul Dawes, Tom Bedecarre, Kevin Ray, Craig Seidel, Daniel Bardenstein, Roi Chobadi, Donna Slade, and Rafi Holtzman and other advisors; Lisa Wallace, Peter Higgins, Steve Hong, Robert Medve.

We were privileged to have the support of an extraordinary all volunteer team of professional senior military officers representing all branches of service attending fellowship programs at Stanford’s Hoover Institution, and Center for International Security and Cooperation (CISAC) and Asia Pacific Research Center (APARC) at the Freeman Spogli Institute (FSI). These included: Colonel Lincoln Bonner (US Air Force), Colonel Curtis Burns (US Army), Captain Kurt Clark (US Coast Guard), Lieutenant Colonel Kurt Helphinstine (US Air Force), Colonel Seth Krummrich (US Army)), Commander Leo Leos (US Navy), Lieutenant Colonel Eric Reid (US Marine Corps), Colonel Mike Turley (US Army), and Colonel Dave Zinn US Army.  Additional volunteers from the active duty military providing support to our teams included  Lieutenant Colonel Donny Haseltine (US Marine Corps), Captain Jason Rathje (US Air Force), Major Dave Ahern US Army) and, Major Kevin Mott (US Army).

And finally a special thanks to our course advisor Bill Perry, former Secretary of Defense and Professor Emeritus, and Tom Byers, Professor of Engineering and Faculty Director, STVP.

Herding Cats – Using Lean to Work Together

When Colonel Peter Newell headed up the Army’s Rapid Equipping Force (REF) he used lean methods on the battlefields of Iraq and Afghanistan to provide immediate technology solutions to urgent problems.

Today, his company BMNT does for government and commercial customers what the Rapid Equipping Force did for the U.S. Army.

Pete and I created the Hacking for Defense class (with Joe Felter and Tom Byers.) One of the problems our students run into is that there are always multiple beneficiaries and stakeholders associated with a problem, often with conflicting value propositions and missions.  So how do you figure out whose needs to satisfy?

Here’s Pete’s view of how you do it.


Unlike businesses, government organizations don’t sell products, and they don’t earn revenue. Instead, they have missions to accomplish and very hard problems to solve.  They use a variant of the Business Model Canvas –  the Mission Model Canvas – to map their hypotheses, and they get of the building to do beneficiary discovery. (A beneficiary can be a soldier, program manager, commanding general, government contractor, stakeholder, customer, etc.)  And just like in a commercial business they are trying to determine whether the value proposition solves the problem and helps the beneficiary accomplish their mission.

Discovery for both business and government is similar in that the only way to do it is to turn assumptions into facts by generating hypotheses, developing Minimum Viable Products and getting out of the building to test those MVP’s in the trenches where the customers and beneficiaries work. Early in the discovery process, teams are faced with a cacophony of personalities and organizations. Often, they struggle with understanding which person or group represents a beneficiary, supporter, advocate or potential key partner. It’s only through repetitive hypothesis testing that they begin to sort them all out.

It’s in the trenches however, where things become different.

Multiple Beneficiaries, Multiple Conflicts
Unlike their commercial counterparts, government problem solvers are often faced with multiple beneficiaries associated with a problem, often with conflicting value propositions. As these differences become apparent, teams must make decisions about the value proposition trade-offs between conflicting beneficiaries – sometimes even pivoting completely in favor of one beneficiary to the detriment of another.

During last year’s Hacking for Defense class at Stanford Team Aqualink experienced the conflicting beneficiaries’ problem.  The result was a significant pivot of both beneficiary and value proposition.

Aqualink started with a problem given to them from the chief medical officer of the Navy SEALS – they had no way to understand chronic long-term health issues divers face. Divers work 60 to 200 feet underwater for 2-4 hours, but Navy doctors currently have no way to monitor divers’ core temperature, maximum dive pressure, blood pressure, pulse and the rebreather (air consumption), or the dive computer (dive profile) data.

Having all this new data would give a diver early warning of hypothermia or the bends. More importantly the data would allow the medical director to individually assess the short and long-term health of each diver. And medical researchers would have access to detailed physiological data. The medical director tasked the team with building a wearable sensor system and developing apps that would allow divers to monitor their own physiological conditions while underwater and to download it for later analysis.

In the first week of the class this team got out of the building, suited up in full Navy diving gear and did customer discovery by spending an hour in the life of the beneficiary.

But as the students on the Aqualink team spoke to the SEAL team divers, (another one of their beneficiaries), they experienced an existential crisis. Most of the divers were “ambivalent” (read hostile) about the introduction of a vitals monitoring platform, (“If you gave to us at 0900, it would end up on the bottom of the ocean by 0905.”) Having worked so hard to get into the SEALS, no diver wanted doctors telling them they could no longer dive.

After further questioning, the team discovered the reason the divers were spending so much time underwater – they often did not know where they were. To find out, they had to get a GPS fix. This meant their minisub (called the SEAL Delivery Vehicle) had to rise to within 6 feet of the ocean surface so the GPS antenna could broach the surface. And to do so they had to surface slowly to avoid giving the divers the bends.

The divers told our student team, “Screw the health sensors. Build us a GPS sensor that can be deployed from 100 feet underwater.”

Now the team had a dilemma. They would have to decide which beneficiary to focus on – the SEAL Team medical director, who was the sponsor of their problem, or the operators of the delivery vehicle and divers within SEAL Delivery Vehicle Team One, along with their immediate chains of command in SDVT-1 and Naval Special Warfare Group 3.

When they went back to the medical director with their findings, he was surprised as they were.  “Never knew that’s why they spent all that time down there.  Heck, yes, fix their problem first.”

Understanding the Problem Context and Problem Ecosystem
As Aqualink shows, getting out of the building – interviewing the beneficiaries, drawing their workflows and mapping a day-in -their-life – will give you a more complete picture of the context in which a proposed problem exists. Talking to multiple beneficiaries will lead to better understanding of the entire ecosystem of the problem. Often this will show that the problem you have been given is merely a symptom of a larger problem, or is the result of a different problem.

The solution is to:

  1. Cross check the results of your discovery between different beneficiaries. Often, you’ll find that they seldom have a complete understanding of one another’s workflows and pain points but instead are championing the solution to a mere symptom of a different problem.
  2. Share what you learned in discovery among the different beneficiaries. This will arm you with the tools needed to get them (or their leadership) to agree on the right problem that needs to be solved first. In many cases this will lead to your first pivot!

The goal is to sort out who has a value proposition that must be addressed first.

The power of beneficiaries helping one another
While discovery with multiple beneficiaries can be confusing and exhausting, there is immense power when all the beneficiaries work together. Therefore, the goal of customer discovery is not just to understand the pains and gains of individual beneficiaries, but to find a shared purpose between all of them.

Once they understand they share the same goal, they can solve pain points or create gains for each other using the resources they already control. A “shared” sense of purpose is a very powerful step in the pathway towards a deployable solution.

When the Department of Energy asked BMNT to build a training program for getting veterans into advanced manufacturing jobs, we saw the power of a shared purpose between multiple beneficiaries first hand.

The problem we were asked to solve is that of the 10,000 veterans who leave military service every month, many remain unemployed or underemployed, yet at the same time the number of unfilled advanced manufacturing jobs in the U.S. is expected to climb to over a million by 2020. From a business perspective, obtaining technically qualified talent is among the top constraints to growth in the US.

Seems like it would be a match made in heaven, right?  Not so fast…

While we initially thought the beneficiaries of the effort were the veterans, we quickly discovered there were other beneficiaries in advanced manufacturing. We found these additional beneficiaries had different pains and gains which in turn required different value propositions to solve their problems.

Our customer discovery taught us that there were three additional beneficiaries:

  • Universities needed to grow their enrollments. Our discovery showed us universities were willing to create programming for Advanced Manufacturing, but first needed to see a business case for how it would increase their enrollment to make it a worthwhile effort.
  • Industry needed to attract and hire qualified employees. We learned that technically qualified employees within industry were in such demand that the number one way to get qualified employees was to pilfer them from others.
  • Government Agencies needed to help their communities build skilled labor pools to attract new industries.

And we learned that our initial beneficiary, veterans leaving service, didn’t need internships or low-paying jobs, but needed jobs that paid enough to support their families.

We found each of these beneficiaries had a shared purpose. And each of them had a value proposition that would create a gain or relieve a pain point for another beneficiary. These were big ideas.

We found that as these overlapping value propositions emerged, we used the results to get the beneficiaries to come together in a workshop designed to jointly create a shared minimum viable product that they could then use to test within their own organizations.

Bringing the groups together in a workshop also served to align value propositions between beneficiaries by demonstrating that there was a way to create a single program that served all their needs. And we created an environment that allowed each beneficiary to discover that the other beneficiaries were partners they could work with in the future.

What was the impact of bringing the beneficiaries together in a workshop and creating this beneficiary ecosystem for advanced manufacturing?

Lawrence Livermore National Lab (LLNL) created a veterans’ jobs program. They teamed with a local college to create internships that allowed veterans to work during the summer.  In turn, the local college created additional advanced manufacturing classes to meet LLNL’s technical needs and the regional workforce investment board provided funding.

In Fort Riley, the Army base in Kansas, the military teamed with Kansas State University to create an advanced manufacturing program. Kansas State created a series of advanced manufacturing classes. Soldiers leaving the service can take these courses at a nearby campus beginning up to six months before they leave service.

An unexpected consequence is that today there are soldiers from Fort Riley using advanced manufacturing processes to create parts for vehicles and equipment at the Army base.

Lessons learned

  • Government problem solvers will often be faced with multiple beneficiaries with different value propositions. Share what you learn from different beneficiaries with each other to sort out which has a value proposition that must be addressed first.
  • The benefit of having multiple beneficiaries is that their strengths can be used to help one another create gains and relieve pains for one another. Creating a shared sense of empowerment from working together smooths the pathway towards scaling the right solution.

Hacking for Defense Goes National

Our goal was to scale Hacking for Defense classes across the US – giving students the opportunity to perform national service by solving real defense/diplomacy problems using Lean Methods. In exchange our government sponsors benefit from 1) access to talent that most likely would never have served the country, 2) getting solutions as minimum viable products/prototypes in 10 weeks, 3) exposure to a problem solving methodology used in Silicon Valley and battle tested in Iraq and Afghanistan.

This week we are doing what we said we’ll do – scale the class nationally:

screen-shot-2017-01-15-at-5-12-36-pm

screen-shot-2017-01-15-at-5-14-39-pm

screen-shot-2017-01-15-at-5-02-14-pm

boise

screen-shot-2017-01-15-at-5-18-28-pm

screen-shot-2017-01-15-at-5-19-54-pm

screen-shot-2017-01-15-at-5-03-06-pm

None of this would be possible without Pete Newell and Joe Felter and the entire team at BMNT and the extraordinary teaching team at each of these universities.

This week I’m in Washington co-teaching the 2nd Hacking for Defense Educators and Sponsor class.  More universities coming to the program, more government sponsors sharing problems, more variants being taught in 2017 (Diplomacy, Impact/Development, Space, Cities, Hollywood, etc.)

%d bloggers like this: