Which Threat Modeling Manifesto anti-pattern does one engineer authoring every team's model create, and how do you break it?
answer
- One of the Manifesto's four anti-patterns
- Skill is not an innate mindset
- The expert becomes the queue
- Adding a second expert changes nothing structural
- Measure models the expert did not write
basics
~20 sThe Hero Threat Modeler anti-pattern. The Manifesto holds that threat modeling needs no innate gift, so the fix is moving the specialist from authoring models to reviewing what teams author, not hiring a second hero.
solid answer
~50 sThat is the Hero Threat Modeler anti-pattern: the practice depends on one person's supposed special mindset, and so its throughput is that person's calendar. Take a scooter-sharing company where one staff security engineer personally writes every model for forty teams. Models arrive late, the queue becomes the practice, and the teams stop reasoning about their own designs — so the person who could actually spot that an authenticated rider can chain free unlocks against fleet availability and revenue is the one not thinking about it. The Manifesto's claim is that threat modeling does not depend on innate ability; everyone can and should do it. Breaking it means the teams author and own their models while the specialist reviews, questions and unblocks — and measuring the practice by how many models the specialist did *not* write.
go deeper
Know the name and the claim behind it: threat modeling is a learnable practice, not a gift. Do not describe yourself as unqualified to model your own feature.
Be ready to explain why a single author is a coverage problem and not just a throughput problem — you understand your own state machine better than a visiting reviewer does.
Expect to describe the inversion in practice: your team authors, the specialist reviews, and the rough first attempt ships anyway. Show you can defend a lower-quality model that the team owns.
Own the metric and the dip. You are expected to say what you would stop counting, what you would count instead, and how you keep leadership from recreating the hero by rewarding whoever unblocks the most teams.
### The anti-pattern as the Manifesto states it **Hero Threat Modeler** is one of the four anti-patterns the Threat Modeling Manifesto names as hindering the practice, alongside Admiration for the Problem, Tendency to Overfocus and Perfect Representation. Its content is a claim about the skill itself: threat modeling does not depend on one person's innate ability or unique mindset — everyone can and should do it. The anti-pattern is not `having an expert`. It is a practice whose existence is contingent on that expert. ### What it looks like from the outside A scooter-sharing company has one staff security engineer and forty delivery teams. She is good, so she writes the models. Within a year: - **She is the queue.** Design work waits on her calendar, and a model that arrives after the design is built is a report, not a design input. - **Teams stop reasoning about their own systems.** They have learned that thinking about threats is somebody else's job with a request form attached. - **The models are hers, not theirs.** An engineer who did not build the argument does not defend it in the sprint where the fix costs something. - **Concentration risk.** The whole capability leaves with one resignation. And the technical cost is specific, not abstract. The rider-facing unlock flow is one that only the team who built it truly understands: which state transitions are idempotent, what happens when a ride ends twice, which balance check runs client-side. An authenticated rider chaining free unlocks costs the company money and takes scooters out of the fleet — a threat about business-logic sequence that a visiting expert with a diagram is far less likely to see than the four people who wrote the state machine. This is why the hero problem degrades *coverage*, not just throughput. ### Why more heroes is not the fix The reflex answer is headcount: hire a second specialist and halve the queue. That doubles the queue's service rate and changes nothing structural, because the bottleneck is not capacity — it is that models are authored **outside the team that owns the design**. Two heroes produce two streams of late, unowned artifacts. The Manifesto's framing points at the other lever: if the skill is not innate, then the constraint is not talent supply. ### What breaking it actually involves Invert who holds the pen. The teams author their own model; the specialist reads it and asks the questions the team did not think to ask. Three things follow from that inversion: 1. **The specialist's output changes shape.** Her deliverable stops being models and becomes other people's models getting better. She is now spending her time on the designs where her judgment moves the answer most. 2. **The metric changes.** Counting models produced rewards the hero pattern directly. Counting models the specialist did not write, or teams that produced a model without her present, measures the thing you actually want. 3. **Rough beats absent.** The first models the teams write will be worse than hers. That is the trade, and the Manifesto is explicit about which side it takes: a rougher model the team authored, believes and can defend beats a better artifact nobody owns. It also feeds the value pair `doing threat modeling over talking about it`. ### The trap in the pushback The hero's models genuinely *are* better, and that is the argument you will be handed for keeping the arrangement. Answer it on outcomes rather than artifact quality: what fraction of findings turned into a design change, and how many were argued for by someone other than the security engineer. A programme where every finding needs its author present to survive contact with a sprint plan has a quality problem that better documents do not fix. ### At principal level The judgment call is what you accept during the transition. Model quality dips, some threats will be missed that the hero would have caught, and the security engineer's personal output — the thing that got her promoted — falls to near zero on paper. If you cannot defend that dip to your own leadership with a metric that captures the new value, the organisation will quietly recreate the hero, usually within two quarters and usually by praising the person who unblocked the most teams.
- Why doesn't hiring a second security engineer fix it?Because the bottleneck is structural, not capacity. Two specialists double the service rate of a queue whose real defect is that models are authored outside the team that owns the design — so they still arrive late, still are not defended by anyone in the sprint, and still leave the team unable to reason about its own system. You have bought two streams of unowned artifacts.
- The hero's models are genuinely better than what the teams produce — isn't that an argument to keep her writing them?Judge on outcomes, not artifact quality. Ask what fraction of findings became a design change and how many were argued for by someone other than her. A rougher model the team wrote, believes and will defend when the fix costs a sprint beats a polished one nobody owns. During the transition quality dips; that dip is the price and it is worth naming out loud.
- How would you recognise the hero anti-pattern from outside the team?Look at authorship and voice. One name appears on every model; threats are closed by that person; engineers cannot explain their own trust boundaries or where their data leaves their control; and findings die when she is on holiday. A practice whose output stops when one calendar fills is not a practice.
saying these in an interview costs you the question
- Says some people just have the security mindset and others do not
- Proposes more specialist headcount as the primary fix
- Measures the practice by the number of models the expert produced
- Treats the expert's superior artifact as proof the programme works
- Blames the bottleneck on tooling rather than on who holds the pen