Project managers basically do something that the devs, especially dev manager, can handle themselves. It seems like a leftover process for when software contracting was more common. There’s no reason a developer can’t just manage the Kanban board and write a quick report.
Product managers can be really good but in a lot of cases they just devolve into stakeholder management with poor/no vision. Because they talk to upper management a lot they can get a lot of credit for things they didn’t have a lot to do with, because they’re the visible face for it. This can sometimes lead to the Product org getting too big because they get promoted up to Director and now need 10-100 reports for something that only needs like 3 Product managers max. Then you’re in a really bad spot because you’re going to be bothered by PMs with small scope a lot about stupid shit
I'm glad I can delegate them the reasoning about which task is more urgent, and them acting as buffer to clients frees me from a lot of time trying to understand what they want, how they want it and all the back and forth about how much they want to pay for it.
good project managers, that aren't just bossing internal people around but working with the team at different part of the projects like communication and operations, are rare, but are a joy to work with.
The role is not as useful in tech companies where developers are working permanently. It's actually hurting collaboration across teams if you start budgeting projects and people tightly.
The Devs who are permanent employees and maintain a set codebase/application/etc do not fall into that. They know what to do, they have a defined Change Management/SDLC abd they are challenged into finding the technical solutio. The project management includes tracking the requirements, sequencing events, getting resources/contractors, etc.. A dev should be spending '8h' per day coding, not figuring out budgets and interviewing contractors. Of course different companies have different approaches, but ballpark and from experience I think my above writings are pretty valid.
Then I actually ended up in the position where I took on the responsibilities of a Project Manager in the course of building a department. I see it much differently now having worn both those hats as a generalist. You're tracking two different sides of the same body of work, and there is solid value that a good project manager provides in terms of producing a meaningful skeletal specification on which more in depth technical analysis and work can be done.
In addition, not all devs are full on gung ho let me throw something out there that I know will be mostly wrong until the details get filled in by everyone else. As a PM, you're as much the Rock in a pot of Rock Soup as you are the guy in meetings all the time. I've had to eat a lot of humble pie since getting saddled with building a department. The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles.
It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something. You don't want to have to do it all at the same time.
Especially this is key: > The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles
> It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something.
Exactly! Thank you for putting this so succinctly.
Just being aware of what needs to be done and in what order is critical. For that you need a bird's eye view of all relevant pieces, which is almost impossible to do when you are in the weeds.
So you have non-designers enforcing their personal "vision" without cross-team collaboration or user research.
In your case, it sounds like you have crappy product leadership. This is _way_ too common.
You need a cohesive product vision from the top down (VP/head of product), which they communicate to their team of PMs. The head of product needs to ensure that their team can make the correct product decisions. This means guidelines on where the product is going, what the company prioritizes, and how products inter-play/work together.
With an actual vision from the top down, these calls which your PM team bicker on should become easy.
An engineering analogy: the CTO/lead architect sets the standard for the direction of engineering, its services, etc. This is followed by everyone in the engineering org (hopefully) with alignment and without bickering. This SHOULD happen for product, too.
Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.
You could probably reach out to your engineering leader and have them coach the head of product here. After all, that's the engineering leader's role - making sure their peers make the right decision and remove blocks from you, the engineer.
Regarding overlap, a good PM should amplify engineering. You might be a product focused engineer, but trust me: an engineering team cannot and should not be focused on writing user stories, performing research, and deciding the larger impact of features alongside their regular job of executing with code.
To expand on this, there has been one defining difference in good companies and bad companies I've worked for.
In good companies, everyone has expertise. Your PM can talk about details. Your director can talk about details. Your VP can talk about details. They do this because it's culturally expected that they know this. So they spend enough time to familiarize themselves and do normal paper-pushing responsibilities.
In bad companies, that's just... not there. If you ask anyone of those roles about details, they don't know and can't speak intelligently.
Consequently, in the former, you get much smarter decisions from all players. In the latter, you get ignorant decisions because there's less shared knowledge.
The strangest thing is that it seems more cultural than training / education. Either the company has this expectation of its people, or it doesn't. If it doesn't, no amount of degree will paper over that. If it does, it doesn't matter if your people are sharp but lack degrees.
There's a famous story from Microsoft back-in-Gates-days, whereby Gates was notorious for his detailed questions in meetings: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...