Player-Coach: Why I Still Do the Work

There's an unwritten rule in security that once you get promoted far enough, you stop doing the work. I've never bought it. I think senior security leaders should stay hands-on, and the ones who don't slowly lose the judgment that got them promoted in the first place.

I lead a team of senior security engineers. I also still run penetration tests and red team engagements, build attack trees, and sit in on threat modeling. Nobody's making me. I just think the job works better that way.

What I mean by hands-on

I don't mean being the best engineer on the team. If I'm trying to out-engineer people I hired because they're good, something's gone wrong, and it's probably me.

I also don't mean hovering over people's reports, or grabbing the fun engagement while the team gets stuck with triage. That's a good way to lose good people.

I mean carrying real work with a deadline and having my findings reviewed like everyone else's.

Why it matters

Credibility, first. Engineers figure out pretty fast whether you understand their system. If I can explain how I'd abuse their token exchange, or why an IAM policy is broader than they think, we skip the argument and get to the fix. It makes me a better interviewer and coach, too.

You've probably seen this pattern. Picture a design review for a new service-to-service auth flow. Someone working from a checklist asks whether the traffic is encrypted, gets a yes, and moves on. Someone who's tested flows like it recently asks who can mint the token, where it's validated, and what happens if it's replayed. Those questions tend to find real problems.

Judgment also goes stale. Something I'd have called critical a few years ago might be handled by the platform now, and something I'd have shrugged at might chain into a real problem. Regular hands-on work keeps my risk calls honest.

Then there's AI, which is changing what we secure and how we do the work faster than any vendor briefing can keep up with. I've argued that we're still testing the wrong thing with AI systems. I'm only comfortable saying that because I've spent time breaking them myself.

And executives. A lot of my job is helping leadership move fast with risk they actually understand. Boiling a technical problem down without distorting it is hard enough when you know the system well. I don't know how you do it from secondhand notes.

What it costs

This isn't free, and I don't always get the balance right.

Time is the big one. One-on-ones and executive asks don't stop because I'm halfway through a test. Paul Graham's essay on the maker's schedule and the manager's schedule explains why an hour of technical work squeezed between two meetings is usually wasted. I block real chunks of time and try not to give them up.

A few other things I watch for:

• Becoming the bottleneck. If my calendar's about to get ugly, I shouldn't own the piece everyone's waiting on.
• Hiding in the work. Testing is more fun than a hard career conversation, so if the team isn't getting direction, the test can wait.
• Ego. If I want in on something a teammate owns, I pair with them instead of taking it over.

Tell your team why you're doing this, so it doesn't read as distrust. And pick work that teaches you something or clears a blocker.

If you want to do this

If you're a leader who's drifted away from the work, start small. One threat model or one scoped test, done properly. You'll find out quickly what you've lost. Then get your own boss to treat it as part of your role, because if it only happens on nights and weekends, it won't last.

If you're a practitioner thinking about management, your hands-on time will shrink, but it doesn't have to go to zero. Before you take the job, ask whether practitioner work is expected, tolerated, or discouraged, and take the answer seriously.

I plan to keep doing the work as long as I'm leading people who do it. I haven't found a better way to stay good at either job.