“But you can code, right?”

Recently I was asked a question I’ve heard before:

“But you can code, right?”

It was delivered with a snarky smile, framed as a sort of credibility check.

But that’s almost always the wrong question. Managing a red team isn’t a test of personal technical output, it’s a leadership role centred on judgment, design, and risk translation.

Let’s clear this up early

I don’t code, but I can Google.

I can read commands, I can understand scripts, I can evaluate tooling, I can ask the right technical questions and know when an answer doesn’t make sense.

I am not an exploit developer nor do I pretend to be.

I came up through software delivery and cybersecurity project management, then into offensive security coordination before becoming a dedicated red team manager. I learned adversarial techniques by designing, governing, and translating them, not by performing them.

If that’s surprising, it probably says more about how we think about red team management than it does about my qualifications.

Tools have gotten better, we all use them. The hard part was never typing - it was knowing what question to ask and what to do with the answer.

The myth of the “hands-on or nothing” red team manager

Somewhere along the way red teaming inherited a flawed identity model:

If you're managing the team, you should also be able to personally do everything the team does.

By that logic engineering managers should still be writing production code daily, the SOC manager should still be on 24/7 shift and Directors should be responding to alerts at 2:00 AM.

That’s not how leadership works anywhere else, but offensive security teams seem oddly committed to the idea.

I’ve spent more time in red team engagements explaining why certain attacks were possible than proving I could execute them myself; whether that meant correcting a executive who believed hashing algorithms prevented Kerberoasting, or an identity leader who thought MFA enforcement prevented process injection.

The unacknowledged trade off

There’s also an uncomfortable reality we don’t talk about enough.

When you promote a strong, technical individual contributor (IC) into a management role, you often lose the very thing that made them exceptional in the first place.

You lose the time spent practicing and refining technical skill and the ability to stay close to the work without constant interruptions.

What you gain is not automatically management capability.

Strong ICs are not inherently prepared to support and grow other people’s careers, translate technical work into outcomes executives can act on, or navigate procurement, budgeting, and vendor risk.

Management skills are learned and matured overtime with practice.

Promoting someone because they were technically excellent doesn’t magically make them good at managing people, ambiguity, or running programs inside real organizations. It just means they excelled at a different job.

We rarely ask whether someone actually wants to manage people, only whether their technical performance suggested it was “time.”

What actually matters when you’re running a red team

Red team management means making decisions most individual contributors never have to make or even consider:

• What should be tested vs. what merely can be tested.
• How realistic is too realistic.
• How to simulate adversarial behaviour without causing real harm.
• How do we make sure findings lead to action instead of defensiveness.
• How do we avoid accidentally becoming the reason someone’s pager goes off.

None of those questions are answered by writing more or better payloads.

This is where many red team programs quietly fail. Not because the techniques weren't impressive but because the program wasn’t designed to evolve to the business' needs.

Just because you can, doesn’t mean you should

One of the most dangerous assumptions in red teaming is:

“If we didn’t exploit it, the risk isn’t real.”

That mindset leads to:

• Scope creep.
• Broken trust with operations.
• Findings that can’t be safely or meaningfully remediated.

A mature red team understands that:

• Evidence that drives change matters more than exploits that impress.
• We don’t chase “wow", we chase results.
• The most responsible decision is sometimes not to exploit.

Knowing when not to attack is as critical as knowing how and that judgment is a leadership skill, not a technical one.

Technical depth still matters (just not the way people think)

This isn't an argument to say red team managers shouldn't have technical expertise.

Red team managers must understand:

• Attack paths.
• Detection logic.
• Adversary tradecraft.
• Control coverage and gaps.

So, what does a red team manager actually do?

They translate technical risk into business relevant decisions, define why an attack matters and what it’s meant to prove. They support operators by setting clear objectives and making risk based decisions that the operators shouldn’t have to fight for alone.

A red team manager is the bridge between adversary behaviour and executive action.

What they don’t need to do is personally demonstrate every tactic or technique to prove they belong in the room.

If a red team manager role requires the manager to regularly pop shells to maintain credibility, it’s probably not a management role but an individual contributor role wearing a different hat.

Possibly a very expensive one.

Red teaming is a design discipline

The most effective red teams I’ve seen are not led by the most cert loaded engineer in the room.

They’re led by people who:

• Know when realism adds value and when it adds risk.
• Understand organizational constraints instead of ignoring them.
• Can say “no” as confidently as they say “yes”.
• Design programs that endure scrutiny from leadership, auditors, and regulators.

That kind of work doesn’t look exciting on a slide. It looks like fewer surprises -which is the entire point.

Final thought

So no, I don’t code.

But I design red team programs that produce credible insight, survive real world constraints, and actually drive change.

And in environments where the cost of getting it wrong is high, that tends to matter a lot more than who can kerberoast on demand.