Requirements and Reality

What “User Focused” Defense Tech Should Look Like

Office Space, did not set out to be a movie about the inefficiencies of the Department of Defense Acquisitions. It accurately depicted how the layers between the people that build things and the people that use them produces bad products. In defense tech it’s just amplified. Engineers don’t talk to the soldiers who will use their kit or hardware in a firefight. They talk to intermediaries that hand off requirements. Different intermediaries then accept the solution. It is a structural distance that explains why great engineering fails in the moments it matters the most.

In commercial tech, the customer and the user are usually the same person. The guy that touches the UI is the guy that buys. You make a B2B SaaS platform, great! Your customer is a business, the user is a person at the company. You make a computer. Awesome, your customer is whoever buys the computer. Defense acquisitions subvert this. The customer is a Program Executive Office (PEO). They hold the checkbook, so the power. The user, a 20-something year old, with little formal power to shape requirements, and often no knowledge of who they would talk to about it anyway, is not really considered. Firms build to satisfy acquisitions gates and metrics, not combat.

They work “The Requirements.” A defense tech firm needs to build to some known set of requirements. These trace back to strategic guidance, threats, missions, and tasks and are supposed to have quantifiable attributes and metrics to measure success. You know what engineers love, metrics, and that all that sounds great. Until you remember that we are talking about designing a device to work at the worst possible moment of a 24-year-old second lieutenant’s life.

Engineers develop technical solutions to hard design problems. They optimize for neat technical solutions. They design a radio to time the small gaps in vehicle mounted jammer’s broadcast so you can talk even while your jammer is on. You just must remember not to speak for 5-8 seconds after you key the mic. In training, everything works well. People pause and wait to speak. Then in combat, your vehicle is under attack and the first thing you, and your team, forget is that you need to wait to speak. Your heart is pounding in your ears and every transmission is incomplete, garbled, and needs to be repeated.

Engineers, the ones that have not been in those situations, will design solutions that require hand eye coordination and fine motor skills, not to mention clear thinking. That is great for normal everyday use, but those are not where the aim needs to be. The aim is to develop systems that work, and are workable, when people are literally and figuratively falling apart. Designing technology for soldiers is not about designing perfect user interfaces. It is about creating something that is useable and useful in the worst moments.

There is something exceedingly hard to quantify about those worst-case moments. What all of them have, is risk taking. The military cultivates a sense of acceptable and unacceptable risks at an early age. The list of acceptable risks would be very weird to those not in the military. The risk tolerance for civilians is different for a lot of good reasons, and soldiers do take dumb risks.

Smart risk taking is something good defense tech firms must cultivate. Remember, most engineers like metrics. They like repeatable tests. Sometimes, that is hard to do if the test is “I am going to scare the hell out of you, stress you out, keep you up for two days, then make things explode around you and see how well you can work this device.” Not a lot of reproducibility there. That is the test that builds equipment that works.

Equipment that works when people are actually falling apart is the metric. Yes, it still needs to meet mission needs, but it needs to meet them in the worst-case scenario. This is one of the good things about changes to the Joint Requirements Oversight Council, one less body that exists at echelons above reality dictating what the “warfighter needs.” The services need to enable rapid field testing and more user-centered prototyping. Acquisitions professions need to reward useful failures. If you run a small defense firm, embed with a unit for 48 hours. If you’re a PM, ask for prototypes you can hand to a squad and iterate on. If you’re a soldier, tell us what breaks when the bullets start. Put the user back in the center. Software patches won’t fix that

If you’ve seen gear fail in the field, message me the anecdote. I’ll publish them and try to continue pushing for more user engagement at all level of defense tech.