Player Manager

What does an ideal PM even look like?

In large-scale development, the PM's job sprawls. Managing full-timers, contractors, vendors. Cost tracking. Ticket grooming. Quality gates. Schedule juggling. When an incident hits, you write the postmortem, present it to the executives, draft the prevention plan. Some companies split authority across EMs and tech leads, but when someone finally asks "so what do we do?"—that question lands on the PM.

A small team lets you play both roles. Write code yourself, steer the team's direction. Up to five people, you can handle design, implementation, reviews, and still sit with the client to nail down requirements.

Past ten, it starts to break.

While you're deep in code, Slack unreads pile up. Reviews stall. Meetings multiply. You realize you are the bottleneck. Cut your coding time and the machine runs again—but a PM who stops coding loses the temperature of the floor. Technical judgment drifts. Keep coding and management turns sloppy.

Beyond a certain scale, you have no choice but to step off the field. You don't want to. You have to. For someone who got into this work because they loved writing code, it is a brutal trade.

The fantasy that you can stay a player while becoming a manager—maybe that's a player's arrogance. I never shed that arrogance. I quit instead. Now AI writes the code, and the very definition of player-manager is shifting. That old struggle already feels like a distant past.