Mistakes we made in our 1st batch of H4D Sprints
At BMNT, solving hard problems is our whole world . Even from our early days, it was obvious that one of two things was going to happen. We would either thrive or crash hard within inside of a year. And the major factor in our survival was going to be our ability to solve national security problems. Our team had to optimize for learning, and work heroically on everything that came across our path.
Even with all our raw talent, we screwed up a lot. There were many mistakes during the awkward “adolescent phase” of the Hacking For Defense™ platform. Success only came because we had phenomenal people working on gnarly problems. Our process had a long way to go.
Each Sprint we unearthed more issues. Here are a few of the highlights from the first five or so:
Mistake #1: Having an owner who is only partially committed to the problem being solved. We had folks with money who were willing to pay us. That part was good. But they were often checked out, pulling double/triple duty on other projects, and only partially committed. This became a problem when we needed introductions, feedback, information, and other random things that pop up during the course of a Sprint. We’re going lightning speed. The “problem owner” can’t slow us down.
Mistake #2: Letting participants commit part of their time to other activities. This is related to #1. Partially we had to accept whoever would show up. But we also didn’t know how intense the Sprint was going to become. Now we don’t let them work on anything else during the whole week when they’re with us. Again, speed matters. Every minute is accounted for.
Mistake #3: Having problem sponsor and/or owner without access to an engaged senior leader. It’s hard to build solutions to gnarly problems. We need a lot of “sweat equity” (i.e. work) from the Sprint participants, and they will work much harder when they know that someone important is waiting to see the results. The added benefit is that senior leader offers them a chance to request things they need. Usually it’s not money, but stuff like policy modifications, more data, a test environment, or additional personnel.
Mistake #4: Trying to do a big “pitch” event on the final day. Our Sprint teams used to focus too much on the final day when we had them brief a large group of people. They got nervous and developed tunnel vision. Now we make them work more on testing their Minimum Viable Products for the first half of the morning. We treat the brief like an afterthought. This keeps them focused on what matters: testing and learning.
Mistake #5: Not providing rapid feedback to the companies who were involved. Engaging with next-gen technologies and companies is part of the value of a Sprint. Government folks love to have access to the latest and greatest. But they rarely provide any reciprocal value to the private sector. We’ve learned to be ruthless about collecting feedback and getting back to any commercial folks. Even a negative outcome (e.g. “I’m sorry they don’t see the value of your product because of X, Y, & Z.”) can still be useful. It gives the company greater insights into the problems faced by national security organizations, meaning they can make a more informed decision about whether to continue down this road.
We continue to learn as we go. Every H4D Sprint gets better in the sense of being a process that is optimized for the speed of development and testing of Minimum Viable Products that validate a national security problem.
The world is changing fast. We have to adapt even faster.
