In most organizations, there’s a familiar tension between security and delivery. When pipelines slow down or deployments stall, the explanation is often the same: Security requirements are getting in the way. This framing is convenient and misleading. 

In my experience, security controls don’t slow teams down by default. Poorly designed security controls do. The distinction matters because it changes where you focus your effort. If you assume friction is inevitable, you accept it. If you treat friction as a design flaw, you fix it. 

Friction is a Signal, Not a Cost of Doing Business 

When developers complain about security, they’re rarely objecting to the goal. Most engineers understand the need to protect systems, data and users. What they react to is unpredictability and interruption. 

The most common complaints sound like: 

• I don’t know why my change is blocked. 

• I need a ticket for something that should be routine. 

• This approval takes longer than the work itself. 

• Security shows up only after things break. 

These aren’t signs of reckless teams; they’re signs of controls that weren’t designed with real workflows in mind. 

The Approval Trap 

Manual approvals are one of the most common sources of friction. They’re often introduced with good intentions: Risk reduction, accountability and compliance. Over time, they turn into bottlenecks. 

The problem isn’t the approvals themselves. It’s where and how they’re used. If every change — low-risk or high-risk — requires the same review path, teams will either slow to a crawl or find ways around the process. Neither outcome improves security. I have seen organizations where engineers batch changes just to reduce approval overhead. This increases risk, not reduces it. Others quietly copy configurations from ‘known good’ services without fully understanding them, because getting explicit approvals takes too long. It’s not a people failure — it’s a design failure. 

Gates vs. Guardrails 

One useful way to think about this is the difference between gates and guardrails. Gates stop progress until someone intervenes, while guardrails allow progress within defined boundaries. 

Security controls designed as gates assume that humans must be involved for safety. Controls designed as guardrails assume that most activity is legitimate and focus attention only when risk increases. 

For example: 

• Blocking every infrastructure change until reviewed is a gate 

• Preventing deployments that exceed predefined risk thresholds is a guardrail 

The second approach lets teams move quickly while still enforcing security intent. It also scales far better. 

When Security Becomes a Ticketing System 

Another source of friction is treating security as a service desk. Access requests, exceptions and reviews — all routed through tickets that pile up faster than teams can process them. From an operational perspective, this creates several problems: 

• Security becomes reactive instead of preventative. 

• Context is lost in ticket backlogs. 

• Engineers plan work around wait times, not technical readiness. 

More importantly, it disconnects security decisions from the systems they affect. By the time a ticket is reviewed, the environment may have already changed. Security that lives in queues struggles to keep up with environments designed for continuous change. 

Design for the Common Case 

One of the most effective ways to reduce friction is to design controls around what teams do most of the time, not the worst-case scenario. Most deployments are routine. Most access changes are incremental. Most configuration updates are low risk. If your controls treat every action as equally dangerous, teams will feel that weight constantly. 

Better designs ask: 

• What does ‘normal’ look like here? 

• What signals indicate increased risk? 

• When should humans actually be involved? 

When human review is reserved for genuinely ambiguous or high-risk situations, it carries more weight and causes less resentment. 

Automation Doesn’t Mean Loss of Control 

There’s a persistent fear that reducing friction means giving up control. In practice, well-designed automation often increases control. Automated checks are: 

• Consistent 

• Fast 

• Transparent 

• Less prone to fatigue 

When controls are automated and predictable, teams learn how to work within them. When controls are manual and opaque, teams learn how to avoid them. The goal isn’t to remove humans from security decisions; it’s to put human judgment where it adds value, not where it simply slows things down. 

Measuring the Wrong Things 

Many organizations measure security success through policy compliance and approval counts. Those metrics don’t capture operational impact. More useful questions include: 

• How often do controls block low-risk changes? 

• How long do routine approvals take? 

• How frequently do teams bypass controls? 

• How much on-call noise do security checks create? 

These indicators reveal whether controls are helping systems stay safe — or just making work harder. 

Security That Earns Trust 

When security controls are well designed, teams stop seeing them as obstacles. They become part of the platform — something engineers rely on rather than work around. That trust isn’t built through mandates. It’s built through consistency, clarity and respect for how systems actually operate. Security that slows teams isn’t inevitable. In most cases, it’s a sign that controls were designed without enough attention to real workflows 

Fix the design — and the friction often disappears.