As a security leader, one of the most important parts of the job has never been the technology on its own. The technical work matters, obviously—but what really decides whether security succeeds or becomes theatre is the team behind it. Not the org chart, not the tooling stack, not the maturity model slides. The actual humans who show up, carry the pressure, make the judgement calls, and keep going when everyone else only notices security during a crisis.

We say it all the time: your cyber defences are only as strong as the people safeguarding them. It’s true, but it’s also a bit of a cop-out, because the unspoken bit is this: if you want a strong security function, you have to build the conditions for it. You have to shape the team, protect it from nonsense, and give it room to grow. That’s not fluffy leadership talk—it’s operational reality.

Start with what you’ve actually got

Before you can transform anything, you need to understand the team you’re standing on. That sounds obvious, but it’s the bit people rush. In new roles, especially, it’s tempting to show impact quickly by reorganising, renaming things, bringing in new processes. And sometimes that’s necessary. But if you don’t first map out skills, gaps, strengths, and the unspoken “how we really work”, you’ll just end up building a plan for a team that doesn’t exist.

When I assess a team, I treat it like a baseline—something you measure so you can improve it. Not an exam. Not a cull. If people think it’s a judgement exercise, you won’t get honesty, and without honesty, you’re building on sand.

What tends to unlock the most value is talking to individuals about what they actually enjoy and where they want to go. It’s not unusual to find someone sitting in GRC who is quietly brilliant at engineering, or someone doing operational work who has the instincts to be a very strong risk partner. Sometimes people are in the wrong lane simply because nobody ever asked.

Then there’s the difference between what people can do in theory and what happens under pressure. The fastest way to learn that isn’t another spreadsheet. It’s drills, tabletops, and realistic exercises where the team has to make decisions in messy conditions. Not because you want to catch them out, but because you want to see what breaks first: process, tooling, communication, confidence, or escalation.

Transformation isn’t a “big bang” job

Once you understand the current shape of the team, you can start the transformation. And transformation is always gradual if you want it to stick. It’s easy to announce a new operating model; it’s harder to make it real.

The foundations tend to be boring, and that’s precisely why they matter. Core skills—risk, incident response, security engineering fundamentals, architecture, basic threat thinking—these are what hold up the fancy stuff. It’s great to talk about the latest trends, but if the team is shaky on the basics, you’ll end up with a function that looks modern and collapses the moment something serious happens.

This is also where continuous learning stops being a poster on a wall and becomes a practical decision. Security is a fast-moving field, and complacency is how teams rot. The best teams I’ve worked with have learning baked into how they operate. Not as an after-hours hobby, but as something legitimate. People improve because it’s expected, supported, and normal.

Specialisation matters too. Broad knowledge keeps you functional, but depth is what makes you effective. When people are encouraged to go deep in specific areas—and you still keep enough cross-skilling so you’re not fragile—you get a team that can move quickly and handle complexity without flapping.

The other ingredient, which sounds soft until you’ve seen what happens without it, is collaboration. Cybersecurity is rarely solved by one person in a corner. Good security outcomes are social. They come from people sharing context early, asking for help without fear, and debating decisions properly rather than quietly working around each other.

Motivation is not a “perk”, it’s a control

A motivated team isn’t just happier. It performs better, makes fewer mistakes, and stays calmer when things go wrong. Motivation becomes an operational advantage.

The simplest lever is clarity. People do better work when they understand what the team is trying to achieve and why it matters. If the only message they get is “reduce risk” or “be more secure,” they’ll drift. If they can see how their work protects customer trust, keeps systems up, enables product delivery, or avoids regulatory pain, they’ll move with purpose.

Recognition also matters more than leaders often admit. Security work can be invisible by default. When you catch an issue before it becomes an incident, it looks like nothing happened. So celebrating impact—properly, in ways that are meaningful—helps people feel seen. That includes progression too, not just applause.

Empowerment is the next step. When people are trusted to make decisions within clear boundaries, things speed up and quality improves. It also builds accountability in a healthy way. Teams that are constantly second-guessed tend to stop taking ownership. They become ticket processors, not security professionals.

And then there’s the boring truth: leadership by example. If you want a team that learns, you have to learn. If you want a team that communicates well, you have to communicate well. If you want a team with high standards, you have to show those standards in your own work. People don’t follow slogans. They follow behaviours.

Yes, agile can work in security (if you use it sensibly)

Security teams often get told agile “doesn’t work here”. Sometimes that’s true for day-to-day operations. Incidents don’t care about your sprint planning. But for delivery—building capability, improving controls, shipping internal security products—agile can be brilliant.

I’ve seen agile delivery inside security functions work extremely well when it’s treated as a way to create focus and momentum, not as a theatre ritual. The real value is the iteration: small chunks of delivery, visible progress, feedback loops, and a steady cadence that keeps leadership engaged because they can actually see outcomes rather than being asked to believe in a long-term plan.

The best part, honestly, is that it gives the team permission to improve continuously. Lessons from one sprint shape the next. Visibility improves. And the team starts to build a rhythm that people outside security can understand and trust.

Going deeper: when specialism becomes necessary

As teams grow, you often reach a point where generalists alone don’t scale. You need depth, ownership, and domain focus. In one organisation I worked with, we deliberately shaped the function into specialist areas because the breadth of work was too wide for a single team to hold properly.

Endpoint protection needed a team that lived and breathed it. Identity and access management demanded a different kind of thinking—more governance, more engineering, more product discipline. Operations needed people who could handle the day-to-day reality of detection, response, monitoring, and the constant background noise of modern environments.

The change wasn’t just structural. It changed accountability. When a team owns a domain, they don’t just run tickets—they shape strategy, improve controls, and develop real expertise. It also makes it easier to explain value to senior leadership, because you can demonstrate capability growth and delivery in ways the business can recognise.

Recruiting: build for reality, not for a brochure

When you’re recruiting, it’s tempting to chase a checklist of certifications and tool experience. Those things can help, but the best hires often show up as something else entirely: curiosity, pragmatism, judgement, and the ability to collaborate under pressure.

A strong team needs a mix. People who can respond to incidents without panicking. People who can build and automate. People who can model risk without turning it into bureaucracy. People who can talk to engineers as peers and to leadership in business terms. And people who keep learning because they’re interested, not because they’ve been told to.

What matters most is building a team that can operate as a system. Not a collection of clever individuals pulling in different directions, but a group that shares context, trusts each other, and can flex when priorities change.

I’ll dive into more of these areas in future posts, because none of this is a one-and-done job. Building a great cybersecurity team is a continuous process. It requires honest assessment, deliberate shaping, and ongoing support. But done well, it gives you something better than “a security function”.

It gives you a team that can deliver, adapt, and hold the line when the pressure turns up—which, in security, it always does.