> most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here.
That sure would be nice. Almost every PM I've work with has actually just been a source of busywork who seemed to view their job as to ensure that the engineers spent as much time on issue management as possible. The only one which actually tried to do it himself had a habit of closing actionable bug reports because the reporter didn't bother giving the useless extra info that the PM asked for, while sending all the useless ones on to the developers.
> But from my experience, I find that the prevalence and empowerment of PMs is largely turning Devs into highly-paid code monkeys, as opposed to the highly-paid and empowered value builders that they should be.
Indeed. In the first ~17 years of my career in software I never met or heard of a PM. That's a job for engineering leadership (architects or equivalent).
Nothing good comes out of having a separate non-technical person making architectural decisions. Also as you say, it disempowers engineering which is a sure way to drive out the best.
How true! In my 30 years in the industry, I haven't experienced a single PM who was a net-positive (though I've heard that some are awesome), and some that simply made no positive contribution whatsoever.
I had one program manager who was awesome, even though we certainly didn't need a program manager (~40 person startup) per se. But she realized what was going on and then kept the PM (and everyone else) off my back so I could get the job done.
First and AFAIK only time in that company's history that a software project was delivered on-time.
Of course, after we shipped, it was all "congrats, but now you must do things properly like the rest of the company".
Not sure whether that's "sigh" or "LOL" or ¯\_(?)_/¯
> Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks
The problem is that if the PM decides to do that, the developer has no authority to refuse that.
> Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.
> Basically, the PM got accolades, the customer got shitty product, and we hated our jobs.
The incentive for a PM or tech lead isn't to help developers do their job well but to make their boss happy. By the developers themselves not being more closely involved with product owners, using a PM as an interface and shield from the rest of the company, they give sole individuals the opportunity to crack the whip for fun and for profit. If they are particularly good at what they do, they make everyone believe they are a hero and that nothing would get done without them.
Guess who's getting a raise for the project getting done ahead of time? It probably ain't you.
>Why are we blaming PMs, here? Plenty of engineers out there make really stupid decisions every day.
EXACTLY! Because it's a known fact all devs make mistakes, and as such, as a product manager/owner you're responsible for the bigger picture of the product and ensuring the right requirements, checks and bound are put in palce and validated for a successful product release.
It's not the job of the lowly SW engineers who have little visibility in the product as a whole and who just sprint to punch out Jira tickets handed to them from above, to check your product works as intended, it's your job as a PM/PO to ensure the work of all the devs integrates nicely into a cohesive product as per the requirements/vision.
Kind of like that famous story of that intern who got fired for deleting the production DB by mistake on his first day. Was it the intern's fault for the mistake or the fault of all the seniors and managers who should have placed the proper checks and bounds in place so that nobody can so easily delete the production DB?
So the buck for the product success/fail stops with those at the top who orchestrate the band, not with the individual SW engineers at the bottom.
> It’s actually really hard as a non-engineer to file useful bug tickets for engineers... So the engineer would be frustrated, I would be frustrated
While I have been in this scenario before, saying something along the lines of, "If I don't get 100% bug reports, I can't do 100% bug fixes," 9 years of experience and maturity later: no, I wouldn't use this. It wouldn't engender me more respect, power or efficacy in the organization if I "just" "educated" PMs on how to file bugs, or if I "just" used some tool for them.
I should have just not asked non-engineers to ticket bugs or do QA. If that is happening, you are already failing in terms of leadership and organization. Most products fail, so that's not saying much, and they rarely fail due to bugs, which is also not saying much. That said, the best technical solution is clearly comprehensive tracing, and the best cultural solution is that engineers responsible for an end user experience must manually QA all paths.
> My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain.
Sorry, calling BS on this one. You’re calling out an entire group when, like most things, it’s a subset of the broader group. Good PMs understand that a complete product is not just new fancy features but a combination of Features, tech debt work, security and more. At the end of the day if our customers aren’t secure, we’re in trouble.
I’ve been on both teams. Once watching a PM stand n the midst of my engineering team proclaiming “I don’t give an F about your technical debt, when will my features be done?” And now I lead a product management team. Great companies have Product and Engineering trusting each other and working together. They may disagree from time to time, but they deliver together and work together to balance what gets done.
> However it is very difficult to have empathy with the user when you're trying to produce code.
Not only that, but as a dev you can get into a position where what you decide to work on is based more on ease of development or “fits cleanly with what we have now”.
There should be a balance. The PM should push for the impossible and the engineers can tell the PM why that won’t work. Kind of… maybe not with that much hyperbole in my assertion.
> The point here is that some PMs feel that if they're not demanding changes, they are not necessary / not doing their job / etc. If there's nothing wrong with the completed work, such a PM will demand unnecessary changes, in order to justify themselves.
Is that the point? Or is the point that some developers/designers don't like to get edited, so they tell themselves that their PM is pathological?
There's more than one valid perspective on things, and in my experience professional relationships work better when everyone realizes that.
> As a software developer, which tasks do you find most annoying in your daily work?
Having to tell others (contractors, collaborating 3rd parties, etc.) what they shall do and how to do it. We've got an issue tracker and a TODO list and tons of TODO/FIXME/XXX comments in our code base. How about working on those? Pick an issue in the tracker (or if you've found some TODO/FIXME/XXX that hasn't assigned a tracking ID, create a new own) and work on it! Oh, and please don't ask me for a pinned down specification for each and every detail; it takes me more time and work to write down such micromanaging specs, than it'd take me, to write the code myself.
You think meetings are productivity killers? At least you can zone out in those and mentally work problems. People asking to be micromanaged, that's what really grinds my gears.
> from a developer’s career perspective, attempts to involve them early can be a huge time suck.
Most developers appreciate bringing them in early. What they don't appreciate is the PM bringing them in early without having done any homework. Such PMs don't earn any developer trust and will never be able to launch things on time.
If companies weren't getting value from them, they wouldn't be hiring them.
> And technical people are basically the only ones who actually know how to write things in detailed and unambiguous enough way
No, that's exactly OP's point. Developers in general are terrible at writing explanatory text (if they even bother at all) because they make so many assumptions about background knowledge that others don't share.
This is one of my pet peeves when it comes to software development. I _really_ think that software development project managers ought to be able to spot the difference between a good architectural decision and a bad architectural decision, a good design decision and a bad design decision, a well implemented function and a badly implemented function. It sinks my heart, as a software development professional, having to work for project managers who, in many cases, would be hard pressed to explain what a byte is. It's just so wrong.
It's like working for a newspaper editor who does not know how to read or write. It does not mean that you cannot produce a newspaper, but it depends upon the workers stepping in and doing all the strategical technical decision behind the project managers back. As an engineer you can live with it for some time, but eventually it ends up feeling fake, and like a masquerade.
I'm much more in favor of hands on leadership types like Microsoft's Dave Cutler, with the technical skills to actually lead, and not just superficially 'manage'.
> You can't lead developers if you have no clue about developing. Sorry.
I’ve been both a developer and a development manager (and a few other things), and once upon a time I would have agreed wholeheartedly with this.
Then about 10 years ago I started working with the best PM I have ever known. He is absolutely not technical.
He is, however, a great listener, opionated about protecting people from burnout and dumb processes, honest to a fault, and able to speak candidly and openly to techs, devs, execs, and everything in between, switching language as he goes.
On one project we worked on, I had an advisory role and he ran the development sprints. He was amazing at understanding what the devs needed and managing the manager’s unrealistic expectations of how quickly things could be done.
He also put his foot down and insisted that everything flow through him, to be integrated into schedules based on, well, balancing everything else with business priorities.
It took a some time for the devs to trust him, and it took a lot of soft skill work on his part to gain that trust, but before long they realized their weeks were pretty evenly balanced.
The first big win was no more high priority interrupts from the manager, who had to work through him. That helped a lot.
He knows nothing about development, in the sense of having no idea how to do it.
He does know people and knows how understand what they need.
> Unfortunately, they are not usually very good at thinking about the people who will use their systems, taking their preferences into account, and treating them like customers who they are trying to keep.
Then give developers a little more respect and let them do that!
It is telling that the longest chunk of this text is about not hiring too many PMs and the next longest is about better support. Maybe we should hire fewer product mangers and more support^H^H^H^H^H^H^Hcustomer success staff.
Is this a PM telling us why we shouldn't hire for that function? I agree and I'll vote this submission up!
> The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable.
The best way to do that is to train your senior devs to act as part time PMs.
In an environmental consulting environment (not software) all projects except for really big, multiyear government contracts were managed by engineers that were the project leads. That is literally what "lead" meant - the person who led (managed) the project. We only had one actual project manager, and he was as much sales/contract development as anything else.
I was a junior engineer, and I still managed small projects. That included costing, tracking hours/labor, and making sure that deliverables were complete.
Then when I started in software development/operations, I had to deal with non-technical PMs and wasted tons of time explaining why what they wanted was either not possible as specified, or otherwise a waste of time.
IMO, if your PM is not a technical person with expertise in the area of your project, you mare wasting money by paying their salary. Get your lead devs to manage your projects as part of their professional progression. Non-technical PMs are pretty useless.
That sure would be nice. Almost every PM I've work with has actually just been a source of busywork who seemed to view their job as to ensure that the engineers spent as much time on issue management as possible. The only one which actually tried to do it himself had a habit of closing actionable bug reports because the reporter didn't bother giving the useless extra info that the PM asked for, while sending all the useless ones on to the developers.
reply