Situation
A Series A SaaS company had just hired their first dedicated security person. But within weeks, they were getting complaints from engineering about “security blocking everything.”
The new security lead was doing their job—questioning architecture decisions, pushing back on insecure implementations. But the organizational context wasn’t there. Teams saw security as an obstacle rather than a partner.
The founder was caught between wanting to move fast and wanting security. Neither side felt heard.
Approach
The issue wasn’t the security lead. It was that no one understood the “why” behind security decisions.
We restructured how security decisions were made:
1. Create transparency. Document not just what you’re doing, but why. When teams understand the reasoning, they stop resisting.
2. Make security someone else’s job. Instead of security lead approving everything, enable engineers to make secure decisions themselves. Shift from “security gatekeeping” to “security enablement.”
3. Show the trade-offs. Security isn’t about saying no—it’s about making conscious trade-offs. Sometimes speed wins. Sometimes security wins. The conversation should be explicit.
Results
The dynamic shifted within 2 months:
Engineering stopped seeing security as a blocker. When they understood the reasoning and had clarity on the trade-offs, they became partners rather than adversaries.
Deployment speed increased. Ironically, being clearer about security made releases faster because teams stopped second-guessing decisions.
The security lead went from bottleneck to advisor. Instead of reviewing every decision, they were consulted on the ones that mattered.
Key insight
Culture shifts when people understand the reasoning. Security programs fail not because the controls are wrong, but because teams feel security is imposed on them rather than something they’re part of building.