Some of these explanations are oversimplified. HMU if you want to discuss in more detail.

Estimating dev work is hard
A PM might think that a new feature will take two weeks to complete. In reality, devs don't really know that answer up front. Often times, we need to actually start building the new feature in order to determine its complexity, whether or not it impacts other things, and how long it would actually take to complete.

Deadlines are important, but devs generally get frustrated if the PM doesn't understand the above workflow and its nuance.

Software development is part art
Some days, devs could be in a flow state and get a lot of things done. Other days, we're just not there mentally and need to unwind. PMs could get frustrated about this reality if their tendency is to micromanage.

Gaps in technical knowledge
Sometimes, the technical gap between dev and PM could be too wide to the point that devs get frustrated trying to constantly dumb down explanations so the PM could understand.

We are very opinionated
Sometimes, our egos get in the way. If a PM suggests something that would be an improvement in user experience, even if it's backed with data, we'll still have our own opinions about it.

A bit of context, I was a team lead for 15 months on my previous job so I had a lot of interface with my then product/project manager.

Usually programmers get more involved in the project and perform better when they know why they are working on said task/story/feature. A good PM always backs his/hers users stories with a solid, business oriented reason.

Communication is key, and that goes both ways. The best PM that I've worked with held pretty strong standards on deliverable quality, but was also a great listener when the team argued that something couldn't be done due to technical limitations, or when a requirement had to be changed/negotiated.

Generally speaking programmers hate when the project scope changes. If the change was big or really far down the project, they hate it even more. Shit happens, we all know that, but a good PM always does his/hers homework on project risks and keep the team aware of the risks before they turn into real problems.

A good PM trusts... Once that trust has been earned. Your team has a great record of shipping fast and with great quality? Good, lay down the requirements, stories and acceptance criteria and let the team do the job. On the other hand, if their performance is spotty you may want to pay attention to that and act if that compromises the project delivery in any way.

The best PM that I've worked with was extremely organised and always kept the team aware of current project status and clear next steps. We may not always agreed, as expected, but always respected each others opinions and decisions.

I've had PMs that act like technical literacy is beneath them but then get upset when things don't go how they plan and basically shut down the conversation if anything as technical as API is mentioned. That's a bit of an extreme case but I think understanding roles and responsibilities is important. Each should understand the others job enough to empathize, and evangelize for the other. But i think it's also important to know where the lanes are. My PM can tell his thoughts and opinions on pubsub vs Kaftka if he has them but at the end of the day it's my job as the lead (with my dev team) to choose the architecture. Likewise I can explain and reason prioritization of 2 features but at the end of the day that's the PMs domain and they get the final say. Without that empathy and understanding though my PM can't understand the value of tech debt tickets, and i wouldn't understand why my PM is pressuring us to creep scope.

I think others have touched upon it here, but communication is the most important thing. The good PMs I've worked with have been able to communicate the project outcomes, the timeline, and specs very clearly. Beyond this they stick to their specs unless a very good reason comes up. I really appreciate this as a dev. One of the things I hate is redoing things unnecessarily. This happens if the PM hasn't been clear enough on the specs and they come up with things midway through the project (aka scope creep).

Another great aspect of a PM is being able to work cross functionally. The ones I've seen have been able to get resources to their devs if needed. Or have been able to unblock devs by connecting them with other teams. For them to be able to do this they need to have a pulse on the team. I don't mean micromanage, but they should know what's going on with work progress and any potential blockers. I've had a few PMs who have just stayed high level trying to develop business goals and continually working on specs. While this is great for planning, this forces me as a dev to step up and start prioritizing work. Which is not going to end well, especially since I don't always know the business priorities.

Finally, a great PM trusts their team and lets them work without pushing them to a deadline. I absolutely hate it when a PM tries to get me to commit to a hard date. A great PM will take information from the team to figure out a deadline to set. And be able to push back against business if someone from above is pushing a deadline on them.

Great question Stephanie, I hope all these answers help!

PM: "How long will this take?"
Me: "I will look at the specs and get back to you."
Me (later): "It will take X amount of time."
PM: "Oh, that's too long. Can we reduce the amount of time somehow?"
Me: "If the client cannot have any slip in due date, that's the amount of time it will take. It might be less."
PM: "I'll tell the client 'less'"

I really don't know how to fix this dynamic, other than to be honest with the client. Tell them the maximum amount of time it will take, and when it takes less time then charge less. This will exceed expectations.

One of the most important things is:

Make crystal clear feature requirements.

As someone who's doing a bit of dev, and project management, the comments are all super insightful!

Bad PM

• forwards client mails to a developer
• forwards developer mails to the client

A good PM

• is shielding the dev from all the second priority tasks
• makes sure that the tasks which are currently in development are 100% approved by the customer and doesn't give in to change-request while development is going on
• keeps issues clean: 1 issue for 1 problem - not 1 issue for 4 problems

What has worked well?

I'm a software engineer. We use a Scrum-like process, except we don't have Scrum Masters and the PMs take on parts of the role of Product Owner.

The PMs prioritization of the work has worked really well.

What could have been improved?

Our code base has had some neglected necessary maintenance. Which means we have a lot of technical debt. Which means feature development takes a lot longer. Yet we never have time to take care of the technical debt. The PMs equate technical debt with bugs, but those are separate from one another. Bugs are user-facing; technical debt is developer-facing.

Also, I think it would be interesting to try to do by the book Scrum. Just for a year. To see what it is like. But I don't think that will happen where I work.

Last but not least, we use Jira. I am not a fan of Jira. It's slow, cumbersome, awkward, and models the workflow poorly. But I do not know of any tool that is better than Jira.

Well, I had experiences with three projects and I had the same feelings about them. First of all, I like being a developer because I use to see it as a creative job. Then, more than liking to just code, I really like to build the software in its concepts and having some opinion about it and this has been the source of tension between me and the PO´s.

In the first project I just thought to myself that I would never use the app that was being proposed. I communicated it but the PO but he insisted that it was what the client wanted. When it happens it affects my engagement in the project, since I don´t believe in what I am building and there is no much space to make suggestions. I think one of the most interesting things in software development is when you see the software as your product, almost your "baby". In that case the PO took away the creative part of the job. In this particular project, after some sprints it became clear that the proposal was not really good and then they had to change the scope to something that was very close to what I wanted to suggest before. So, for me as a developer it was like a waste of work and re-working.

I found this pattern in the other projects too. Sometimes it is kind of obvious that the idea and requirements are not really good, but they expect that you as a developer just to do it. Then, in the future they ask to change or re-do things as it was the normal flow. But I think this argument is exaggerated. In my particular case they always justify with some ready-made phrase about agile but it was more a lack of understanding and since the developers are the ones who really have to do the work again they don´t care much about it.
In resume, they treated us as mere executors as we would not get bored or frustrated just coding whatever they asked with no regards to the idea of the system itself.

In some cases I felt like the PO was just a bad intermediary.
It was like if someone get sick (the client) and goes for a doctor (to find the solution, the software), but instead of talking to the doctor who knows how to identify and solve the problem, the patient had to talk to an intermediary, and then, this intermediary repasses the info to the doctor and then repasses it back to the client and so on. If we really think about this example, many confusions are going to happen and could be solved if there was no intermediary. This is an extreme example, but I think it can relates sometimes.

I believe it's all related to the top most managers and how work is rolled into action. As the customer's and time-to-market demands get higher, the backend engineers are doomed to failure; except for one thing. They must focus on reusable components and the product manager can help to run interference on that because it's really the number 1 way to get to production faster. Does your department have a component library?

A PM should
Not micromanage them,
Trust them with the task
Don't give unexpected deadlines
Listen to them