The Phrase a Lieutenant General Coined to Describe Our Work

Years into my work as an Operations Intelligence analyst, I learned that sometimes the most lasting impact of a piece of work isn't the analysis itself — it's the language someone uses to describe it afterward.

We had built a recurring readiness product: a single-page visual summary that pulled together maintenance status, crew currency, weather windows, and mission tasking into one view, refreshed daily. It wasn't novel in concept — most units have some version of a readiness dashboard — but ours was deliberately designed to answer one question fast: "If something happened right now, what could we actually do?" Everything on the page existed to answer that, and nothing else.

During a visit from a Lieutenant General touring several units, our wing commander used that page to brief him. I watched the general study it for a moment, then say something like, "This is the difference between knowing what you have and knowing what you can do." He used a short phrase — something close to "actionable readiness" — to describe the distinction, almost as an aside.

That phrase stuck. Within weeks, it had worked its way into how our wing leadership talked about readiness products generally — not just our page, but the standard other teams were asked to meet. "Does this tell us what we have, or what we can do?" became a quick filter for whether a report was useful or just informative.

What struck me afterward wasn't that we'd built something good — plenty of teams build good products that never get that kind of traction. It was that the general's framing gave everyone else a shared, memorable way to evaluate their own work against the same standard, without needing to explain the whole methodology behind it.

It taught me something I've kept since: technical work earns trust through rigor, but it earns adoption through framing. If you can't describe what makes your work different in a sentence someone else will repeat, you're relying on people to do that translation themselves — and most won't.

Now, whenever I'm building something — a report, a dashboard, a piece of software — I try to find that sentence early, not after the fact. Not as marketing, but as a test: if I can't say plainly what this lets someone do differently, I probably haven't finished designing it yet.