Good PMs are worth their weight in gold and actually make engineers' jobs easier.
Bad PMs create a useless "translation" layer that doesn't help anyone (except, perhaps, themselves.)
It's exactly the same for designers.
Good ones can shave days off complex tasks, and even help the code be more beautiful.
Bad ones can turn a 5-min feature into a week's worth of work. For absolutely no gain, and possibly creating a few bugs along the way.
Unfortunately the only way designers and PMs can learn this is by working together with engineers. Everyone needs to check the ego at the door. Which is borderline impossible with some personalities (from all sides).
In my startup experience, it seems to me the best PMs are the CTO and the early engineers who has near infinite business and user context.
Not OP, but I can answer:
They're ok with ideas coming from someone else, check the ego at the door and listen to both engineers and customers. They make engineers work less and produce more value. Most important, they don't have a "vision", they help organize the team so the team has a shared vision built by the team.
EDIT: Also: They're not competing with the engineering manager or lead developer for some sort of leadership. They're talking with customers instead of asking sales to do it. They're working on the product aspect of tasks instead of offloading them to engineers.
Yep. Most of the managers that I've had that have been promoted from engineering have felt that their role is also tech lead, and have been poor at both being a tech lead and a product manager.
I worked one of those in the past, and the attempts at micromanagement were not only absurd but very disruptive.
I now prefer "non-technical" PMs to "half-technical".
Example: good PM will build a mock up of a UI, go over it in detail with engineers, then let them break up their own work. They are focused on the actual product. Bad PM will write 10 Jira tickets without any real context, assign them without discussion, then add 20 different tracking fields that nobody will use.
My definition of a good PM is someone who can champion both customers/users and developers concurrently, while sticking to the company's value prop and competitive edge.
In some cases, it's boiling down the needs of the customer into something achievable before sales gets in the way with over-promising and under-delivering. In other cases, it's telling the executives to stop wasting engineering's time with excessive meetings and scope-creep. It could be simply going and getting the engineers coffee. It could also be telling engineering to stop over-engineering the MVP and to simply get what needs to be done, done.
In simple terms, someone who can go to bat for any facet of the company at any time externally or internally, in order to make sure right product is being built in a timely manner that aligns with both business needs and most importantly, customer needs.
* Do the developers know what the customers want?
* Do the customers have realistic expectations?
If yes to both, then the PM in between is doing a good job. Bonus points if higher management is aware of that.
A good PM should effectively get out in front of the sales team to make sure customers/users feel heard and understood, and also to communicate to the customers/users what is and isn't possible within a given period of time.
A good PM should also know how to communicate a "no" to anyone in the business cycle from anyone else in the business cycle. Their job is effectively to be the firewall/filter from one team to another.
No, customers don't want Feature XYZ even though engineering wants to build it No, engineering can't build Feature ABC even if a customer wants it No, sales cannot promise Feature 123 to customer, especially without checking with engineering first. No, executives can't force engineering to focus on the CMO's pet project, or force sales to hit numbers if the product sucks or isn't what the market wants
And so on
That's basically the role of the PM: to have all the business and user context and to use that to harmonise vision between the various "stakeholders" (parts of the business, users/clients, etc). But one doesn't have to be the CTO or an early engineer to have this context/skillset.
My company, being more than a little bit toxic, he got transferred to a new manager who took an instant dislike to him and he was pulled off all his projects and then fired for not delivering anything. (bit of an exaggeration, he got put onto one of those "all responsibility, no authority" type projects where he was responsible for making sure everyone at the company stopped using the VPN, but he had no authority to force teams to build or migrate services to be available outside the VPN, and there were 2+ decades of services to migrate, and he couldn't direct people to stop connecting to VPN if they needed something that was inside the VPN)
The PM that came along to replace him described himself to all the engineers as "the next Elon", wouldn't let engineers talk to customers, personally decided what features to build with no input from the dev team, even when making technically difficult decisions. He asked for estimates from devs but never used them. Often giving us both half the time asked for, and half the engineers asked for to deliver a project. He never deflected chaos from customers, just added a translation layer that made it impossible to make the customers happy. Everything was an emergency, every feature necessary for an MVP. He'd constantly harass people for status updates, forget what they were working on and harass them again. He constantly asked for documents to be written for himself that he never bothered to open the links too.
He was actively toxic, wrong and an impediment.
He'd send out launch announcements to the org celebrating the projects that were completed and it was customary to list key people who delivered the project. He'd forget whole teams of people that worked on the project. One time he left me off of a project that I lead, got everyone in our sibling team that was helping out though. One person he never forgot to list as being a key person involved in the project was himself. Even in projects he had never heard of before having to write the launch announcement.
That behavior was rewarded, for whatever reason. Although he finally left the company when one of the many rounds of "you must work from the same office as your manager" bullshit caught him up and he wouldn't relocate from canada to the US.
Sounds like you're describing someone with narcissistic personality disorder. Such people are often extraordinarily good at convincing the people above them they walk on water while shitting on everyone below them.
My greatest wish is for managers to be trained to recognize people with NPD and other disorders and to remove them from the company quickly. They can cause tremendous damage to the organization in a very short time.
Yep that sums it up.
A mediocre one is already a huge problem, a bad one is able to tank projects.
A mediocre boss or mediocre engineer can at least get out of the way.