Dispatch From the Other Side: Aligned Incentives
Source: Dev.to
Introduction
This is post three of the Dispatch From the Other Side series.
Links to previous posts
From the first time I heard it, Charlie Munger’s quote on incentives has stuck with me:
“Show me the incentive and I’ll show you the outcome.”
It explained something I kept running into. Development teams weren’t ignoring security findings because they didn’t care; they were responding rationally to how they were measured.
This is what makes the leveraged approaches we explored in the last post so valuable. Rather than asking teams to change how they work, you reduce the cost of being compliant. When the common case is easy, most teams will choose it.
A contrasting approach
A vulnerability‑management team I worked with reached out to a development team about a low‑risk finding without an available fix and blocked it from going to production. The security team was measured on eliminating known vulnerabilities, while the development team was measured on shipping working software. Leaving that tension unresolved eroded trust faster than any missed vulnerability ever could.
Raising the bar gradually
Development teams have limited time to address security findings. I’ve seen more success with slowly raising the bar rather than letting “perfect be the enemy of good.” Before rolling out a new cloud‑misconfiguration detection as part of the official rule set, I asked development teams for feedback. This gave them time to prepare and built buy‑in before enforcement.
Partnering instead of policing
Sometimes the number of people finding issues far exceeds the number empowered to fix them. I’ve submitted pull requests to fix security‑configuration issues rather than putting the burden on the development team. After a few of those, teams started looping me in earlier to figure out how we could remove the insecure option outright. Approaches like this turn it into a partnership and show that you’re invested in their success.
Security as a dimension of quality
Security is one dimension of overall quality. Teams are managing operational risk alongside security risk. A security patch can impact system availability if it is not well tested or is rushed. Security debt competes with feature debt, operational debt, and architectural debt—it does not exist in isolation. I’ve seen many stakeholder groups ask development teams to take corrective action on an issue without realizing how many other groups are asking them to do the same.
Aligning incentives
When incentives align, trust follows. That shift moves security from an adversarial relationship to a partnership and increases impact for issues that can’t be solved with tooling improvements alone.
Looking ahead
As generative AI accelerates how software gets built, those incentive gaps could widen. The question is whether security evolves with them—that’s what I’ll explore in the final piece.