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.
Every security team I've led had the same problem, and it took me way too long to see it.
We optimised for tech and ignored our people.
Burning 60-hour weeks to squeeze in a £2M security platform before year-end?
Emergency meetings, weekend deployments, whatever it took.
But finding 30 minutes for the team to discuss how we actually work together?
Somehow impossible.
We spend 90% of our time fixing 10% of the problem
It’s not really surprising that we over-index on the technical work. Most security leaders come up through a technical path.
You get rewarded for being great at the craft—then you’re handed a job where the craft is no longer the main thing.
No one tells you the skills that got you here won’t be the ones that get you through the next part. So you keep doing the work you’re good at, not the work the role requires.
This was me.
I got promoted because I was good at security work. Then spent two years failing at a job that had almost nothing to do with security work.
At no point did anyone say,
"Okay, now you need to think completely differently."
So I didn't.
I figured leading a team was just engineering with more meetings.
Same logic, same tools, just with people in the loop.
I was not a good leader.
At all.
I’d do this thing where I treated humans like machines:
Write a runbook detailed enough, and incidents will resolve themselves.
Buy a smart enough platform, and dashboards will light up green.
Send everyone to the right training, and collaboration will happen automatically.
I was genuinely surprised when none of this worked. But did I pause to figure out what was actually going on? Did I dig into the people side of team performance?
No.
I doubled down, threw another technical solution at the problem, and called that "leadership".
Team performance Is 90% human, 10% tech
But we spend 90% of our time on the 10%.
What I would do to improve team performance:
Replace the entire SIEM with another SIEM that does the same thing
Buy a new agile workflow system
Spend weeks automating a process that wasn't actually the bottleneck
What I wouldn’t do:
Ask why incidents escalated when someone noticed something weird hours earlier
Figure out why my brilliant engineers became terrible teammates
Admit that our "collaborative" teams barely talked to each other
I wanted to believe our issues were technical because technical problems are easily solvable.
You can buy those. You can implement those by Q4. You can show those on a dashboard.
There's a vendor to blame if it doesn't work.
Human problems?
Those are messy.
Uncomfortable.
Hard to quantify.
And 100% my fault when they failed.
What actually moved the needle for my teams
The eight principles in this series transformed my teams from collections of smart individuals into actual teams.
It took me way too long to find them, mostly because in security we don't talk about this side of the job.
There’s no NIST framework for creating vulnerability in your team.
No CISSP domain for psychological safety.
No vendor sliding into your Inbox with a AI-generated pitch about how they’ve boosted “recognition metrics” at three other Fortune 500s.
They’re the exact type of thing I avoided for years because it felt too "soft" for serious security work.
But they ended up making the biggest difference for my teams.
Here's how we'll break them down:
Part 1 – The Cultural Foundations (this post): Psychological safety, deliberate vulnerability, productive conflict, and meaningful recognition.
Part 2 – The Systems for Sustainability (next): Clear priorities, competency matrices, structured onboarding, and consistent 1-on-1s.
You don't need budget for any of this.
No new tools, no frameworks to implement. Just you, your team, and the way you show up as a leader.
If that sounds like leadership-blogger energy, fair. I’d have rolled my eyes too.
But there's research behind it. Google's Project Aristotle spent three years studying hundreds of high performing teams trying to reverse-engineer what makes them work.
The answer wasn't technical skills or seniority or even who was on the team.
It was this:
Principle 1: True Psychological Safety
Ask dumb questions • admit real mistakes • pitch wild ideas
"You ask too many questions."
My first security manager dropped this on me in a performance review. It should have been a compliment. Instead, it was a warning: “Leave the decisions to the seniors.”
Message received: Stop asking. Stop proposing. Stop thinking.
Every unsafe security team does this.
They say they want curious people. Check the job description. "Intellectual curiosity" is right there between "team player" and "strong communication skills.”
Then you ask why the team's doing something a certain way.
Eyes roll. “You don't know how unique this organisation is.” “You'd need to understand the history here.”
No one explains the history. No one answers the question.
Psychologically unsafe team red flags:
Write "innovative thinking required" in job postings → shut down new ideas with "that's not how we do it"
Host brainstorming sessions → where only senior voices matter
Create "blameless" post-mortems → then talk about who really screwed up
Say "there are no stupid questions" → then smirk when someone asks one
It's easy to dismiss psychological safety as corporate fluff. The kind of thing that shows up on a slide deck somewhere between "we're a family here" and "our agile transformation.”
Trust falls. Participation trophies. “Woo-woo”.
It’s not.
It's about creating a high-performance environment where anyone can ask questions, own mistakes quickly, and pitch half-baked ideas that might be brilliant (or terrible).
Why this matters: Security problems don't wait for the right time or the right person. When your people hide their questions, you get blind spots. When they hide their mistakes, you get repeated failures. When they hide their ideas, you get mediocre solutions.
The Playbook:
For Leaders: You Go First
Build Question Culture: Make "asks clarifying questions" a performance review strength, not a weakness. Create a #no-stupid-questions channel and be the first to use it. Thank questioners publicly: "That question just saved us from a future incident.”
Broadcast Your Own Mistakes: "Here's where I went wrong, here's what I learned, and here's how I'll adjust." Normalise imperfection and reframe errors as data.
Fix Systems, Not People: Replace "Who did this?" and "They should have known." with "What made this possible?" and "Where did our process break?”
Respond with Curiosity, Not Criticism: Default to responses that build safety: "Tell me more about that," "What made you think of this?" "Let's test that idea."
For ICs: Build Safety Without a Title
Be the Teammate You Needed: When someone asks about basic TLS, don't eye-roll. Help them level up.
Amplify Quiet Voices: Notice the junior who mumbled something smart? Say it louder: "Chris just made a great point about the auth flow. Chris, can you expand on that?"
Ask ‘Obvious’ Questions: “Why do we rotate keys every 90 days instead of 60?" Even if you know the answer, someone else doesn't. Your question gives them cover.
Have Their Back: Junior getting grilled for not knowing something? "Actually, I was confused about that too.” Someone admits breaking prod? "We've all been there, what matters is fixing it." Use your reputation to protect those building theirs.
Principle 2: Deliberate Vulnerability
Ask for help • teach what you know • team wins over personal glory
Security attracts some of the smartest people in tech.
And smart people hate looking dumb.
So we build these elaborate ways to never show vulnerability:
The architect who hoards knowledge for job security
The manager who takes credit in every presentation
The senior who'd rather burn three days stuck than risk asking for help
The team lead who says "I've got this" while quietly drowning in work
The cost?
Every hoarded solution is work duplicated. Every stolen credit is trust destroyed. Every three-day struggle that could've been a three-minute conversation is momentum lost.
High-performing teams sound completely different:
"Kubernetes RBAC is destroying me, I need help"
“Your approach is cleaner than mine, show me how you did that.”
"Can someone explain this CVE to me?"
“You present it to leadership, you did the hard work”
Notice what's missing? No ego. No posturing. Just people focused on solving the problem.
Why this matters: Energy spent looking smart is energy not spent being smart. When your team stops wasting time on appearances or office politics it can focus on the work that matters.
The Playbook:
For Leaders: Model Humility from the Top
Ask for Help Publicly: "I don't understand this Docker setup. Who can walk me through it?" Say it in stand-up. Post it in chat. When you show vulnerability, you give permission for others to do the same.
Protect Those Who Risk It: Someone admits they're lost? That's courage, not weakness. Respond with resources, shadowing on the next incident, whatever they need. Never "You should know this by now.”
Kill the Hero Complex: Assign high-visibility work to others and resist the urge to take over. Your job is building leaders, not just being one.
Redirect Credit Relentlessly: When praised for a success, immediately redirect it: "The team’s input made this possible.", “The engineers built it, I just presented it”
For ICs: Build Trust Sideways
Be Human: Share when you're stuck, tired, or out of your depth. “Sorry if I'm off today, my kid is sick” or “This is my first time leading a project this big.” Being authentic beats being perfect.
Practice Honest Recognition: "Your solution is cleaner than what I've been doing for years. Can you teach me?"
Stand Up When It Counts: Someone taking heat for a decision you agreed with? Speak up: "We made that call together." Teams remember who had their back and who let them burn.
Default to Positive Intent: That blunt chat message? They're in the middle of an incident, not attacking you. That stalled PR? They're being thorough, not incompetent.
Principle 3: A Culture of Challenge
Question every assumption • challenge every decision • embrace productive confrontation
Teams that ship excellent security look dysfunctional from the outside:
Engineers dismantling each other's code in reviews
Architects defending decisions under fire
Juniors asking questions that make seniors squirm
Heated discussions that go way beyond the scheduled time
Most teams shut down this type of challenge immediately.
Someone pushes back on a design, and suddenly it's "let's take this offline." Someone questions a decision, and it's "we need to stay aligned." Someone points out a problem, and it's "let's focus on solutions.”
Translation: Team conflict is scarier than data breaches.
Here’s my take on this: The absence of challenge is not harmony, it's apathy.
If your team isn't constantly arguing over the best way to secure something, you're already falling short.
Why this matters: Your attackers aren't holding back to preserve team morale. They're finding every flaw in your logic, every gap in your assumptions. The best security solutions come from ideas that have already survived interrogation, not ideas that avoided it.
The Playbook:
For Leaders: Set the Fight Rules
Make Challenge Mandatory: Start meetings with: “Who's going to poke holes in this?” Assign devil's advocates. Recognise people who ask the hard questions. Make challenging ideas part of the job.
Protect The Argument: Don't shut down a heated discussion prematurely because it feels uncomfortable. Friction means your team cares enough to fight for the best outcome. Keep it focused on the problem, but let it breathe.
Questions, Not Instruction: Instead of dictating solutions, ask questions that force critical thinking. "What breaks this?" "How would an attacker bypass it?” "How can we achieve the same protection with half the friction?” Your questions should make people defend their thinking, not just their conclusions.
For ICs: Be the Sceptic
Challenge With Substance: "This seems wrong" isn't helpful. "This breaks if an attacker does X" is. Bring data, examples, and analogies.
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.
Play Devil's Advocate: Especially when everyone agrees. "What if our assumption about X is wrong?" Consensus without stress-testing leads to groupthink.
Principle 4: Meaningful Recognition
Notice the work • be specific about impact • make praise a habit
Monday stand-ups at every company I’ve ever worked at: we spend ten minutes dissecting the latest Hacker News vulnerability.
Zero minutes recognising the engineer who killed their weekend fixing the scan pipelines.
This is how we lose good people.
They didn't need a promotion or a bigger salary. They needed five seconds of "I saw what you did there, and it mattered.”
Recognition is the single biggest lever you can pull for team performance.
And it costs you nothing.
When you tell someone, "That fix you pushed prevented a breach," you're feeding three psychological needs:
Competence: "I'm good at this"
Relatedness: "My work matters"
Autonomy: "I can influence outcomes"
Hit all three consistently and watch your people push harder than any bonus could inspire.
Why this matters: Security's best work is invisible: breaches that didn't happen, attacks that got blocked, disasters prevented. No headlines. No hero moments. Without deliberate recognition, teams burn out wondering if anyone even notices.
The Playbook:
For Leaders: Surface Great Work
Make It a Ritual: Start every weekly meeting with 5 minutes of recognition: "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?” Most meetings open with problems. Yours opens with proof that their work matters.
Be Specific and Link to Impact: Vague praise (“Good job!”) falls flat. Make it genuine and specific: "Your custom detection rule caught that credential stuffing attempt and saved us from a breach" Formula: What they did + What it prevented/enabled. Takes 10 seconds more. Makes 100x more impact.
Be Their Publicity Agent: Escalate their wins up the chain. "FYI - Josh's automation just cut our scan time from 3 hours to 30 minutes." Name names. Be specific. Your manager should know your team members by their wins, not just from org charts. This costs nothing and changes careers.
For ICs: Lift Others Up
Shout Outs: See excellence? Call it out. "That PR review where you caught the SQL injection—clutch." Post it in chat. Say it in meetings. Make it normal to acknowledge good work. The best teams don't wait for managers to notice wins.
Credit Others First: In every project summary, stand-up update, or success story, lead with what others contributed. "Kim's threat model shaped our whole approach" beats "I led the security review". Takes zero effort. Makes people want to work with you again.
Recognise Up, Not Just Sideways: Your manager did something right? Say it. "Your feedback on my proposal made it way stronger." Managers are people too and they're usually starved for genuine feedback. Be the person who provides it.
You've Built the Foundation. Now What?
Four principles. Zero technology.
Just humans treating humans like humans.
If this feels too simple, ask yourself: when's the last time a security failure was actually about the technology?
The answer is probably buried under layers of communication breakdowns, unclear expectations, and teams too afraid to speak up.
These principles transform culture. Your team will start asking real questions, admitting what they don't know, challenging weak ideas and feeling valued.
But it only sticks when your human systems support it.
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 create leaders
For now, try one thing this week.
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.
Then go deeper in Part 2 →