I was fixing a production bug late one night during my time at The Ignition Group. The bug was in a scheduled job that processed inbound data files, and I had traced the problem to a specific method in the data access layer. The fix itself was straightforward.

What caught me was the git blame. The code was mine. I had written it about eight months earlier, and in those eight months nobody else on the team had touched that file.

That was the moment I realized something about how I was leading.

The real job at most small companies

When you run engineering at a small company, you write code, set up coding agents, and you run the team. Most articles about the player-coach model treat it as a transitional phase, something you grow out of as the team matures.

My experience was different. At The Ignition Group, being a player-coach was the actual job for a long stretch of time, and I think it’s the real job at most small companies. The hard part is the weekly decision about which parts of each role you keep and which you let go.

The pull toward the keyboard

Coding feels productive and satisfying in a way that management work never quite does. You can see what you shipped. It’s concrete. On top of that, you get a dopamine hit when you figure out why the original code didn’t do what you intended and you make a fix. When I had a hard day of management, the easiest thing in the world was to open my IDE and write something. And sometimes, that was necessary for the company, but often it was just a crutch.

Most of what a manager does is slower and more ambiguous, measured in weeks or months rather than commits. One-on-ones don’t have a definition of done, and a tricky conversation with a product partner doesn’t give you a green checkmark at the end.

The pull away from the code

It is easy to go wrong in the other direction, too. You can get so busy with management tasks that you lose touch with the code the team is producing. You’re attending standups but not reading PRs. You start making architecture decisions based on what the team tells you about the code, rather than what you can see in the code yourself. You stop questioning the AI’s decisions.

If that happens, your credibility slowly erodes, and your role as an engineering leader becomes less useful. Engineers can tell when you don’t know the system anymore, and they start filtering what they bring to you because explaining context takes too long.

Finding a balance

At The Ignition Group, I found a balance that held for a few years, with the team around three or four engineers. I stayed hands-on in a couple of specific, bounded areas, but handed off most of it to my engineers. I reviewed their PRs, answered questions when they came up, and deliberately kept my hands off the keyboard as much as possible.

The split was never perfectly clean. I still pulled tickets during crunch periods and still debugged production issues when I was the fastest path to a fix. What the balance gave me was a way to stay technically credible without becoming a bottleneck.

When player-coach starts to break

The signal that player-coach is breaking down is when your coding starts blocking the team more than it helps them. A PR sits for a few days because you were working on code instead of reviewing it. A decision stalls because you were the only one who could make it and you were heads-down on a feature. Engineers start routing around you because asking you takes too long.

For me, that inflection point came the first time we had a second product effort running in parallel. Once there were two workstreams, I couldn’t be meaningfully hands-on in either one without neglecting the other, and I couldn’t coach both groups while coding in one of them. By necessity, I (reluctantly) pulled back from active coding.

Building trust in the team

Moving beyond being a player requires trust in the engineers on the team, and honestly, that part was hard for me. Handing over code you care about means accepting that someone else will make different decisions than you would, and that some of those decisions will turn out to be worse than yours. Getting comfortable with that took longer than I’d like to admit.

Building that trust may be harder now than it was a few years ago. Engineers are writing code with AI in the loop, which means the coach sits one more step removed from what’s actually getting produced. You’re trusting the engineer’s judgment, and you’re trusting the AI output that the engineer decided to keep.

Advice for someone starting out

My advice to someone stepping into a Head of Engineering role at a small company? Plan to be a player-coach for the first year (maybe two), and to expect it to stop working sooner than you think. Player-coach is a stage with a shelf life tied to the size of your team and the trust you’ve built inside it.