What makes an engineer the right pick as a squad's threat modeling champion?

## What the role is A security champion is an engineer **inside** a delivery squad who carries the threat modeling practice locally. Concretely, they make sure a model gets started when the squad changes something structural, they hold the pen (or make sure someone credible does), and they are the person teammates ask a security design question before anyone escalates to a central team. They are not a security engineer with a different reporting line, and they are not an approver — they do not sign off their own squad's work. The role exists for a headcount reason. A central application-security team of a handful of people cannot sit in every design conversation across dozens of squads, and a practice that only happens when a central reviewer is in the room stops happening the moment the reviewer is double-booked. Champions move the practice from *scarce specialist attendance* to *something the squad can do on its own*, with the centre keeping the method and the hard cases. ## The criteria that actually predict success **1. Influence inside the squad.** The champion's output has to change what gets built. If the squad already routes design arguments through this person, the model becomes an input to the design; if not, it becomes a document produced after the design is settled. You cannot delegate credibility, so you have to select for it. **2. Genuine interest.** Someone who wants to learn the method will read past the training, ask the centre awkward questions and keep going when a session runs badly. A draftee produces the minimum artifact that closes the task. **3. Enough architectural context.** The champion needs to know where their system's data actually flows and which components sit on the other side of a trust boundary. An engineer who has only worked inside one service will draw a diagram that stops at the service edge, which is exactly where the interesting threats begin. **4. Protected time — last as a criterion, first as a failure cause.** See below. ## The selection anti-pattern Consider a bank that asked each squad manager to nominate a champion. Every manager, reasonably, volunteered the engineer with the most slack in their sprint — the newest joiner, or the person between projects. Within two quarters the models existed and nobody argued with them, which sounds like success and is not: in design review the architects treated the model as a compliance artifact produced by someone who does not set the squad's technical direction, and it changed no decisions. The programme was measuring the wrong thing, because "a model exists" is cheap and "the design changed because of the model" is the point. The fix is to make the ask explicit to managers: name the person whose technical judgment this squad follows, not the person whose calendar is emptiest. That is a costlier nomination, and management has to be told it is the price. ## Time allowance is the binding constraint Enthusiasm does not survive contact with a full delivery load. A satellite-imagery company appointed a single champion on a squad handling customer targeting lists and imagery derived from them, gave them a training course, and allocated no hours. The champion modelled the first design on their own time, then stopped — not from disinterest, but because every hour spent modelling visibly cost the squad's committed sprint work and the champion was the one who had to explain the miss. Make the allowance concrete and visible: a named fraction of sprint capacity (a day a fortnight is a common shape), reserved the way on-call or interview load is reserved, and reflected in what the squad commits to. If a manager will not protect it, the honest reading is that the squad is not doing threat modeling and the centre should plan accordingly rather than pretend. ## Practical shaping of the pick - **One per squad is the norm, two is safer.** A single champion is a single point of failure for both holidays and attrition; pairing a lead with a second, less-experienced engineer also builds the successor. - **Volunteering plus vetting.** Open calls surface interest, which is genuinely useful, but the centre should still confirm the candidate has the standing and the context — otherwise you get self-selection by curiosity alone. - **Give the role a boundary.** Champions run routine models and raise the ones above a defined risk line; they do not become the squad's unpaid security review function for everything from dependency alerts to production access requests. A role with no edges is the second-fastest way to lose a champion. ## How to answer in an interview Name the three criteria in priority order, then say what you would refuse: you would not accept a nomination based on availability, and you would not accept the role without hours attached. If you have run this, cite the moment you found out a model was being produced and ignored — recognising that failure is the mark of someone who has actually operated the programme rather than designed it on a slide.