Because if you’re working on a project big enough, you don’t have the time to be a good dev or a good manager. As a developer I wanted time to think about how best to solve the problem I was facing, not writing documents, refining the big picture, get a buy in from the stakeholders, giving reports, making sure the other parts of the project kept getting along and so on. It was important for me to be kept in the loop, not doing it on top of my job. As a product manager, it’s the other way: I have a product that need to be there and so I’m trying to find a good compromise between the stakeholders idea, what would really work and what can be done with the ressources I have. That means sometimes I recommend to not start anything, but to buy a solution (then I need to validate that it will work as intended, that the budget and contract are ok and so on)

It’s another job altogether. That doesn’t mean I won’t follow the technological trends, educate myself or refuse to program anything. I wrote some postman script to validate what’s happening with our api, know the infra behind it, and can generally point people in the right direction. I have to know the product inside out to make educated answers when something goes wrong or if a decision is required.

It’s often a people job. And that’s something I try to share with the teams I work for.