The Player-Coach Model: Why I Stay 40% Hands-On

The views expressed here are my own and do not represent those of any current or former employer.

There’s this moment that happens to every senior engineer eventually. You look at your calendar for the week and realize: it’s all meetings. Strategy reviews, stakeholder alignments, planning sessions, one-on-ones. Somewhere between the promotion and the present, you stopped writing code. And the worst part? You didn’t notice it happening.

I noticed. And I decided to fight it.

About 40% of my time stays hands-on. Code reviews, design reviews, writing Terraform modules, debugging production issues. The other 60% is strategy, mentorship, and cross-functional work. Some people hear this and think it’s a failure to delegate. It’s not. It’s the most deliberate choice I’ve made in my career.

The Credibility Tax

Let me be blunt about something. When a senior engineer who hasn’t touched the codebase in six months tells the team to adopt a new architecture pattern, everyone nods politely and then goes back to doing what they were doing.

When someone who reviewed your PR last week, who was in the Slack channel at 2am during the last incident, who has actually wrestled with the same janky Terraform module you’re stuck on… when that person suggests a new approach, it lands differently. Not because they have more authority. Because they have more context.

That’s the credibility tax. You either pay it by staying in the work, or you spend your influence capital on every recommendation and wonder why adoption is slow.

But credibility is just the surface-level argument. The deeper reason is that staying hands-on keeps your technical judgment calibrated. I’ve seen architecture decisions made by people who haven’t touched production in two years. They tend to underestimate complexity and overestimate how cleanly their diagrams will map to reality. They design for the whiteboard, not for the 3am page.

When you’re reviewing code, pairing on a tricky module, or debugging a networking issue while everyone else is asleep, you build an intuition for what’s actually hard versus what just looks hard on a slide deck. That intuition is irreplaceable, and it atrophies fast if you don’t use it.

Mentorship That Actually Works

Over 20 years, I’ve mentored more than 20 engineers across infrastructure, security, and SRE. And the pattern is consistent: the most impactful mentorship happens when you’re solving real problems together, not when you’re dispensing wisdom from a conference room.

Reviewing someone’s pull request and pointing out a subtle race condition in their Terraform state management? That’s mentorship. Walking through a design doc and asking “what happens when this service is down in Region B?” That’s mentorship. Sitting next to someone (or on a Zoom) while they debug their first VPC peering issue and not taking the keyboard? That’s the hardest and best kind of mentorship.

Career conversations matter too. Of course they do. But the daily, technical mentorship that happens through code reviews, design sessions, and joint debugging is where most of the growth actually happens. It’s where engineers learn to think about operational safety, to anticipate failure modes, to make pragmatic tradeoffs. And it only works if the mentor is actually in the code.

Knowledge Multiplication

Here’s the metric I care about: are teams more capable after working with me?

Not: how many lines of code did I write? Not: how many design docs did I author? But: can the SRE team debug a peering issue without escalating to me? Can the data team provision their own clusters safely? Can a new hire get to their first production deployment without a two-week gauntlet of “please ask Sekou”?

I call this knowledge multiplication, and it’s the real reason the player-coach model matters at the principal level.

In practice, it looks like cross-team workshops on cloud networking and Infrastructure as Code. Not lectures. Working sessions where engineers bring real problems and we solve them together. The goal is raising the floor of infrastructure literacy across the whole organization, not just building a dependency on one person.

You can’t teach what you don’t practice. The moment I stop touching the systems I’m teaching people to operate, my workshops become theoretical. And theoretical workshops are the ones people attend once and forget.

What 40/60 Actually Looks Like

Forty percent isn’t a precise number. Some weeks it’s 30%. Some weeks (usually during an incident or a big migration) it’s 60%. The point is the commitment to staying in the work.

The hands-on 40%: code and design reviews. Writing and maintaining Terraform modules and CI/CD configurations. Debugging production issues. Building proof-of-concept implementations for new architecture patterns.

The strategic 60%: defining team charter and roadmaps. Cross-functional alignment with product, security, and data teams. Mentorship and career development conversations. Translating infrastructure strategy into language that non-infrastructure teams can act on.

Both halves feed each other. The strategic work tells me what to build. The hands-on work keeps my strategies honest.

The Part Nobody Talks About

When the most senior person on the team is visibly doing the work, making mistakes, asking questions, admitting when they’re wrong, it does something powerful for team culture. It creates permission for everyone else to do the same.

I think about this a lot, especially in the context of engineers from underrepresented backgrounds. As a mentor at /dev/color, I’ve seen firsthand how important it is to work in environments where you feel safe to take risks, ask “dumb” questions, and grow publicly. The player-coach model contributes to that environment because it flattens the hierarchy in practice, even when the org chart still has levels.

When your tech lead ships buggy code, admits it, fixes it, and talks about what they learned? That’s more powerful than any psychological safety training deck.

The Gap Where Bad Decisions Hide

The player-coach model isn’t for everyone. I know senior ICs who lead brilliantly at full strategy, full time. But for me, the 40% commitment to staying hands-on is what makes everything else work.

The best infrastructure leaders I know can draw the architecture diagram and write the Terraform module. The gap between those two activities is where bad decisions hide. I stay in both because that gap is where my job actually lives.