Your squad's only threat modeling champion resigns four months in — how do you keep the practice alive?

## Why this question is really about design, not about the leaver Champion turnover is routine. People change squads, get promoted out of hands-on work, or leave; over a year, a programme of thirty champions will replace several. So the interesting question is not "how do you react" but "what did you build that makes a resignation survivable". A programme that is shaken by one departure was resting on one person's memory. Take a 400-engineer games studio with six central application-security staff and one champion per squad. Four months in, the champion on the in-game-currency squad resigns — the squad that owns virtual-goods purchases, balance transfers and the refund path, where the asset at risk is money and tradable in-game items rather than customer records. What the studio discovers is that the squad's model existed as slides from a workshop, that the reasoning for why a particular double-spend mitigation was rejected as too expensive lived only in the champion's head, and that the champion was the person the squad quietly asked before adding an integration. All three losses are different, and only one of them is a document. ## The three things that leave with a champion **1. The artifact.** Diagrams and threat lists are recoverable if they were written down somewhere durable. The fix is boring and effective: keep the model in the squad's repository next to the code it describes, in a format the squad already reviews, so it moves with the codebase and not with the author's account. **2. The reasoning.** Far more valuable and far more often lost. A model records what you decided; it rarely records what you *considered and rejected, and why*. The successor who does not know that a mitigation was already priced and refused will either re-litigate it or, worse, silently assume it is in place. Capture rejected options and accepted risks alongside the threats, with the reason and the person who accepted them. **3. The relationship.** The champion is the named contact between sessions — the person the squad asks before adding a new integration mid-quarter, which is exactly the trigger that ought to reopen the model. That contact is a name in the squad's head, not a document, and it does not transfer automatically. Announce the successor to the squad explicitly and let them be seen doing the role once before you assume the channel exists. ## The handover itself While the notice period is running, spend an hour or two per live model with the outgoing champion, the successor and someone from the centre. Walk each model: what the system is, where the boundaries were drawn and why, which threats are open, which mitigations were rejected, and what the squad has agreed to accept. Record the open items with owners and dates so the successor inherits a state rather than an archaeology project. If the champion has already left with no notice, the centre runs a fresh session instead — cheaper than reconstructing intent from an artifact nobody can explain. ## Choosing the successor The common mistake is inheritance by proximity: the successor is whoever picks up the leaver's ticket queue. Re-run the selection on the same criteria — standing inside the squad, interest, architectural context — because the squad's composition has changed and the right answer may be a different person entirely. Two other rules: - **The hours move with the role.** If the leaver had a protected fraction of sprint capacity, the successor gets the same. A title with no time is a vacancy that looks filled, which is worse than an open one because nobody escalates it. - **Cover the gap explicitly.** Between the resignation and the successor completing training, the central team owns that squad's modelling — including being the contact for a mid-quarter change. Say so out loud, with a name, or the squad simply stops modelling and nobody notices for a quarter. ## Designing against the next one - **Pair the role.** Two champions per squad, one experienced and one growing into it, makes departure a promotion rather than a hole — and gives you a successor who already has the context. - **Train in cohorts on a repeating schedule.** If the only training was a one-off at launch, every replacement is a bespoke project. A cohort every quarter or two means a successor is a few weeks from ready, not a few months. - **Keep an onboarding path for the role**, not just for the method: which models this squad owns, where they live, what is open, who the centre contact is. - **Expect a refresh rate.** Plan for a share of champions changing every year and staff the central team's coaching load accordingly, rather than treating each departure as an incident. ## What a strong answer sounds like Lead with the distinction between the artifact and the reasoning, name the between-sessions contact as a thing that must be re-established with the squad, and be explicit that the successor gets the same protected hours. Candidates who answer only "we document everything" have addressed the cheapest third of the loss.