There is a strange asymmetry between the military world and the private security industry.
The people move freely between them. Veterans, former police officers, ex-military engineers — the private security sector is full of them. I am one of them: 26 years in law enforcement, sergeant to lieutenant colonel, before I crossed over. Walk into any security operations center in America and you will find résumés that begin in uniform.
The ideas, however, do not move. The two industries share personnel and almost no doctrine. Military engineering spent decades learning — expensively, sometimes fatally — how to build systems that survive contact with real conditions and real operators. Private security technology, for the most part, never inherited those lessons. It inherited feature lists instead.
This article is about the single most valuable idea that should have made the crossing sixty years ago. It is called KISS, and it was written for fighter jets. It applies, almost word for word, to the software your guards carry tonight.
What KISS actually says — and what it doesn't
KISS stands for Keep It Simple, Stupid. Most people have heard the phrase. Most people also misread it.
The "stupid" is not aimed at the user. It never was. It is a warning addressed to the designer: if your system can only be operated after long explanations, extensive training, and a thick manual, you have not built an advanced system. You have built a fragile one — and you have shifted the cost of your complexity onto the person least able to absorb it.
A second correction, because the internet repeats it endlessly: the KISS principle is often loosely credited to "the U.S. military" or specifically to the Marines. Its actual origin is more precise, and more instructive.
Born at Skunk Works: the field-repairability doctrine
The KISS principle is credited to Kelly Johnson, the legendary lead engineer of Lockheed's Skunk Works — the division behind the U-2 and the SR-71 Blackbird. The phrase spread through U.S. Navy engineering circles in the 1960s and from there into general engineering culture.
Johnson's original framing had nothing to do with slogans. It was an operational requirement he imposed on his own design teams:
A combat aircraft must be repairable in the field, under combat conditions, by an average mechanic, with a basic set of tools.
Read that sentence again as a design constraint. It rules out elegance that only works in the hangar. It rules out systems that assume the best technician, the full toolkit, the calm environment. It forces every engineering decision through one filter: what happens when this thing meets reality at its worst?
The story goes that Johnson once handed his engineers a handful of ordinary tools and told them the aircraft they were designing had to be fixable with those tools and nothing more. Whether every detail of the anecdote is literal, the doctrine behind it shaped decades of military engineering: the field is the test, and the field does not grade on effort.
That doctrine is the bridge between Johnson's world and mine.
The 3 AM standard
Replace "combat aircraft" with "patrol verification system" and "average mechanic" with "security officer hired three weeks ago," and Johnson's requirement translates without losing a word.
A security guard does not operate software at a desk. He operates it:
- at 3 AM, at the low point of the human circadian cycle,
- in rain, in cold, often in gloves,
- in the dark, on a site he may have been assigned to yesterday,
- under time pressure, sometimes under stress,
- with whatever phone is in his pocket and whatever training fit into one shift briefing.
If recording a routine incident requires navigating five menu levels under those conditions, the failure that follows is not a user error. It is a design error that was allowed to leave the office. Military engineering learned this lesson with airframes. Security software, as an industry, has largely not learned it at all — which is why so much of it reads like it was designed for the demo, not the post.
In security operations, complexity is not a feature. It is a failure mode. A missed checkpoint, an unfiled report, a misconfigured schedule — in this industry those are not inconveniences. They are the exact gaps that incidents walk through.
The five questions that actually matter
Vendors in this category compete on feature counts: real-time monitoring, geofencing, checkpoint management engines, automated report pipelines. The vocabulary is impressive. It is also beside the point.
Strip away the terminology and every security director, property manager, and contract client is asking the same five questions:
- Did the patrol happen?
- Was the guard actually there?
- When?
- What did they find?
- Is there proof?
That is the entire job. If a system answers those five questions in seconds — with GPS context, QR checkpoint scans, timestamps, photos, and incident reports as evidence — it has succeeded. If it answers them only after training courses and report exports, it has failed, no matter how long its feature list runs.
This is Johnson's filter, applied to our industry: not what can the system do, but what survives contact with the field.
I fought this battle inside my own company
I will admit something: importing this doctrine into software development is a fight, even when you own the company.
When we built Trinity Guard®, the single greatest source of friction between me and our engineering team was exactly this. Engineering instinct pulls toward capability — more options, more configuration, more power surfaced to the user. Field instinct pulls the opposite way, because every additional button is one more thing that fails at 3 AM in the hands of someone hired last week. We argued about it constantly, for three years of live beta testing with a real security company, and the field won every argument it entered. I wrote that story in detail here: how a police commander and a software engineer built a guard tour system together.
The point of retelling it is this: simplicity in a shipped product is never an accident and never a limitation. It is the visible result of someone with field standing repeatedly telling the engineers no. Kelly Johnson had that standing at Skunk Works. Someone has to have it wherever security software gets built — and in most of this industry, nobody does.
Simplicity is not less capability
The most common misreading of KISS is that simple systems do less. Johnson's own aircraft refute it — the SR-71 remains one of the most capable machines ever flown, designed under the same man's ruthless simplicity doctrine.
The real relationship runs the other way: the best systems make complex work feel simple, because the complexity has been absorbed by the design instead of exported to the operator. Design researchers have since described KISS as possibly the first usability principle in product design — decades before "UX" existed as a word. Behind a one-tap checkpoint scan there is GPS validation, timestamping, sync logic, and evidence chains. The guard does not see any of it, and that is precisely the achievement. The user was never supposed to admire the technology. The user was supposed to get the result.
This is why, at Digital Guard Tour, the operating question in every design review is the same one, asked until it stops producing answers: Can this be simpler? It is why the system runs on the smartphones guards already carry instead of dedicated hardware. It is why a site can be set up and the first verified patrol launched in minutes, not weeks. And it is why a manager sees what happened on a patrol at a glance, instead of excavating it from reports.
Keep It Simple and Secure
The two worlds this article connects — military engineering and private security — will keep exchanging people. My argument is that they should finally start exchanging doctrine, and that KISS is the place to start, because it was field-tested at a level of consequence our industry will never face: Johnson's designs were judged by whether pilots came home.
At Trinity Guard®, we adopted the principle and rewrote one word of it, into a form we hold ourselves to in every product decision, every onboarding flow, and every line of interface copy:
Keep It Simple and Secure.
Because security is complex enough on its own. The job of a security system is not to add to that complexity. It is to take the complexity that already exists — sites, shifts, patrols, incidents, evidence — and make it simple to run and impossible to dispute.
Your guards patrol. The system proves it. Everything beyond that had better justify itself.
Related reading: How Trinity Guard® was built between the field and the office · Why Trinity Guard was founded
