Your Champions Programme Is Unpaid Overtime With a Sticker
// elusive thoughts // appsec // culture // fund it or do not run it
There is a Slack channel at your company called something like security champions. It was created with a lot of energy. There was a kickoff, there were stickers, there was a deck with a diagram showing six security engineers in the middle and forty developers arranged around them like a solar system. Somebody said the word force multiplier and nobody laughed.
Scroll it now. The last message is four months old. It is from you.
I have built this programme twice. The first one died exactly like that. The second one is still running, and the difference between them had almost nothing to do with security and almost everything to do with money and promotion, which is a sentence nobody wants to hear at a security conference and is nevertheless the whole of what I have to say.
The five ways it dies
The volunteer trap. You sent an email asking who wants to do it. Hands went up, good hands, people who genuinely care. Then it was a Tuesday, the team was two weeks behind on the quarterly commitment, and their manager, who never agreed to any of this and whose bonus is tied to shipping, asked what they were working on. Security champion work is not a sprint item. It is not on the roadmap. It is not what they will be assessed on in six months. The channel goes quiet in about eight weeks and everybody is too polite to say why.
The dumping ground. Now that a champion exists, you have somewhere to put things. Scanner findings for that team, send them to the champion. Security questionnaire needs a technical answer, champion. Training compliance chase, champion. Within one quarter the role has become "the person who does the security team's admin for free" and everybody can see it. The tell is easy to spot. Look at what your champions actually did last month. If nearly all of it was reactive, and nearly none of it made their own team's software better, you have built a punishment and attached a badge to it.
The training programme that changed nothing. You built a curriculum. Secure coding, the OWASP Top 10, a CTF, maybe a cert. Everybody completed it. Everybody learned something. Nothing changed, because knowledge was never the bottleneck. The champion who now knows what an IDOR is still has no time to review pull requests, no authority to block a bad design, and no standing to tell their tech lead the auth model is wrong. You handed them a map and no vehicle. Training keeps happening anyway, because completion rates are easy to report and they make a very good slide.
The one hero. One champion is genuinely excellent. They find real bugs, they push back on bad designs, other teams start asking for them. So they get more work, and more, and their own roadmap slips, and their manager notices, and their review says needs to focus. Then they get promoted out, or they leave, and the programme's entire output, which was functionally one person, goes to zero in a single Friday. If your results are concentrated in one or two people you do not have a programme. You have a dependency, and you should be losing sleep over it.
The cargo cult. You watched the Google talk, or the Netflix one, and you copied the structure. Guild, monthly sync, maturity model, RACI. None of it is connected to anything an engineer at your company experiences on a Tuesday. The meeting happens because it is in the calendar. Attendance falls ten percent a month until it is you and one loyal person who feels bad for you. You copied the artefact and not the conditions that produced it. At those companies the incentives and the executive backing came first and the org structure was the last thing they added. You did it in reverse and wondered why it did not take.
The thing that actually worked
Before we named a single champion, we went to engineering leadership with an ask so boring it is almost embarrassing to write down.
Ten percent of one engineer's time per team. Four hours a week. Named in the sprint, on the board, planned around, in exactly the same place as every other commitment the team makes.
Not as time allows. Not twenty percent time. Not a spiritual commitment made in a kickoff meeting. A line item.
And if a manager would not fund the four hours, that team did not get a champion. Not once. Not even when somebody great wanted it. Not even when it made our coverage numbers look bad in front of the CISO, which it did, for two quarters.
field note
That refusal was the single highest leverage decision I have made in this job. It converted security champion from a favour into a role. Favours evaporate when the quarter gets tight. Roles have budgets, and things with budgets get defended. It also handed me an honest metric I did not have before, teams with a funded champion against teams without, and the gap between those two columns is a conversation with a VP rather than a complaint in a retro.
Define the role by what they own, not what they attend
Four things. That is the list. Nothing else belongs to them.
They triage their own team's findings, and they have the authority to close something as a false positive without asking us. That authority is real and giving it away is the point. It is what makes the role feel like a promotion instead of a chore.
They run the threat model for their team's new services. Forty five minutes, four people, a whiteboard. We taught the format, sat in on the first two, and then got out of the way, which was harder than it sounds.
They review the pull requests that matter. Auth changes, new endpoints, crypto, anything crossing a boundary. Not every PR. The ones that count, routed automatically by a CODEOWNERS rule so that it does not depend on anybody remembering.
They are the escalation path to us, and not the escape valve for us. If it is beyond them it comes to AppSec fast and there is no shame attached to it arriving.
Now look at what is not on that list. Chasing training completion. Filling out customer questionnaires. Writing policy. Being the compliance liaison. We kept every unpleasant administrative task, deliberately, forever. The champions get the interesting work and the security team keeps the toil. Reverse that and the programme is dead inside a quarter and you will not even be able to say when it happened.
Put it on the promotion ladder, in writing
We spent three months in unglamorous meetings with HR and engineering directors to get security ownership named explicitly in the career framework, as evidence toward the technical leadership beyond your immediate team criterion that every senior and staff track already has.
That was worth more than every piece of security content we have ever produced.
Because now when a champion's manager asks why they are spending four hours a week on this, the answer is not because I like security. The answer is because it is how I am demonstrating staff level scope, and here is the framework language that says so.
Nothing sustains discretionary effort like it being the fastest route to a promotion. That is not cynicism. That is just how organisations work, and pretending otherwise has killed more security programmes than any attacker.
Give them things nobody else has
Champions got write access to the security tooling config for their own repos, so they could tune rules and thresholds themselves rather than filing a request with us. A private channel where the answer arrives in minutes. Early access to new tooling and a real vote on what we bought. A conference budget line and an explicit expectation that they use it.
The message underneath all of that is the recruiting strategy. This role gives you access and capability you cannot get any other way. Champions should be visibly better equipped than their peers. People should want the job, and wanting the job is the only recruitment mechanism that scales past the first cohort.
Rotate them on purpose
A one year term, then renew or hand off, with a deliberate two month overlap.
This prevents the one hero failure. It turns a champion leaving into a scheduled event instead of a crisis. And over time it spreads security knowledge far wider than a permanent role ever could. After three years you do not have twenty champions. You have twenty champions and forty former champions who still read a diff carefully out of habit, and that second number is the one that is quietly making your software better.
Rotation feels like it weakens the programme. It is the thing that lets it survive contact with reality.
Measure the right things
Not number of champions. Not training completion. Those measure activity, and activity is what dying programmes report right up until the week they are cancelled.
Time to triage on new findings went from eleven days to two, which is the clearest signal that real work is happening closer to the code. New services with a threat model at design time went from twenty percent to eighty five, almost entirely because champions ran them without us. Findings caught in code review rather than by a scanner rose steadily, and no amount of tooling spend buys you that.
And then the one that actually matters. Renewal rate. When people renew, the role is worth having. When they quietly do not, something upstream is broken and you have about one quarter to find it before the whole thing goes back to being a Slack channel with stickers in it.
The short version
Champions programmes fail because they ask engineers to do unfunded, uninteresting work for the benefit of somebody else's metrics, and then act betrayed when it does not stick.
They work when the time is funded in the sprint, the role carries real authority and real perks, the toil stays with the security team, and doing it is visibly good for the champion's career.
Fix the incentives and the security content is the easy part.
Skip the incentives and the best curriculum in the world will not save you. It will just be very well formatted, like all the other things we leave behind.
// Elusive Thoughts // written from the in-house chair, not the consultant one // securityhorror.blogspot.com
Figures are from one estate over roughly two years. Treat as direction, not decimals. Analysis and commentary are my own.
#AppSec #SecurityChampions #SecurityLeadership #DevSecOps #EngineeringCulture
