5 ms·

how to be pm engineers don't hate > don't micromanage (sending IM messages to repeat something already in an email or ticket for example) > respect the experi

how to be pm engineers don't hate > don't micromanage (sending IM messages to repeat something already in an email or ticket for example) > respect the experience of your engineers. don't patronise them. > take responsibility for YOUR project. don't expect engineers to do anything other than exactly what is requested. and no more. > remember that you are the PROJECT manager and not dev manager. don't overstep your position. > don't make negative assumptions about people. if something is delayed or slow ask why. don't just assume the worst about people. > don't wait until production to check things properly. ultimately it is your project and you're responsible. > don't expect engineers to answer question that was not asked. be thorough in your requirements. don't make assumptions about prior knowledge. > don't editorialize or edit what the engineer has written. put in your own words if needed. don't eliminate the engineer from a discussion. they are a human too not some basement dwelling ogre. i have much more but my brain is tired right now from spoon-feeding ungrateful PM's.

aikinai 3y ago
Wow, a few of these are like the blueprint for dysfunctional teams. Engineers only do exactly what was written in requirements and don’t answer any questions that weren’t asked? Then why even have your own engineers instead of outsourcing to the cheapest Indian shop you can find? Or is that the arrangement you’re intending to describe?
- usrbinbash 3y ago
  > Engineers only do exactly what was written in requirements It's a balance question. Because on the other side of that coin, are requirements that are nebulous enough to be interpreted as a technical document describing everything between a calendar app to a rocket engine, a cooking recipe, or the prayer mantra of a futurologist cult. Sure, engineers can "work" with that, which means they have to implement AND design the product as they go. Which usually ends in a mess for all parties involved. So yes, engineers are within their rights to demand actually useful specs, that clearly outline what the goal of the work is. That doesn't mean they want every step of the way described in minute detail. As I said, writing good specs is a balancing act. Of course employers are also welcome to instead take a broken spec and try to outsource it to somewhere. Only, they should be aware beforehand that the cost of hiring freelancers to fix the outcome of such experiments, often exceeds the rate of inhouse guys by quite a significant margin.
  - whstl 3y ago
    "Sure, engineers can "work" with that, which means they have to implement AND design the product as they go. Which usually ends in a mess for all parties involved." IMO that can work as long as engineers are experienced enough, and expectations are set on both sides. PMs will have to accept an iterative process where people gotta keep refining to get to an ideal state. And Developers will have to accept that "iterative" means you'll constantly have to re-do work or throw away stuff. But if either side can't accept that, you'll end up with a mess alright.
- matwood 3y ago
  I agree. The OP is basically saying the engineers need to go off and do only their interpretation of a ticket with zero responsibility, while the PM is fully responsible isn't allowed to ever question engineers. Outside of the clear problems of lack of trust, the items when taken as a whole are how to destroy a team and fail a project.
amelius 3y ago
Think your project through and don't come up with last-minute requirements.
dagss 3y ago
As an engineer, I would not want to work in a team that works the way you seem to paint as ideal here. Especially "don't expect engineers to do anything other than what is requested". Engineers and PMs are "partners in crime", they have to collaborate with their skills complementing one another, bounce ideas around to find the best outcomes. Many good engineers also have a good grasp of product. Having a mindset where it is always PMs "requesting" and engineers "deliver only what is requested" -- in such an environment I would (as an engineer) find a new job.
noisy_boy 3y ago
I'll add my favorite: > don't start with "that shouldn't take much time, right?" Unless you are a PM that is also making non-trivial code contributions, let the people who are actually getting their hands dirty on a daily basis provide you the estimate. What seems simple can be complex to implement or vice versa. Asking presumptive questions like this only insults the engineers knowledge of the system and usually they are smart enough to see such underhanded pressure tactics from a mile so it only diminishes respect for you in their eyes. Just ask it straight: "how long do you think this will take?" You'll get plenty of time to question the estimate and the engineer would be more than happy to take you though the code/config to explain why what seemed simple isn't so, assuming you are genuinely interested in understanding the rationale.
ravenstine 3y ago
> don't expect engineers to do anything other than exactly what is requested. and no more. > don't expect engineers to answer question that was not asked. be thorough in your requirements. don't make assumptions about prior knowledge. The inverse unfortunately describes just about every PM I've had to work with. Good developers should be asking questions to fill in any gaps in requirements that aren't likely to be considered by non-developers, but it ultimately shouldn't be their responsibility to figure out the requirements. If a PM can't provide useful feature requirements, then they probably should be fired. Here's how things typically go: - PM comes back from meeting with product owners and writes a bunch of tickets with a title and single sentence like "do the thing." - During backlog grooming, engineers are forced to ask the PM to provide more context and acceptance criteria. The PM pulls some AC out of their ass. Because the grooming is capped at an hour, all AC and behavioral descriptions are half-assed, and contain contradictions. Developers are burned out from constantly wondering WTF and just want to get out of there. Most if not all groomed tickets are wrong in some way. - PM meets again with product owners and designers to discuss changes to features being worked on. PM fails to update most of the tickets that relate to said changes. Designers, who seem to usually work outside the sprint process, make changes to their mockups without notifying developers. Developers stumble across changes to the mockups midway through developing a feature and go "WTF?" Or they've already submitted a PR and another developer notices that the work doesn't match the mockups. - Developers have Zoom meeting with PM and designers to ask "WTF?" Nobody takes responsibility. PM pretends to clear up ambiguity by taking suggestions from the developers and changing the AC of the ticket. Designers pretty much roll over to whatever the group decides because they just want to get out of there. - PM presents merged feature to product owners. Turns out the PM didn't read their minds correctly, and so follow up tickets are filed. Some of those tickets vindicate the developer's concerns or revert changes made to the AC during the sprint. - Developers are told to "ask more questions" in order to "close the loop" during sprints so that this circus doesn't happen again, passing blame to developers and further guaranteeing that the circus continues.
- 5350-uiop-1130 3y ago
  > Turns out the PM didn't read their minds correctly that's what frustrating. why should the engineer ask the pm to ask the product owners to flesh things out. pm has a responsibility to understand product requirement fully - outside of technical limitations. otherwise they are just a glorified middle man. just let the engineer speak to the product owner. this is why i say don't expect engineer to answer questions that were not asked. why should we take that burden and blame. consider the engineer as someone providing a service, like someone else commented "outsourcing to india" - yes in a way you are outsourcing to an engineer in your team. if a PM doesn't understand a project, then why are they managing it. they should be title "email or communication facilitator" or something like that instead.
lkbm 3y ago
> > remember that you are the PROJECT manager and not dev manager. don't overstep your position. This suggestion really applies to both, but I just wanted to note that article is talking about product managers, and specifically recommends against making them project managers.
rockemsockem 3y ago
The article is about product managers. Not project managers. Usually a totally different role, which is why I assume none of your points are correct.

aikinai 3y ago

Wow, a few of these are like the blueprint for dysfunctional teams. Engineers only do exactly what was written in requirements and don’t answer any questions that weren’t asked? Then why even have your own engineers instead of outsourcing to the cheapest Indian shop you can find? Or is that the arrangement you’re intending to describe?

usrbinbash 3y ago
> Engineers only do exactly what was written in requirements It's a balance question. Because on the other side of that coin, are requirements that are nebulous enough to be interpreted as a technical document describing everything between a calendar app to a rocket engine, a cooking recipe, or the prayer mantra of a futurologist cult. Sure, engineers can "work" with that, which means they have to implement AND design the product as they go. Which usually ends in a mess for all parties involved. So yes, engineers are within their rights to demand actually useful specs, that clearly outline what the goal of the work is. That doesn't mean they want every step of the way described in minute detail. As I said, writing good specs is a balancing act. Of course employers are also welcome to instead take a broken spec and try to outsource it to somewhere. Only, they should be aware beforehand that the cost of hiring freelancers to fix the outcome of such experiments, often exceeds the rate of inhouse guys by quite a significant margin.
- whstl 3y ago
  "Sure, engineers can "work" with that, which means they have to implement AND design the product as they go. Which usually ends in a mess for all parties involved." IMO that can work as long as engineers are experienced enough, and expectations are set on both sides. PMs will have to accept an iterative process where people gotta keep refining to get to an ideal state. And Developers will have to accept that "iterative" means you'll constantly have to re-do work or throw away stuff. But if either side can't accept that, you'll end up with a mess alright.
matwood 3y ago
I agree. The OP is basically saying the engineers need to go off and do only their interpretation of a ticket with zero responsibility, while the PM is fully responsible isn't allowed to ever question engineers. Outside of the clear problems of lack of trust, the items when taken as a whole are how to destroy a team and fail a project.

amelius 3y ago

Think your project through and don't come up with last-minute requirements.

dagss 3y ago

As an engineer, I would not want to work in a team that works the way you seem to paint as ideal here. Especially "don't expect engineers to do anything other than what is requested". Engineers and PMs are "partners in crime", they have to collaborate with their skills complementing one another, bounce ideas around to find the best outcomes. Many good engineers also have a good grasp of product. Having a mindset where it is always PMs "requesting" and engineers "deliver only what is requested" -- in such an environment I would (as an engineer) find a new job.

noisy_boy 3y ago

I'll add my favorite: > don't start with "that shouldn't take much time, right?" Unless you are a PM that is also making non-trivial code contributions, let the people who are actually getting their hands dirty on a daily basis provide you the estimate. What seems simple can be complex to implement or vice versa. Asking presumptive questions like this only insults the engineers knowledge of the system and usually they are smart enough to see such underhanded pressure tactics from a mile so it only diminishes respect for you in their eyes. Just ask it straight: "how long do you think this will take?" You'll get plenty of time to question the estimate and the engineer would be more than happy to take you though the code/config to explain why what seemed simple isn't so, assuming you are genuinely interested in understanding the rationale.

ravenstine 3y ago

> don't expect engineers to do anything other than exactly what is requested. and no more. > don't expect engineers to answer question that was not asked. be thorough in your requirements. don't make assumptions about prior knowledge. The inverse unfortunately describes just about every PM I've had to work with. Good developers should be asking questions to fill in any gaps in requirements that aren't likely to be considered by non-developers, but it ultimately shouldn't be their responsibility to figure out the requirements. If a PM can't provide useful feature requirements, then they probably should be fired. Here's how things typically go: - PM comes back from meeting with product owners and writes a bunch of tickets with a title and single sentence like "do the thing." - During backlog grooming, engineers are forced to ask the PM to provide more context and acceptance criteria. The PM pulls some AC out of their ass. Because the grooming is capped at an hour, all AC and behavioral descriptions are half-assed, and contain contradictions. Developers are burned out from constantly wondering WTF and just want to get out of there. Most if not all groomed tickets are wrong in some way. - PM meets again with product owners and designers to discuss changes to features being worked on. PM fails to update most of the tickets that relate to said changes. Designers, who seem to usually work outside the sprint process, make changes to their mockups without notifying developers. Developers stumble across changes to the mockups midway through developing a feature and go "WTF?" Or they've already submitted a PR and another developer notices that the work doesn't match the mockups. - Developers have Zoom meeting with PM and designers to ask "WTF?" Nobody takes responsibility. PM pretends to clear up ambiguity by taking suggestions from the developers and changing the AC of the ticket. Designers pretty much roll over to whatever the group decides because they just want to get out of there. - PM presents merged feature to product owners. Turns out the PM didn't read their minds correctly, and so follow up tickets are filed. Some of those tickets vindicate the developer's concerns or revert changes made to the AC during the sprint. - Developers are told to "ask more questions" in order to "close the loop" during sprints so that this circus doesn't happen again, passing blame to developers and further guaranteeing that the circus continues.

5350-uiop-1130 3y ago
> Turns out the PM didn't read their minds correctly that's what frustrating. why should the engineer ask the pm to ask the product owners to flesh things out. pm has a responsibility to understand product requirement fully - outside of technical limitations. otherwise they are just a glorified middle man. just let the engineer speak to the product owner. this is why i say don't expect engineer to answer questions that were not asked. why should we take that burden and blame. consider the engineer as someone providing a service, like someone else commented "outsourcing to india" - yes in a way you are outsourcing to an engineer in your team. if a PM doesn't understand a project, then why are they managing it. they should be title "email or communication facilitator" or something like that instead.

lkbm 3y ago

> > remember that you are the PROJECT manager and not dev manager. don't overstep your position. This suggestion really applies to both, but I just wanted to note that article is talking about product managers, and specifically recommends against making them project managers.

rockemsockem 3y ago

The article is about product managers. Not project managers. Usually a totally different role, which is why I assume none of your points are correct.