← Posts

Four titles, and I never left the editor

Staying in the code was the compromise I was quietly embarrassed about for fifteen years. The economics just made it the correct position.

5 min read

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 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, and the manager's job was to multiply other people's hands.

I used the rule on myself. At Life Happens I went from individual contributor to CTO in nearly six years, running an engineering team I have described elsewhere, 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. If typing was the bottleneck, my job was to make more typing happen through other people, and sitting in the editor was a tax on that. The tax was real, in that cost structure. We are not 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, and 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. That is not a personality preference. It is a fact about skill.

I am back at the keyboard, running agents, for that reason. 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.

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. Four titles in between. Individual contributor through January 2019. Director of Engineering and Director of Customer Success at the same time through October 2019, because the loop between what shipped and what members experienced was the actual job. Director of Technology and Engineering through January 2023. Then 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 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 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 caught myself and reformed.

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, and 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: 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, the senior person's calendar should show it. A leader who only sees dashboards will approve plausible work they cannot read. How much I should still write versus only read, and how much of my own editor time is discipline versus the failure mode wearing a better explanation: that split is not settled. The calendar shows the review hours. That much I can defend.