For leaders who have the budget for a team and want it to be a good one

Building a security team that can do the work, not just pass the interview

I've hired a lot of security people, and I've been wrong often enough to have changed how I do it. The résumé with the most acronyms rarely belonged to the person who could find the intrusion. The quiet candidate who'd spent years fixing broken systems usually could. Building a team that performs starts with defining the work, then hiring for the demonstrated ability to do it, then leading in a way that makes competent people want to stay. None of those steps is complicated. All of them get skipped.

Define the work before the roles

Most job descriptions are a drawer of acronyms emptied onto a page. Start instead with what the team has to be able to do: investigate an alert to a conclusion, write a detection and prove it fires, recover a system, explain a risk to a business owner, run a bridge at 2 a.m. NIST's workforce framework gives a vocabulary of tasks, knowledge, and skills for exactly this, and I use it as a checklist, not a template. Once the work is listed, the roles fall out of it, and so does the realistic headcount.

Hire for what people can do

A certificate tells you someone can recognise the right answer on a screen. A short, realistic exercise tells you whether they can find it when the answer isn't in the options. I run candidates through bounded, job-relevant scenarios with consistent scoring, and I weight those over credentials. I've written about why in the certification industry's competence problem. It takes a little longer per candidate and saves a year per bad hire.

Structure for coverage, not org-chart symmetry

Detection, response, engineering, and governance need different people and different measures. Small teams need generalists with one deep specialty each; larger ones need specialists with enough overlap that nobody is a single point of failure. The structure should answer two questions: who's on when something happens, and who knows the thing only one person knows. If either answer is "we'd have to call Dave," the structure isn't done.

Keep the ones worth keeping

Security people leave for three reasons: they're not learning, they're not trusted, or they're blamed for the things they raised. A team I lead has a visible path for growth, authority matched to responsibility, and a rule that raising a problem is rewarded and sitting on one is the thing that gets you in trouble. Pay matters, but it's rarely the reason the good ones go.

Where this comes from

Thirty years of leading security teams, in organisations from startups to governments, plus decades building curriculum and assessing competence. Most of the detail is under NDA. What I can say here, I do.

What I've written on this.

Read these before we talk, if you like. They're the long version of the argument.

Related work.

Other ways I'm engaged on the same problems.

Discuss an executive role.

Tell me about the role, the organisation, and what the first year has to deliver. I'll say quickly whether it's a fit.

Much of what I've done can't be described in public, and I've had an intimate relationship with NDAs most of my adult life. What I can say here, I do; the rest we talk about in confidence.

  • CISOs and directors standing up or rebuilding a security team.
  • Organisations that keep hiring certified people and keep having the same problems.
  • Leaders who want help designing roles, assessments, and the structure before the next hire.

Everything I do, in twelve places.