Early in my career, a boss of mine had a formula. Security equals one over productivity. He said it like it was physics. The more security you had, the less productivity you had. The more productivity you wanted, the less security you got. That was the trade, and the CISO's job was to argue for the right point on the curve.
I believed him. For years.
I do not believe him anymore. I think it is the most expensive idea in our field, and I think most security programs at scale still operate inside it, even when the leaders running them swear they do not. You can hear it in how teams describe their own work. Number of reviews completed. Number of findings closed. Number of policies enforced. The unit of value is the gate, and the gate is the thing the company routes around when it actually needs to ship.
This is the productivity tax framing of security, and changing it has become the work I care most about.
Let me try a different frame.
Brakes Make You Faster
Formula 1 cars do not have the most powerful brakes in motorsport because the engineers wanted to slow down. They have the most powerful brakes because brakes are what let a car take a corner at three hundred kilometers an hour. Remove the brakes and the car does not go faster. The car cannot enter the corner at all. It has to lift off the throttle a hundred meters earlier and hold a survival speed all the way through.
The same logic applies to downforce. The wing on the back of an F1 car looks like an obstacle. Aerodynamic drag, more weight, more energy required to push the car forward. Engineers add it anyway, because without it the car cannot put its power down. The downforce that costs a few kilometers an hour on the straight is what allows a hundred kilometers an hour through the corner.
Security is supposed to work the same way.
The job is not to slow the car down. The job is to make speed survivable. A team that ships ten times a day with an attack surface they understand is faster than a team that ships once a week and prays. The engineering organization that can move fast on regulated data because the controls are paved into the platform is faster than the one that has to assemble approvals every time. Speed without security is not speed. It is acceleration in a straight line until the first corner, and then a wall.
The teams that internalize this stop measuring themselves by the number of reviews they completed. They start measuring themselves by how much the engineering org can do without ever having to talk to them.
Remove Friction to Enable the Right Thing
The first move is harder than it sounds.
Most security programs accumulate friction the way old codebases accumulate technical debt. Every incident produces a new control. Every audit produces a new requirement. Every leadership change adds another layer. The result is a program that has tripled the number of things engineers must do before shipping, with no corresponding tripling of risk reduction. Engineers learn to route around the controls that do not actually do anything. The controls that do matter get routed around with them, because by the time engineers are looking for the bypass they cannot tell the difference.
The work is to remove the friction that exists for historical reasons rather than functional ones.
Paved roads instead of approval gates. Defaults that are secure without anyone having to ask. Self-service tooling for the eighty percent of cases that follow a known pattern, with senior security attention reserved for the twenty percent that do not. The metric that matters is not how many reviews you completed. It is how many reviews you made unnecessary.
A program that removes its own friction is not a weaker program. It is a stronger one, because the friction it does keep is the friction that earns its keep.
Introduce Friction to Prevent the Bad
The second move is easier to articulate but harder to do politically.
Once you have removed the friction that exists for historical reasons, you have credibility for the friction that prevents actual harm. The downforce on the corners. The brakes for the moments speed becomes dangerous. Hard stops in front of customer data. Mandatory reviews for changes to authentication. Required approvals for anything that touches financial flows. Friction that is rare, deliberate, and obviously load-bearing.
Engineers who have been freed from pointless friction will accept the friction that is not pointless. Engineers who are drowning in pointless friction will fight every new control as another tax, even the ones that genuinely matter.
This is the order that most security programs get wrong. They keep adding friction in the name of safety, then wonder why nobody trusts their judgment on which friction matters. The trust is built by deletion, not addition. You earn the right to introduce friction by being the team that aggressively removes it.
Your Engineers Are Your Customers
Here is the part of the work that security training does not teach.
I spent part of my career as a founder and as a product leader for one of the startups I sold. What I learned in that chapter is a skillset that almost nobody in security comes up with, and it changes how you do this job. Product leaders study their users. They watch how people actually behave, not how the spec says they should. They obsess about the friction in the experience, because they know that any friction the user does not accept is a place the user will route around the product. Delight is not a luxury in product. It is the mechanism by which the product gets used as intended.
Security has the same problem. Your engineers are your customers. If you do not understand their workflow, their constraints, their incentives, and the moments where your controls collide with the work they are paid to do, your controls will get circumvented. Not because the engineers are malicious. Because humans are ingenious at making their lives easier, and an engineer with a deadline will find a path through your program faster than your program will find them.
A product team that ignored this would lose to the competitor that did not. A security team that ignores this loses to the engineer who finds the bypass.
The implication is that the senior security leader's job is closer to product management than it is to audit. You research your users. You design for the path of least resistance. You build experiences that engineers choose to use, because the secure path is also the fast path. The reviews that test this work are not security reviews. They are usability reviews. Did the engineer find the right answer in under a minute. Did the tool fail in a way they could recover from on their own. Did they ship the secure thing by default, without ever realizing they had made a security decision.
There is one more piece, and it is the piece that separates a security program engineers respect from one they tolerate.
Treat your engineers as adults.
Do not hand them a list of rules and expect compliance. Do not police them. Give them the tools, give them an honest read of the threat landscape and the business stakes, and work with them on the goals. Engineers are not the problem to be managed. They are the people building the thing that has to be defensible, and they almost always understand the system you are trying to protect better than you do. A program that treats them as smart partners gets smart partners. A program that treats them as a risk to be controlled gets the minimum effort required to look compliant.
This is the skillset we do not train into security leaders today. We should. We have to.
What This Looks Like in Practice
A few questions that test whether your program is actually a downforce program or a productivity tax.
What percentage of security work is reactive versus proactive? If most of your team's time goes to responding to engineering requests rather than building the paved roads engineers walk on by default, you are a tax.
How many of your team's reviews end with the answer "yes, ship it"? If most reviews approve what was already going to ship, you are a tax. The review existed to create a record, not to change an outcome.
How long does it take an engineer to do the right thing on a new project? If the answer is measured in days, the right thing is the harder path and engineers will find a faster one. If the answer is measured in minutes, the right thing is the path of least resistance.
How many of your controls are documented in policies versus enforced in tooling? Policies that depend on humans reading them and remembering them are not controls. They are aspirations.
What happens when an engineer ships something that bypasses a security expectation? If the answer is "we discover it three weeks later in a review," your program is producing the appearance of safety without the substance.
The Real Move
The senior security leaders who are reshaping this field are the ones who stopped accepting the framing. They are not arguing that security teams are slower than they look or that the productivity tax is misunderstood. They are deleting the tax. Replacing it with infrastructure. Building experiences engineers choose to use. Making the right thing the default thing.
The job is not to slow the car down. The job is to build a car that can take the corners.
The teams doing this work are the ones that will run security in the era we are entering. The ones still measuring themselves on gates closed and reviews completed are going to be replaced. By automation. By paved infrastructure. By a customer who finds someone faster.
Pick a corner. Build the downforce.