A version of this post appeared in Fortune.

When we talk to security leaders about their biggest challenge, the response is almost always the same: “We don’t have enough people.” Infosec teams everywhere are stretched thin, and companies simply can’t hire enough people to keep up with ever-increasing needs across security, privacy, and compliance—often despite healthy budgets and salaries.

The situation is hardly surprising given the shortage of cybersecurity talent. The low supply of skilled security professionals is a widely acknowledged problem for the industry, with four million positions open and unfilled worldwide, according to the non-profit IT security organization (ISC)².

But a large part of the problem also lies in the demand-side. Why do security teams need so many people in the first place? One important reason is that most products in our industry still have an over-reliance on human capital. They require constant babysitting, create checklists of tasks, and hog attention with yet another “single pane of glass.”

In contrast, some of our most essential security products almost seem to run themselves. How do they do it? They are intentional about keeping overhead low, often using one or more of the following design principles.

Principle 1: Involve end-users in the workflow

“Security is everyone’s responsibility” has become somewhat of a cliché, used everywhere from public transit announcements to corporate security awareness presentations! But the best security products weaponize this insight to create self-serve workflows that rely on end-users.

Arming users with simple workflows decentralizes the operational load of the solution and also reinforces a sense of shared accountability. And it can be more effective too, since end-users often have business context that a centralized security team doesn’t.

Take a hypothetical DLP product as an example. When a user shares a file externally, it’s incredibly challenging for a security team to know how to respond because they lack sufficient context. Notifying them in this scenario just creates busywork and pain for everyone involved. A better approach might try to directly confirm intent with the end-user or their manager.

Of course, involving end-users requires marrying security and productivity. One of the best examples of striking this balance are modern MFA products. Rejecting an MFA challenge is a simple action that allows users to participate in their own security. And companies like Duo, Okta, and Yubico do a great job of packaging this workflow in an end-user experience that is easy on users and security teams.

Principle 2: Take responsibility for (sane) alerts

It can sometimes feel like the entire security profession is an exercise in responding to alerts. A lot of us wanted to be firefighters when we grew up but this probably wasn’t what we had in mind! While there are higher leverage tasks, security teams face a terrible choice between spending tons of time triaging alerts or, worse, bulk ignoring them. Too many security products abdicate responsibility for making sure their alerts are meaningful.

To be fair, getting alerting right in security is hard. The importance of a given event is highly subjective. And unlike notifications in other products, the cost of being wrong and under-alerting can be catastrophic. But, tragically, the obsession with not missing anything creates massive inefficiency. 

Low overhead security products combat this problem with a 1-2 punch. First, they start with sane defaults. They are opinionated and choose a high signal-to-noise ratio over a zero false-negative rate. Second, they include the ability to tune alert thresholds to match an organization’s risk appetite and resource availability.

For example, Thinkst Canary and other honeypot products’ defining mantra is to issue just a single, meaningful alert. At Material, by default, we alert our on-call engineers whenever we alert customers. It’s not a tactic that will scale forever, but it forces us to be thoughtful about our alerts from day 1: Is there something the customer can actually do about this alert? If so, what information would they need? Does this deserve a pager alert in the middle of the night or just an informative email?

Principle 3: Leverage existing sources of truth

For a security product to be effective, it needs organizational context (people, policies, locations, etc.). But initializing this context and keeping it up to date in every tool creates a flood of busywork.

The best security products leverage as many existing “sources of truth” as possible. And what’s more, they actually resist becoming a new source of truth (especially outside their primary value proposition). These products minimize the amount of information that needs to be configured or defined, opting for integrations instead. They are faster to set-up and automatically adapt to changes in an organization.

As a simple example, consider Fleetsmith, the Mac device management product recently acquired by Apple. Rather than build an employee directory from scratch, Fleetsmith treats a company’s Google Workspace or O365 account as the source of truth for the list of users. It’s a simple choice that saves a lot of time by eliminating the need to keep two (seemingly unrelated) systems in sync manually.

Even where integration with other tools or workflows is impossible, borrowing existing concepts, data models, or even just terminology can reduce a product’s onramp time and maximize skill interop. Good product designers know that the secret to building easy-to-use products is to reuse familiar concepts and patterns—and security is no different.

The cybersecurity skills gap demands better products

Addressing security issues with tools that require armies of people to run them will never scale—there aren’t enough people, and the problem space is continuously expanding. Instead, the industry needs to prioritize tools that alleviate the net burden on teams, not add to it. This won’t happen until builders and buyers alike are obsessed with minimizing overhead as an explicit design objective, not an afterthought.