In defense of the player-coach

Staying in the code was the compromise I was quietly embarrassed about for fifteen years. The received wisdom was clear. A leader still using the editor had not learned to delegate. I believed it enough to be embarrassed. I have changed my mind, and not because I missed typing.

The player-coach role used to look like a failure to grow up. Now that producing code is cheap and evaluating it is expensive, staying close to the work is the better leadership structure. I did not arrive at that as a slogan. I arrived at it by never fully leaving the editor, and then watching the economics catch up.

The orthodoxy

The rule was simple. If you were still writing the code, you had not learned to run the people who should be writing it. An hour in the editor was an hour you did not spend unblocking five other people. When production was expensive, that arithmetic was right. The scarce thing was correct output at volume. The manager's job was to multiply other people's hands.

I understand why the rule existed. I used it on myself. At Life Happens I went from individual contributor to CTO in nearly six years, and I spent a lot of that climb slightly ashamed that I still opened the project. The received names were working manager and hands-on leader, and they were not compliments.

The rule was optimizing for a real constraint. I ran an engineering team of India-based contractors, typically five and peaking at fifteen for major projects, inside a company of about fifteen US W-2 staff. If typing was the bottleneck, my job was to make more typing happen through other people. Sitting in the editor was a tax on that.

I still think the tax was real, in that cost structure. I do not think we are in that cost structure anymore.

What inverted

Producing a candidate implementation now costs very little. Establishing that it is correct still costs about what it always did, and we have to do it much more often. Verification became the constraint. Generation did not take the constraint with it.

That inverts the old arithmetic. An hour in the material is no longer an hour stolen from multiplication. It is how you keep the one faculty the new stack actually needs: the ability to tell whether the output is wrong. Judgment has a maintenance requirement. It decays if you stop touching the work. A leader who has not touched the material cannot evaluate what the machine produced. I do not think that is a personality preference. I think it is a fact about skill.

I am back at the keyboard, running agents, for that reason. Most of my development work now runs through AI coding agents. The job looks less like typing a system into existence and more like directing, catching, and refusing. That is closer to management than the IC title suggests, and closer to the editor than the CTO title suggested. The player-coach was the shape that already fit. I had been treating it as a defect.

The many hats version of the same years is that I did not just stay in the editor. I also held jobs that were not engineering. That range is a different essay. This one is about the refusal to fully leave the code, even when the title said I should have.

Four titles, and I never fully left

I joined Life Happens in February 2018 as a PHP and Laravel developer. I left in December 2023 as CTO. Nearly six years. Four titles.

February 2018 to January 2019: PHP and Laravel developer. Individual contributor, senior, shipping against the platform roadmap.

January 2019 to October 2019: Director of Engineering and Director of Customer Success at the same time. Two titles. The point of the combination was the loop between what shipped and what members actually experienced.

October 2019 to January 2023: Director of Technology, Director of Engineering. Dual-hat leadership across delivery and the broader technology function.

January 2023 to December 2023: CTO.

I never fully left the editor. I am stating that as a fact about how I spent the years, not as a virtue. The titles moved. The project stayed open.

The failure mode is still real

Leaders hoard the interesting work. That failure mode is real. It was the steel inside the old orthodoxy, and the steel is still there. A player-coach who keeps the good problems and farms out the dull ones is not a new kind of leader. They are an old kind of bottleneck with a better story.

I am not claiming I avoided it cleanly. I do not have a story I can point to where I caught myself keeping the interesting work and handed it off. I stayed in the editor through four titles. Some of that was judgment, the maintenance requirement I am defending. Some of it was probably appetite. I cannot sort those cleanly in hindsight, and I will not invent a conversion narrative in which I did.

The honest position is narrower than a defense usually wants to be. Staying close to the material is now load-bearing. Staying close because you like the interesting problems is still a way to fail the people around you. Both can be true in the same week. I do not have a reliable test that tells them apart from the inside.

What the role should look like now

Keep your hands on enough of the material to judge it. Stay out of volume for its own sake. The old temptation was "I should type this because I am faster." The new version is "I should just generate it because I am faster." Both skip the part that is actually scarce, which is deciding whether the result should exist.

Reviewing agent output is a leadership activity, not a hobby you sneak in after the meetings. If the scarce work is verification, then the senior person's calendar should show it. A leader who only sees dashboards will approve plausible work they cannot read.

I do not have a finished picture of the split. How much I should still write, versus how much I should only read. How to stay close without crowding out the people, and now the agents, who are supposed to produce. I am still figuring out how much of my own time in the editor is discipline and how much is the failure mode wearing a better explanation.

Related: Player-coach, Verification, Many hats