The U.S. military was making base location decisions — where to set up operations, which sites could support specific mission types — with fragmented data and institutional memory. My predecessor called the prototype "CB-SITE." The stated problem was "build a site location database." That was the obvious problem. I kept asking: which data transfers globally, and which just looks like it does?
My mentor Jim Westervelt — creator of GRASS GIS — gave me the only advice that mattered on day one: go talk to the people who will use it before you build anything. It became the rule I've never broken.
The original tool was built for one country at a time. To make ENSITE globally applicable, I had to rethink the entire data architecture. Which datasets actually transfer across geographies? Which variables that "work" in one theater are meaningless in another? I evaluated data sources for worldwide applicability and set standards for what would — and wouldn't — be part of the system.
This wasn't just a technical decision. Every data standard I set was also a policy decision about what the military would trust. I built the governance framework from scratch: a formal review process, a governance board, and a staff education program so decisions about data quality didn't live in one person's head.
The unique tension in defense product work: your users are not your decision-makers. Commanders set intent — "evaluate 50 potential sites in this region before next week" — and the tool has to support execution without knowing the specific mission context. I couldn't ask "what are you actually trying to do?" the way I might with a civilian client.
I learned to design for ambiguity. What does "good enough to act on" look like when the stakes are operational? What does a decision-maker need to see to trust the output? That thinking shaped every UX decision.
What I'd do differently
In hindsight, we didn't do user research as well as we could have. We were researchers, not operators — and sometimes we pursued what was technically interesting over what was truly useful in the field. I spent time at Fort Leonard Wood talking to users, but not enough time. The gap between what we built in the lab and what commanders needed operationally was real.
That honest gap is part of why I operate the way I do now. The lesson from ENSITE wasn't just "talk to people." It was: talking to people isn't enough if you're not asking the right questions, in the right context, with enough humility to hear things that challenge your assumptions.
I traveled to South Korea to meet with command teams and understand how they used data in the field versus how we imagined they used it in the lab. I built working relationships with NGA (National Geospatial-Intelligence Agency) — the people who actually controlled the data we needed.
The framework I built ENSITE around: every candidate site gets evaluated across physical, built, and social factors, from terrain and infrastructure to who already lives there and what resources they rely on.
ENSITE running a live scenario. Planners set the constraints that matter for a given mission, and the tool ranks the ground accordingly.
ENSITE deployed after Russia's invasion of Ukraine — reducing the time to locate and evaluate potential military base sites. The data governance framework I built from scratch became the standard for how CERL managed geospatial data products.
I received the Department of the Army Medal for Civilian Service for the CB-SITE leadership component. The peer-reviewed work and technical reports are part of the permanent ERDC record.