Most security programs fail not because the controls are weak, but because the people around them learn to route around the friction. A developer stores a production token in a Slack DM because the vault takes three approvals. A sales lead forwards a contract to a personal Gmail because the sanctioned file-share is slow on mobile. Nobody in that story is reckless. They're just trying to ship.
That's the real tension. Security that fights the workday loses, quietly, in a thousand small workarounds you never see until the breach post-mortem. The goal isn't to make people care more about risk. It's to make the secure path the fast path.
Friction is a signal, not a virtue
There's a stubborn belief in this field that if a control is annoying, it must be working. I've watched teams add a mandatory manual review step to every deploy and call it "security maturity." Six weeks later, half the org had shadow pipelines to avoid it.
When a control creates friction, treat it as a design bug to investigate, not a badge of seriousness. Ask a blunt question: what is this actually preventing, and how often? If a step blocks one real incident a year but costs 200 engineers ten minutes a day, you're not managing risk — you're subsidizing it with everyone else's time.
The best security control is the one your team doesn't have to think about because it's already the default.
Make the paved road the secure road
The single highest-leverage move I recommend is investing in a "paved road" — the well-supported, secure-by-default way to do common things. When the easy path and the safe path are the same path, compliance stops being a negotiation.
- Secrets: a vault with a one-line SDK call and short-lived credentials beats a policy document telling people not to hardcode keys.
- Access: SSO plus just-in-time elevation that grants access for four hours on request beats standing admin rights nobody ever revokes.
- Code: a pre-commit hook and a CI gate that catch the vulnerability in 20 seconds beat a quarterly pen-test that finds it after it shipped.
Notice the pattern: the secure option is also the lower-effort option. That's the whole game. You're not asking for discipline; you're removing the reason to cut corners.
Meet developers where they already work
Security tooling that lives in a separate portal, with its own login and its own ticket queue, gets ignored. Push findings into the pull request, the IDE, the chat channel the team already lives in. A vulnerability comment inline on the exact line, with a suggested fix, gets resolved. The same finding in a PDF report emailed to a manager gets forgotten.
The same logic applies to alerts. If you route every low-severity finding to the same channel as the criticals, people mute the channel — and then they miss the one that mattered. Tune ruthlessly. A quiet, trusted alert stream is worth more than a comprehensive, ignored one.
Build judgment, not just rules
Rules scale badly because attackers don't follow your threat model, and neither does reality. What scales is judgment. In my engagements, the teams with the strongest security posture aren't the ones with the thickest policy binder — they're the ones where an engineer feels safe saying "this looks off, can someone look?" without fear of being blamed.
That culture is built in small moments. A few things that consistently work:
- Blameless retrospectives. When someone reports their own mistake, the response is thanks, not punishment. Punish disclosure once and you'll never hear about the next one.
- Security champions. Embed one interested engineer per team as the local point of contact. They translate context both ways and catch issues long before a central team could.
- Short, specific, timely training. A five-minute explainer tied to a real thing that just happened beats an annual hour-long compliance module everyone clicks through.
Where to start on Monday
Don't try to boil the ocean. Pick the one control your engineers complain about most and sit with them while they work around it. That workaround is your roadmap — it tells you exactly where the secure path is too slow.
Then fix that one thing properly: make the safe way the default, put it where they already work, and measure whether the shortcut disappears. Do that three or four times and you'll have something a policy document can never buy — a team that reaches for the secure option because it's genuinely the easiest one in front of them.
Ask yourself this week: where in your own workflow is the secure path the slow path — and who's already routing around it?