Building a defence function people don't quietly leave

There is a particular pattern that anyone who has been in cyber defence for long enough will recognise. A new security leader joins, hires aggressively, runs a year of high-energy delivery, and then — sometime in the second year — the team starts to leak. The best people go first, because they have the easiest time finding new jobs. By the third year, the function has effectively reset, the runbooks are out of date, and the new leader is repeating the cycle.

I have watched that loop happen, in one form or another, across more organisations than I would like to count. The pattern is not inevitable. But avoiding it requires deliberate work that does not feel like security work, and that is partly why it gets skipped.

The leading indicators

The metrics most security functions report on are lagging: incidents, mean time to respond, control coverage, audit findings. Those numbers matter to the audit committee, but they are not very useful for steering the function. By the time a lagging metric moves, the underlying problem is usually months old.

The metrics that actually steer well are leading indicators about the work itself. Time from a known control gap being raised to it being closed. Rate of detection-rule additions and retirements. Number of post-incident review actions completed within the sprint they were promised. Voluntary contributions from the team to upstream open-source projects, runbooks, or training. These are not vanity numbers. They are evidence that the function is operating at a steady rate, learning, and not silently degrading. When they slip, intervene early.

Burnout is an architectural problem

It is fashionable to treat burnout as a wellness issue — a yoga class, a meditation app, an extra day of leave per year. Those are nice. They do not address the underlying problem, which is architectural: the function is designed in a way that makes burnout the rational outcome of competent work.

The architectural levers that actually reduce burnout are unsexy. On-call rotations that genuinely rotate, not the same three people indefinitely. Toil reduction work that is funded as work, not as someone's nights and weekends. Detection backlog that is allowed to be paid down, rather than perpetually starved by feature work. Training time that is on the calendar, not aspirational. If those four things are in place, the wellness benefits are pleasant rather than load-bearing. If they are not, the wellness benefits are decorative.

The political work

A meaningful share of a security leader's time goes to translating across constituencies. Engineering leadership wants to ship; you want a control that slows shipping. Finance wants to flatten the budget; you want to fund work that does not produce a visible deliverable. Legal wants written policies; you want them to be technically buildable. Each of those tensions is healthy in moderation; each is corrosive if mismanaged.

I have come to think of this as the most important deliverable a security leader produces over time: a body of trust with peer leaders that lets you have hard conversations without them turning into political contests. That trust is built by being right enough of the time, by being precise about the costs and benefits of what you are asking for, and by being willing — sometimes — to not fight for a particular control because the political capital is better spent elsewhere this quarter.

Every security leader I respect has a small mental ledger of fights won, fights lost, fights deferred. The good ones spend the ledger deliberately.

Hiring slowly, rotating deliberately

Most security functions hire too fast at the start of a build-out and then refuse to acknowledge that the team needs deliberate rotation later. The hiring problem is well documented; the rotation problem is not.

The teams I have seen retain talent best are the ones that have explicit rotation paths. Three years on the detection desk, then a year on the architecture team, then a year on the IR retainer side, then back to detection or onwards to programme work. The path is not strict — not everyone wants to move every year — but the option is real. People stay in functions that offer growth more reliably than they stay in functions that offer good pay alone.

Leadership is where the multiplier lives

It is tempting, particularly for technical leaders who came up through detection or IR, to keep their hands on the keyboard. I am sympathetic — I do it too, on the projects I love. But the durable leverage at programme level is in the leadership work, not in the technical work. A leader who spends a quarter coaching their detection lead into being a better detection lead almost certainly produces more durable value than the same quarter spent personally writing detections.

The detection rules will be re-written by someone else next year. The capability of the lead they coached will compound for the rest of that lead's career.

The unglamorous final point

If the function you are leading is not one you would happily join, do not expect anyone else to. The audit of would I want this job? — asked honestly — is one of the more useful checks a leader can run on themselves quarterly. The answer is sometimes uncomfortable. It is also, in my experience, the cheapest steering signal available.