The PM Who Codes — Pros and Cons

I write Python. I build FastAPI services. I query Neo4j databases. I am also a project manager. This combination generates strong opinions from both sides.

The Pros

Credibility with engineers is the biggest win. When I review a technical design, I understand the tradeoffs. When a developer says "this refactor will take two sprints," I can have an informed conversation about scope instead of just accepting or pushing back blindly. Engineers respect PMs who understand their work at a technical level.

Speed is the second advantage. When I needed a capacity dashboard, I did not write a ticket and wait six weeks for it to get prioritized. I built it in two weekends. That tool now serves our entire team. Solving your own problems is incredibly empowering.

The third benefit is better requirements. I write specs that engineers actually find useful because I think about edge cases, error handling, and data flow. My requirements documents include API contracts and data schemas, not just user stories.

The Cons

The biggest risk is scope creep on yourself. Once people know you can code, requests start flowing in. "Can you just add this endpoint?" becomes a weekly occurrence. You have to protect your PM time aggressively, or you end up as an unpaid developer who also has to run standups.

The second danger is overstepping. Knowing how to code does not mean I should dictate implementation details. My job is to define the what and the why. The how belongs to the engineering team. I have to consciously step back during technical discussions and let the team own their architecture.

My Rule

I only build tools that no one else will build. If it is in the product backlog, it is engineering's domain. If it is an internal process tool that will never get prioritized, that is my territory. This boundary keeps things clean.