Hacker News Reader

Comment by ng12 | Hacker News Reader

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.

I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let them have it.

A big part of the problem in my experience is that PMs tend to proliferate. I've seen many startups go from hiring their first "product" person to suddenly having a PM team that's a third the size of engineering.

View on HN

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed.

If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in a large org that pushes those menial tasks onto engineers. PMs are there to facilitate engineers. They do not rule over them. They make targeted, efficient queries of engineers' status and then communicate and coordinate appropriately.

I would love to see PMs hired at my org. We're currently drowning in process-related tasks and it's mostly because we do not have PMs(the process is mostly necessary, but wastes engineer time). I'd also love to have some technical writers on staff. Having engineers write documentation, beyond, say, doxygen comments in header files, is just dumb. Right now our user facing docs have little consistency or defined scope. They don't target a well defined audience, and don't effectively communicate to our users.

Let engineers do what they do best, and enable them to be productive by hiring helpers as needed.

I feel like a good PM is someone who makes sure everyone is on the same page and working towards the same goal. If they are good at their job, you dont notice them.

Otoh If they are bad at their job, they really get in the way, cause a lot of resentment and extra busy work.

The end result is selection bias - lots of engineers think they are useless because you only really notice the useless ones.

We used to have 3 PMs in our team of 20ish people. Two of the PMs left and NOTHING changed for us or our project.

The idea of being relieved of process-related tasks is nice, but it rarely happens. You get pulled in to those timewasting meetings by your PM anyway.

A good PM, yes.

But IME, most are not.

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 said it upthread but I'll say it a little differently here. The PMs do lots of valuable work that allows us to do our work well (and prioritize it so that we're doing the right work).

If they're subject matter experts, that's best - they're your translator/interpreter, able to speak in terms of both tech and the problem domain. And they know what the user wants because they were the user of your competitor.

But even if not, they can be the best assistant you'll ever have. Dealing with customers, sales, higher-ups, etc. so you can focus on your work. Technically they may be above you in the org chart, but you can't have a better assistant than a good manager that gives you what you need, clears the way, and runs interference so you can work doing what you do best.

This!

Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc.

Yet, the product manager position isn't really staffed, and neither is the project manager one. So, all the additional work beyond design and coding also falls on the owning engineer. And since we are frugal that engineer is happy to get maybe 1 additional engineer assigned to help. But often that one will also have their own project they own or need to prepare for owning.

So the lead/owning engineers turn into mostly product and project managers but are still expected to do the down to earth construction of the product which means to get anything done in the expected time frame engineers need to put in long hours.

I just don't get it. It seems utterly wasteful use of resources. I'm not saying engineers cannot be good at these things, but generally speaking product and project managers cannot and do not need to be able to code in addition to owning a project/product. Adding/hiring more project managers to projects would be the single most effective way to speed up project timelines as it frees the engineers, the producers of tangible product deliverables to focus on that.

In no way do I mean engineers should be cloistered away from dealing with product or project decisions or even chatting with users. But it needs to be in the correct proportion to the actual engineering work.

Add to that the addition of duplicate processes (e.g. we are dealing with 3 right now that cover the same ground but are ever slightly different in what needs to be done to cause triple effort) and everything grinds to a halt. A project manager could also be the right person to push back on management and dedicate resources to improving project management overall.

> Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc.

This is why I like the way the linked article put it: you can lose most PMs without sacrificing efficiency. I would imagine a great deal of this stuff isn't actually important and only hampers the team's velocity. A PM will make it their job to make sure it gets done, if there is no PM the unimportant stuff will fall by the wayside.

> A PM will make it their job to make sure it gets done, if there is no PM the unimportant stuff will fall by the wayside.

You will always need to spend some time project managing your project even when things are not as process heavy.

You still need to make sure that timelines are met or flag if they are not. Keep dependencies informed, push/remind other teams you depend on to fix a bug, add the feature they promised. Communicate with management to get more resources, etc.

A PM can do all of those things with a bit of input once in a while from engineers.

These things only aren't important if you neither have timelines to meet, have no dependencies, and aren't accountable for the success of your project. Outside a hobby project outside work I'm not sure we ever have that luxury.

The article doesn't talk about other roles, so maybe where OP worked these things would have been assisted by other roles, e.g. the product manager. Maybe from that perspective it's not clear to the engineer what value project managers provide but I feel it's a bit of a limited perspective to say a role that can dedicate their time to tasks of type X isn't of benefit to those who'd otherwise need to do these tasks.

I mean would you say the same about customer support? About getting clarity on compliance/legal/finance (via asking external council)? About internal developer tooling? There's a point where an engineer working on a product may need to do all these things in addition to the building. But you cannot claim that it'd make no difference to the engineer's efficiency if they could delegate those things to others.

>A PM keeps management apprised of progress.

In most places, project managers save managers time by not requiring managers to spend their time figuring out the progress of things. However because PMs have more bandwidth they take up even more engineer time than managers would.

IME a PM takes time at the beginning of the project to define tasks, dependencies, and time estimates. After that, you meet with them formally once every 1-4 weeks as a team to update the schedule, along with an informal, individual chat as needed for critical tasks and late dependencies. It took a lot less time than the useless daily standup meetings I now attend.

Most of my experience with PMs was at smaller orgs with smaller teams. Now that I work at a large valley company with layers of antagonistic management, I appreciate my former PMs more than ever.

It's important to hire good PMs without huge egos or career aspirations. Being a PM is kind of a shit job and it's not about wielding power or authority over people. You also need PMs who understand the uncertainty baked into software estimates, and can cope with unforeseen problems requiring schedule juggling.

> It's important to hire good PMs without huge egos or career aspirations.

This is so important. PMs are there to serve management and engineering, not the other way around. As soon as you have PMs who are trying to boost their own profile, you're screwed.

See much of FAANG over the last five or so years for a number of good examples.

If you're hiring more people to deal with rote, managerial "process" you're already lost in a mire of inefficiency.

I think it is important to point out at this point, that product managers and project managers are two different jobs. Yes, neither writes code, but the product manager focuses on which features are most important for the customer and therefore needs to know a lot about the product and what makes a good product.

Project managers, on the other hand, can be used even if there is no product. They require good people skills and (should) make things work, while having some knowledge about tools/methods that could enhance the job.

If you think SCRUM, the project manager is closest to the scrum master (someone who cares about impediments and methodology) and the product manager is likely to be the product owner (prioritizing and describing features).

However, project managers can be used for all types of assignments as long as they have a start and an end ;-)

The linked post said project manager.

Good PRODUCT managers, in small numbers, are worth their weight in gold IMO. Researching/talking to users takes time, making decks takes time, stepping back and surveying the landscape takes time. It's worth having someone doing that.

Oh god, I hate the PM abbreviation. Product managers and project managers have a bit of overlap (as the former also do project management to an extent, just like engineers), but they are different and having them provides different benefits. Why do we abbreviate both with PM? I never quite know which is referred to.

Don’t forget “program manager” too

Oh god, yes.

We should really start using PdM, PjM, PgM as disambiguation in contexts where that’s necessary

The engineers that believe they would thrive without managers are likely the ones managers exist for.

It is simply absurd to believe that companies throw away billions down the tube for useless work.

Sometimes it is the customers that need shielding from the engineers.

I remember a situation where defcon was raised to 2 when the head of our unit found out that a particular engineer went to a meeting with a particular customer on his own.

I believe, that many project managers are actually bad project managers. And that is not so much their fault as project managers are being trained on methods big time, but then again then job they have to do is not just executing these tools somehow, but to understand the dynamics in larger organizations and to act accordingly. But many project manager just learn the tools and methods to perfection and try to bring their cure to everyone by prioritizing method adoption, when many times the missing methods are not the most important problem.

So many times there are politics and emotions part of the broken communication that causes quite a lot of havoc these days. So instead of teaching developers how they have to work project managers should focus more on how to foster collaboration and use their people skills to reduce friction between people.

Having a good idea of exiting methods can be advantageous, but should never distract from the first priority to actually help the people who do the work, as good as they can.

Reply on news.ycombinator.com