The Pushing Fallacy: Why pushing harder makes your system more fragile
You do everything to keep your AppSec system running. That's exactly the problem.
In 2022, I took a sabbatical to travel Scandinavia for three months. Back then, I was 18 months into developing my first AppSec system from scratch.
What do you think happened while I was hiking?
Exactly.
Nothing.
Of course I didn’t expect anyone to develop the system further. I just asked them to prepare some small tasks in the meantime. Things I would usually have to wait for, as my progress depended on them.
But without my constant reminder, the 3 months just passed by unused.
I had fallen for the Pushing Fallacy.
Why did I get trapped?
When I got handed responsibility for AppSec, I took it very seriously. I wanted to build something that really helped my fellow developers to build secure software. I had no idea what I was doing, but I was determined.
The problem was, nobody would argue that security was important. But was it urgent enough to prioritize it over the feature the customer wanted to have yesterday?
Probably not.
This behavior is not a character flaw. It is a documented cognitive bias. Researchers call it the mere urgency effect. In a 2018 study, Meng Zhu at Johns Hopkins found that people consistently choose urgent tasks over important ones — even when the urgent task promises a smaller reward. They pick the deadline over the payoff. Every time.
A bug is urgent. A feature becomes urgent, because the customer is pushing for it.
Security is important, but not urgent until it’s too late.
I adapted fast. I knew instinctively, I had to create urgency. I became the two feet in their door, pushing security forward.
And of course it worked.
It worked. So why is it a fallacy?
Pushing creates urgency, urgency creates action, action creates results. The dependency gets updated. The vulnerability gets fixed. The ticket moves forward. Every push delivers a small, immediate win.
That’s exactly why the cycle is so hard to break.
B.F. Skinner demonstrated this in the 1930s: behavior that is immediately rewarded gets reinforced faster and stronger than behavior with delayed consequences. Push. Ticket closed. Relief. Push again. Our brain learns that pushing works, and it learns it fast.
The mechanism has a name: temporal discounting. We devalue rewards that lie in the future. A resolved ticket now feels more real than a fragile system in two years. The dopamine hit arrives before the damage is even visible.
But the reinforcement does not stop with you. Your colleagues are learning too.
Every time you push, you send the same signal: when security is urgent, someone will stands in the door. They learn that the reminder will come. They learn that delaying security has no consequences.
Psychologists call it the overjustification effect: when an action is always triggered by an external push, the internal drive never develops. Your colleagues never develop a reason to prioritize security on their own. You are the reason. And when you disappear, the reason disappears with you.
Two cycles. One spiral.
This is how AppSec heroes are born.
Why does this make my system fragile?
Imagine the knight fighting the dragon. That’s you. But you can’t fight all dragons everywhere at the same time. And what happens, when the dragon wins?
Yes. A hero is per definition a single point of failure.
In AppSec, you are fighting. You are pushing. This may work for some time. But eventually, you may get wounded.
The statistics are brutal. A 2025 Sophos survey of 5,000 cybersecurity professionals across 17 countries found that 76% experienced burnout in the past year. At the leadership level, it is worse: 91% of CISOs report moderate or high stress, and more than a quarter admit that stress directly affects their ability to do their jobs.
When your system depends on one person, and that person burns out, the system does not slow down. It stops.
Obviously, hero-dependence makes your systems fragile.
But even if you do not burn out, pushing has already stolen something from you: the time to build.
Every hour you spend reminding someone to close a ticket is an hour you didn’t spend designing a process that closes tickets without you. Every meeting where you’re the only one pushing security is a meeting you could have spent building ownership into the development team. Every firefight you solve alone is a firefight you didn’t use to train someone else.
You are trading progress for motion. You stay busy. You stay indispensable. You waste energy without building resilience.
Now, how can you escape the fallacy?
The first step is not to stop pushing. That’s unrealistic. Just recognize the trap.
1. Name the dependency.
Run the thought experiment. What breaks if you’re gone for two weeks tomorrow? Not “who would miss you.” What concrete process stops? Which ticket stays open? Which decision doesn’t get made? Which escalation has no path?
Write it down. That is your dependency chain.
2. Test the system.
On your next vacation, be gone. Really. No “I’m reachable in emergencies” exception.
Watch what happens. What stopped without you? That is proof the system depends on you. What lies untouched after two weeks? That is proof nobody took ownership.
If you come back and everything ran smoothly, congratulations. You may not have a hero problem.
Two weeks is a short test.
Now ask the harder question: Would the system still work if you were gone for three months? Or six months? If you quit tomorrow?
3. Break one cycle.
Take the most obvious or most fragile dependency. Eliminate it.
Not delegate it. Eliminate the dependency.
Hand the tool to the operations team. Train someone else to handle the incident. Build a process that works without your signature.
Just one.
Then the next.
That creates resilience over time.
These three steps get you started. But they don’t replace a focused diagnostic.
For that, you need to understand your AppSec program as a system. Not as a collection of tools and processes, but as a system with interdependencies, responsibilities, and pressure points.
On my website I explained the full process. Map out your system. Understand how it works and where it’s most fragile. Then optimize for resilience step by step.
I built the AppSec Ownership Model as a reference for how responsibility can be distributed in a resilient AppSec system. You can use it to decide which responsibilities are misplaced and how to rearrange them.
If you want my support with that diagnostic, that’s exactly what the AppSec Terrain Check does.
Whatever route you choose, don’t wait. Start today. Break the first cycle.