Tools: Dispatch From the Other Side: Aligned Incentives

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. Let's compare this to another approach. A vulnerability management team I worked with reached out to a development team about a low risk finding without an available fix. They blocked it from going to production. The security team was measured on eliminating known vulnerabilities. The development team was measured on shipping working software. Leaving that tension unresolved eroded trust faster than any missed vulnerability ever could. 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. 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 it 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. I’ve learned that security is one dimension of overall quality. Teams are managing operational risk alongside security risk. A security patch can impact the availability of a system if it is not well tested or implemented in a rush. Security debt competes with feature debt, operational debt, and architectural debt. It does not exist in isolation. I've seen many different 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. When incentives align, trust follows. That shift moves security from an adversarial relationship to a partnership. It also increases impact for the issues that can’t be solved with tooling improvements alone. 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. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - From Scripts to Software
- Designing For Leverage