I think about this a lot. A great pm can be a huge help to senior devs. However in the cases Ive seen senior devs end up doing most of the pm's thinking.
Oh, we've had very different experiences relating to project management! I've never had a PM that was a former developer, and in my world senior developers usually act as solution architects without the title, mostly removed from the day to day development tasks unless they're briefing developers on documentation and implementation details.
I spent at least the first half of my career working with non-technical PMs and thought they were useless. I then joined a company where the PM was a former C++ game dev who was on several credits of some of the biggest games of the 2000's. He was an absolute joy to work with. He understood issues that we faced, he warned us of pitfalls to certain approaches, he greased pathways for us in upper management. I consulted with him when I was trying to decide whether to take a PM role.
It's actually very hard to generalize these statements.
I wholeheartedly agree that a great PM is a great advocate for the team, bringing team issues forward and freeing the way to get stuff done.
On the other hand it's often a tight rope to walk. I've seen situations often enough where a dev team would like to change frameworks/backends/dev environments/codebases, whatever it might be. And this has to be weighed between short- and long-term success. This is where a more technical product manager shines. On the other end of the scale I've seen dev teams walk all over their (non-technical) PM because they knew they could do so. It's a give- and take between team happiness and advocacy as well as end-user satisfaction and what the company needs at any given point in time.
Being a great PM is actually much harder than it seems at first.
The positions I've worked with non-technical PMs has been one with a kind of dual structure - there was a lead developer who was the technical expert as well as largely the PM's equal. The PM was more of an ancillary addition to the team, and any decisions were filtered between the two.
The best PM I had came from Customer Support, where he learned some scripting to automate tasks. So he wasn't really a developer, but understood the technical side of things.
I only say this because you mentioned that some PMs had some problems with your work. People who gravitate to one of the PM roles are problem creators. They are not users and they are not developers. In order to make a living they need to extract value from the dev process. One of the methods in which this is done is politics, gatekeeper-ism, and gridlock. This manifests as FUD to upper management. If the project or technology is not seen as one the PM has instigated and is in control of, they will fight it and you with FUD. Never mind the fact that the PM probably knows nothing about the technologies in question. Unfortunately you will probably need to find some new clients.
As a dev lead, tech lead or architect, my experience of PMs has almost exclusively been terrible. It has usually involved them being a thin proxy between myself and management, with the PM constantly pushing for firm numbers and dates, pushing for forecasts, asking for meetings to explain all of the things they have already been communicated...
I invariably end up feeling like a baby sitter, and feeling like I'm doing most of the work the PM should be doing, and with frequent, pointless meetings cutting severely into my available time. Aside from that, as soon as there is any pressure from the customer, the PM projects that onto the team, lambasting and pushing, pushing for more with less.
On occasion my experience is different, with the PM actually using the data they already have available in Azure DevOps (or whatever), keeping meetings to the minimum, and shielding the team from outside stresses. Very rare though.
I've never thaught about a PM that isn't "involved" and only relies on metrics.
My experience is that PM's are part of the team ( and mostly a senior developer), not part of management.
They translate management decisions to their team and take responsibility for it. They shouldn't live in their ivory tower and not know what is going on.
Their experience gives them insights in developer efficiency issues and can solve more advanced problems.
Sometimes they help program, sometimes they are doing infrastructure ( Eg. Cloud management) or deployments.
They did good in the past and now do something else as a way of promotion and encounter new social aspects in managing a team and deploying a project.
Some should better stay developers and some like the challenge.
And if I interpreted the OP well, he's a promoted developer close to the team. And not a hired worker that thinks he's a PM without Dev experience.
What you describe is the ideal PM. Someone who understands the business and customers and some of the technology. There are two kinds of PMs that are good. The one you describe who understands the business and the former developer who has been with a company many years and has made transition to PM role. However in a lot of companies this is not always the case.
Boy, do I hate PMs. It’s as if almost every PM I’ve had to deal with isn’t particularly proficient in business, programming, or design management but knows exactly enough of all 3 silos to be dangerous at once to the other two. More often than not, I’ve found a PM will try to steer a project with some compromise to dev and design and bias toward business — in my selfish opinion as a single-silo employee, it’s mostly frustrating. PMs always come across like they believe they are miniature CEOs.
But, all that said... I could never do what they do. Oftentimes PMs are the last guys to leave, working weekends, scrambling for last minute keynotes and honestly pushing out ideas faster than anyone — good or bad. So even though I don’t always like working under a PM, I definitely respect the position and think in general the good ones really deserved the $$$.
Disagree completely. A good project manager sees themselves as a peer to devs, with a goal of shielding their team from dumb administrative stuff (like requests from upper management that are clearly out of touch with how the product actually works).
To do so, they must see themselves as a peer. Anyone with an ego who wants to boss people around will be a terrible PM. A good PM enables their team and is altruistically driven.
Once you work with someone like this, you'll understand how amazing PMs can be.
I'll second that. Any time I've seen PMs involved in dev work (like requirements gathering) it's a shit show. PMs can usually have shallow conversations about software, but not deep enough to do requirements gathering.
Yeah, I have found a few PM's who were "used to be technical". To be honest I found it a bit frustrating at times as they would think they knew enough to make (some of the) technical decisions, when I felt that I should actually be making those decisions as was the one actually getting my hands dirty with the code. Plus I had more experience as a developer than them, as they had transitioned to PM and hadn't actually been building stuff for a while.
I'm currently in transition from developer to PM. As a developer you always have the ability to bang something out and do something. As a PM, there are more frustrating days. I spend my day answering emails, tracking down stakeholders so I can figure out what the requirements are, getting the status of work, and reporting on the work. The bad days are when you get emergency requests or requests that don't make sense. You need to be able to work with everyone and see their point of view, even if you think they are incompetent
Most of the PMs come from non-tech background, more project-management types, and it shows.
reply