10 Years Leading Security Teams: Performance Is 90% Human, 10% Tech (Part 1)
The secret to elite infosec teams isn't your tech stack, it's your people.
The thing that made the biggest difference to my security teams had nothing to do with security.
It was changing the way people interacted with each other. Whether they asked questions. Owned mistakes. Pushed back on bad ideas. Whether everyone felt like the work they did actually mattered.
If you lead a security team, this probably sounds like the kind of thought leadership that wins LinkedIn Top Voice awards, not useful security advice. Past me would've felt the same.
"Team culture is not real work."
I was a technical person running a technical team. We had real problems to solve, and those problems had technical solutions.
Except they mostly didn't. Two years in, I realised I wasn't actually leading anyone. I was just doing my old job with more meetings and an org chart I was technically responsible for. I thought I was doing fine because the technology kept improving. The team didn't.
Truth is, I had no idea what I was doing. Nobody teaches us the leadership part on the way up. The conferences, certs, and training we all stack up cover every corner of the tech. Not one covers how to actually run a team. The technical side has frameworks for everything. The people side, we figure out on our own.
The principles in this series are what I eventually figured out. Eight things I completely avoided at first because they felt too soft for serious security work. I was wrong about that. They made more difference to my teams than any tool or process I ever implemented.
We'll cover them in two parts:
Part 1 (this post) is the cultural stuff: psychological safety, vulnerability, productive conflict, and recognition.
Part 2 is the systems that hold it together: clear priorities, competency matrices, structured onboarding, and consistent 1-on-1s.
There's actually a decent amount of research on this too. Google's Project Aristotle studied hundreds of teams over three years trying to work out what actually made them effective. It wasn't technical ability, budget, or seniority of the team. It was psychological safety. That's where we'll start.
Principle 01Psychological Safety
"You ask so many questions."
My first security manager dropped this on me in a performance review. At first I thought it was a compliment, but he meant it as a warning: “Leave the decisions to the seniors.”
Message received. I learnt real quick to nod along in meetings and bury my questions.
Years later, when someone put a name to what happened in that review, I wrote it off. Psychological safety had big corpo energy. The kind of thing you'd find in a culture deck next to "we're a family here."
But it's not that. It's just three questions you can answer about your own team: Can people ask questions without feeling stupid? Admit mistakes without getting punished? Float half-baked ideas that might be brilliant (or might be terrible)?
There's a cost when those answers are no that's hard to measure because it's made up of things that don't happen. You don't notice the questions people swallow or the ideas that never make it past someone's own head. You just notice that the same problems keep finding you.
You have to go first.
Share your mistakes out loud. Not as a performance, just "here's where I went wrong and here's what I learnt." That gives everyone else permission to do the same.
If "asks too many questions" shows up as a negative in someone's review, that's a problem. Make sure that questions are a strength, not a weakness.
Thank people who ask things publicly. Even a quick "good question, I hadn't thought about that" makes it safer for the next person to ask.
When something goes wrong, watch your language. "Who did this?" finds someone to blame. "What made this possible?" and "where did our process break?" finds the gap that let it happen.
"Tell me more about that," "what made you think of this?" and "let's test that idea." Defaulting to curiosity costs nothing and builds safety.
Principle 02Deliberate Vulnerability
I once spent five hours trying to find the answer to something a junior engineer had figured out in ten minutes. I knew he knew. He knew I knew he knew. But asking him directly? That would mean admitting I didn't understand something a junior had already solved.
So I burned a morning protecting my ego instead.
A bit of competition is good for your team, but it can show up in unhealthy ways. Architects that hoard knowledge, credit stealing managers, and that one engineer who's clearly drowning but won't ask for help. Multiply that across a team and you get a culture that spends hours protecting egos instead of solving problems.
The best teams I've worked with figured out how to make vulnerability a goal, not a weakness. Someone says "I don't actually know how this works" and nobody blinks. Nobody is keeping score. It's not the absence of ego, it's just a team that decided the work matters more.
Ego is the most expensive thing on your team. Lead without it.
Ask for help out loud. "I don't understand this Docker setup, who can walk me through it?" Say it in stand-up, post it in chat. It's not the help you get that matters, it's the permission you give everyone else to ask next time.
When someone admits they're lost, that's courage, not weakness. Respond with resources, shadowing, whatever they need. Never "you should know this by now."
If high-visibility work keeps landing on your desk, give it away. Resist the urge to take it back when it gets hard. Your job is building leaders, not being the only one in the room.
Be human. "Sorry if I'm off today, my kid is sick." "This is my first time with GCP so I'll be leaning on you lot." People want to work with someone real, not someone performing perfection.
When praise lands on you, push it back out. "Kim's threat model shaped the whole approach." "The engineers built it, I just presented it." Name names, especially in front of your own manager.
Principle 03A Culture of Challenge
Every leader says they want a team that challenges each other. In reality, almost none of them have one. Someone pushes back hard in a meeting and you jump in before it escalates, smooth it over, and move things on. It feels like you're keeping the team aligned. What you're actually teaching them is: team conflict is scarier than data breaches.
Resist that urge and you’ll create space for something different. Engineers tearing apart each other's code, juniors telling senior architects they're wrong to their face, meetings that blow way past their time slot because nobody wants to back down.
From outside this looks like dysfunction. Up close it's trust. Everyone in the room is fighting for the best outcome, not each other.
I realise this goes against most leadership advice, but security isn't like most jobs. Your attackers aren't holding back to preserve team morale. They're looking for any flaw you didn't push back on hard enough.
Your best security decisions will be the ones that already survived interrogation, not the ones that avoided it.
Let them fight.
Build challenge into meetings yourself. Open design reviews with "who's going to poke holes in this?" Assign a devil's advocate before you start. Challenge should feel like part of the job, not a brave move.
When a discussion gets heated, that's the moment to lean in, not shut it down. Friction means your team cares enough to fight for the best outcome. Keep the argument focused on the problem, but let it breathe.
Treat scrutiny as debugging. When someone attacks your idea, they're running QA on your thinking. Every flaw they find now is one less failure later. Take notes, not offence.
If you catch yourself dictating solutions, switch to questions. "What breaks this?" "How would an attacker bypass it?" "How can we achieve the same protection with half the friction?" Make people defend their thinking, not just their conclusions.
Principle 04Meaningful Recognition
Ask anyone outside infosec what we do and you'll get some version of "the department of no." It's a thankless job. Sales closes a deal and the whole company celebrates. Security stops a breach and nobody hears about it. We don't get hero moments, and if nobody on the inside names those wins either, an entire team can spend years doing excellent work, quietly wondering if any of it even matters.
Done well, recognition does more work than you'd think. Tell someone "that fix you pushed prevented a future incident" and you're landing three psychological needs at once. I'm good at this. My work matters. I can actually shape what happens here. Competence, relatedness, autonomy. Hit all three consistently and your people will push harder than any bonus could inspire.
If you don't say it, they won't know.
Most meetings open with problems. Open yours with proof that their work matters. "Shoutout before we start, Matt tuned out 200 false positives last week. Our analysts can actually focus now. Who else has a win to call out?" Five minutes at the top of the meeting will lift the room.
"Good job" evaporates the second you say it. "Your detection rule caught a credential stuffing attempt this morning. That was a breach we didn't have because of you." That's the version people remember. Be specific about what they did and tie it to the impact they had.
Your manager should know your team by their wins, not just by the names on the org chart. Your job is being their publicity agent. "FYI, Josh's automation just cut our scan time from 3 hours to 30 minutes" takes ten seconds to type and shapes how they're seen for the next six months.
In any summary or project update, lead with what someone else contributed. "Sean caught a gap in design review that would've given developers direct access to the PCI environment" beats "I led the security review" every time.
Your manager did something right? Say it. "Your feedback on my proposal made it way stronger." Senior managers are people too and they're usually starved for genuine feedback. Be the one who provides it.
ConclusionIt's the team, not the tools
A decade in, this is what I keep coming back to. The security teams that actually hold up aren't the ones with a perfect tech stack. They're the ones that get the human side right.
Behind every incident, somewhere in the chain there was a question nobody asked, a mistake nobody admitted, an idea nobody challenged, or a person nobody thanked.
No tool will ever close those gaps. That's the leadership part.
Culture is only half the work though. The other half is the systems that hold it in place.
Part 2 builds those systems:
One clear goal that makes decisions obvious
Career paths that keep your best people
Onboarding that reinforces culture from day one
1-to-1s that build leaders
For now, try one thing this week: Thank the next person who asks a "dumb" question in a meeting. Admit what you're stuck on in tomorrow's stand-up. Send one specific recognition email. Or designate someone to tear apart your next decision.