Does a PM have to get involved in engineering?

A friend started working as a PM recently and he is currently in his first PM stint. He works in a company that has integrated new products with legacy products and is scaling up without improving legacy infrastructure. It’s gotten to a point where most of his productive hours go into analyzing issues, figuring out which system is at fault, identifying ways of making the integration better - things like improving sync time or adding validations, solutioning automated DB updates, identifying redundant columns in tables etc. He seems to be working more closely with the developers than with the business team/product users. Is this part of a PMs job? Or is he doing something very very wrong.


I think it really depends on the organizational needs. I’ve been in companies where I was tied at the hip to engineering and spent a lot of time on tactical, near term execution because that’s what the business needed at the time. I’ve also been in companies where I’m almost entirely divorced from engineering and focused just on the strategic long-term vision. Neither is the “right” approach, just different.

If I consider as a PM, I’m “accountable” for the success for the success of the product, I do what I need to, to make it a success. Sometimes, it’s down in the weeds for months with engineering if that’s what the product needed. Other times, it’s staying at 30k feet and keeping out of everyone else’s way while being a meatshield for engineering. It just depends.

If the answer to the question," Does my product or the business need me to be doing this to be successful" is “Yes” and there’s no one else to do it, I think it’s part of job.

There are caveats with this - if the business needs you be working 60 hours a week consistently to be successful, that’s not OK. If the business is exploiting your willingness to step and get the job done to avoid long-term solutions to issues, that’s also not OK.

But assuming positive intent from the business – roll up your sleeves and dig in :wink:


Great response here. PMing is a malleable role, and varies from organization to organization.


Sounds like engineering work. Why are you doing it?


The engineering lead isn’t doing it. Even when he raises a concern either they asks him to directly work with the developer or just directly talks to the business teams on what needs to be done without keeping me in the loop he is always asked to directly work with the developer. Be it for estimates, requirement discussions, analyzing issues. Is that how it’s supposed to be?


When you raise the concerns, ask when he will have the work completed. Don’t leave the next action open-ended so it can be passed to him.

just directly talks to the business teams on what needs to be done without keeping me in the loop

Either he needs to be involved or he doesn’t. He has to be careful about asking to be “kept in the loop,” that’s a great way to get pulled into engineering work like fixing defects that really aren’t your problem. Unless there’s something about the expected user experience that’s unclear, or these discussions are to determine the user experience in the first place, it’s really not your problem.

If the discussions are about determining the user experience, you should be driving them, not the eng manager.


I’m having the same problem. It happens that I’m quite technical, so I get dragged into the weeds with the engineers all in the spirit of getting it to ship. But if I’m spending so much time on engineering, then I’m not spending time talking to customers and driving the roadmap.

In my opinion, PM’s shouldn’t need to dive into engineering details, so I’m pretty interested in hearing what others have to say.

1 Like

Hard to judge based just on this, but PM should be spending most of their time on delivering long term goals rather keeping the lights on.

Sometimes there are situations when dropping everything and firefighting makes sense for some time, but these should be exceptional.

Getting your team space and resources to fundamentally improve the system is more important that making it tick.

on reflection I wanted to add an explanation:

This means that you need to learn to let bad things happen, even if you personally can plug the hole temporarily. Sometimes when you firefight really well, it masks the issues, as from a distance everything appears to be working good enough. Let things go bad, spend time on fixing properly, so nobody every needs to plug that hole again.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.