Feels like it badly needs the reciprocal "How to be a PM that engineers don’t hate". Otherwise it comes across as "Ten things you grunts need to do to make my career go better".
The OP makes some pretty big generalizations:
> A common area for things to get messy is QA. In many agile teams, PMs end up doing UAT or requirements checking before tickets go live... A common way this happens is if the engineering team is much less tenured than the PM, and the PM knows how to test better than the engineers. In any case, PM acting as QA is not a healthy state. If PM is catching lots of bugs in UAT, engineering teams need to re-evaluate their QA strategy and fix the problem ASAP.
Well that's one possibility, but I've never seen it in reality, let alone call it common. Another strong possibility is that the team (PM in particular) didn't spend enough time thinking through use-cases and writing acceptance tickets. And/or that whoever's supposed to be communicating with the customer isn't doing that well. Or indeed that the customer themselves doesn't understand their needs well (in which case quickly getting them an MVP without much acceptance testing is entirely the right thing to do, then iterating - but ideally that should have been budgeted up front, which would be on the PM as much as anybody - and more so if they're "more tenured"). So, less blamespreading, more the team rolling their sleeves up. Especially if the PM really aspires to be a "partner" to developers (as they say elsewhere).
And btw if the "engineering team is much less tenured than the PM" is a recurring pattern, then that suggests trying to scale too fast, or antipatterns in hiring/ development/ budget/ management/ retention/ compensation (for example any developer with half a clue in that org would eventually either aim to get promoted/ jump ship into PM/ quit). The solution isn't always to whip the developers harder. It may be about mismatches in management/ budget/ incentives/ KPI.
Not really, none of the second article's philosophy seems to show up in this article: "Hold Yourself Accountable/ Help With the Dirty Work/ Be an Engineering Management Ally/ Be a World Class Copilot" seems to conflict with their scenario "In any case, PM acting as QA is not a healthy state. If PM is catching lots of bugs in UAT, engineering teams need to re-evaluate their QA strategy and fix the problem ASAP".
Also as commented, the OP makes too many implicit generalized assumptions about the org: that PM and developers report to a similar management chain (that's often not the case, depends on the org) or at least is aligned with compatible incentives. Their throwaway remark "if the engineering team is much less tenured than the PM" and the lack of inquiring about why that scenario might have arisen makes you wonder, too.
No it's not, because that other article absolutely isn't reciprocal, for all the reasons I had already listed above [0], 14 hours before you even wrote this. If you had read the other article, you'd see it flatly contradicts this article. Over there the OP trots out rhetoric like "Hold Yourself Accountable/ Help With the Dirty Work/ Be an Engineering Management Ally/ Be a World Class Copilot", but here moans about (hypothetically legitimate) scenarios where the PM may temporarily have to shoulder a lot of the QA burden (or push back on the customer rather than blame developers, if the customer doesn't understand their own use-case).
Conversely in this article the OP makes cryptic hand-waves towards "As always with power balances, just be gracious... Know that there are implicit power dynamics that should be managed graciously... So, be a good partner...", but what they write feels like they only view it as a one-way partnership, and makes it sound like they don't care if the developers are getting the short end of the stick. Or, they're trying to make a faulty generalization from their personal experience to other orgs where developers and PMs report to different chains and have very different incentives, as again other people here had already commented [1] before your post.
Your comment isn't constructive, and it intentionally misrepresents what I had clearly already written above half a day before you posted it. Please don't do that again. [2]
And I didn't make a "suggestion", I critiqued the OP's absence of having actually written something genuinely reciprocal like they said they had.
Everywhere I have been a PM usually has an engineering team thoroughly battered by poor management, constantly shifting requirements, and is so near burnout I can feel it. I place no blame on engineering giving me inflated timelines when culture sucks. PM positions opening up seem to correlate with problems between the business and engineering. Take true ownership and watch how quick you can get a better relationship with engineering.
It's my job to take true ownership by accepting responsibility for outcomes, pushing back on the business for their short sightedness, and to attempt to drive an environment where respect for the trade of engineering exists. I completely understand the bad rap PMs get on HN. It always feels like I am working for the death star half the time. Though I am always glad when I can act as a blame sponge and slowly turn toxicity around. If you constantly throw engineering under the bus for management problems you are a product manager by name only.
I’m a dev and I’m sympathetic to PMs. In the end the constant change in requirements doesn’t come from them, but from the business. And while I appreciate some don’t do the bare minimum pushback on absurd requirements/demands, I also understand that in the end their career is tied to what the business think of them, not the devs they manage. It’s just the way it is.
This is a big part of the problem; PMs should be managing the product, not managing developers, though it almost always ends up being the latter. The same goes for project managers, who should be managing the project, not the developers.
Though PMs should be working closely with developers, the idea that developers are subordinate to them is pretty silly when, ultimately, their incentives are heavily weighed towards siding with product owners and upper management in general. The role of PM doesn't suggest any sort of qualification for managing developers, thus it makes more sense for developers to be managed by lead or staff developers who report to directors of technology or product owners. Unfortunately, this can be dysfunctional because roles like "lead" are often given to those who don't have good leadership or management skills. However, it still makes more sense that developers are lead by developers who answer to whomever owns the product. When you add a PM in the middle, they often act more as a blame-diffuser when their actual job should be like an interface between developers and the business, and to provide some amount of defense for the developers they supposedly manage.
I recently had a failing team put under me. They all have what I would consider PTSD. I often see the opinion that leadership doesn't matter, but poor leadership is one of the main of causes failing teams.
Knowing it would barely help you. Both titles are amongst the most overused in the industry. They can mean widely different things in different companies.
1. Agree what jobs need to be done as a team, and who’s doing them. Think RACI matrix. If you disagree over roles, consider breaking down the responsibility into smaller parts until you can agree.
2. Engineers should understand the strategy. How are you acquiring and retaining customers, and what are the biggest issues there? How are you spending money? What are the risks?
3. PMs need to think about NFRs. Instead of the common “tech debt vs features”, break work into customer-facing and internal-facing. If a feature is about decreasing latency by 200ms, for example, that’s customer facing.
4. Engineers and PMs need to empathise with each other. PMs typically lack control, but are at the coal-face receiving demands and complaints from everyone but unable to directly do anything about it. Engineers have to deal with huge complexity in areas they often know little about. Understand each other’s problems.
5. Have more effective meetings. Use them for answering difficult questions that need debate. For imparting huge amounts of info in one direction, record videos or write documents.
6. Be honest and transparent. Challenge each other where there is ambiguity until you are all ready to fully commit and prepared to be held accountable for delivering the same goal.
7. Build a decision-making framework that you both follow. This can be particularly effective with work intake.
8. Keep the focus on moving KPIs, not delivering features. Align around a few product and engineering metrics and concentrate on them relentlessly. Regularly review the case for all in-flight work.
> don't micromanage (sending IM messages to repeat something already in an email or ticket for example)
> respect the experience of your engineers. don't patronise them.
> take responsibility for YOUR project. don't expect engineers to do anything other than exactly what is requested. and no more.
> remember that you are the PROJECT manager and not dev manager. don't overstep your position.
> don't make negative assumptions about people. if something is delayed or slow ask why. don't just assume the worst about people.
> don't wait until production to check things properly. ultimately it is your project and you're responsible.
> don't expect engineers to answer question that was not asked. be thorough in your requirements. don't make assumptions about prior knowledge.
> don't editorialize or edit what the engineer has written. put in your own words if needed. don't eliminate the engineer from a discussion. they are a human too not some basement dwelling ogre.
i have much more but my brain is tired right now from spoon-feeding ungrateful PM's.
Wow, a few of these are like the blueprint for dysfunctional teams. Engineers only do exactly what was written in requirements and don’t answer any questions that weren’t asked? Then why even have your own engineers instead of outsourcing to the cheapest Indian shop you can find? Or is that the arrangement you’re intending to describe?
> Engineers only do exactly what was written in requirements
It's a balance question.
Because on the other side of that coin, are requirements that are nebulous enough to be interpreted as a technical document describing everything between a calendar app to a rocket engine, a cooking recipe, or the prayer mantra of a futurologist cult.
Sure, engineers can "work" with that, which means they have to implement AND design the product as they go. Which usually ends in a mess for all parties involved.
So yes, engineers are within their rights to demand actually useful specs, that clearly outline what the goal of the work is. That doesn't mean they want every step of the way described in minute detail. As I said, writing good specs is a balancing act.
Of course employers are also welcome to instead take a broken spec and try to outsource it to somewhere. Only, they should be aware beforehand that the cost of hiring freelancers to fix the outcome of such experiments, often exceeds the rate of inhouse guys by quite a significant margin.
"Sure, engineers can "work" with that, which means they have to implement AND design the product as they go. Which usually ends in a mess for all parties involved."
IMO that can work as long as engineers are experienced enough, and expectations are set on both sides.
PMs will have to accept an iterative process where people gotta keep refining to get to an ideal state. And Developers will have to accept that "iterative" means you'll constantly have to re-do work or throw away stuff.
But if either side can't accept that, you'll end up with a mess alright.
I agree. The OP is basically saying the engineers need to go off and do only their interpretation of a ticket with zero responsibility, while the PM is fully responsible isn't allowed to ever question engineers. Outside of the clear problems of lack of trust, the items when taken as a whole are how to destroy a team and fail a project.
As an engineer, I would not want to work in a team that works the way you seem to paint as ideal here.
Especially "don't expect engineers to do anything other than what is requested".
Engineers and PMs are "partners in crime", they have to collaborate with their skills complementing one another, bounce ideas around to find the best outcomes. Many good engineers also have a good grasp of product. Having a mindset where it is always PMs "requesting" and engineers "deliver only what is requested" -- in such an environment I would (as an engineer) find a new job.
> don't start with "that shouldn't take much time, right?"
Unless you are a PM that is also making non-trivial code contributions, let the people who are actually getting their hands dirty on a daily basis provide you the estimate. What seems simple can be complex to implement or vice versa. Asking presumptive questions like this only insults the engineers knowledge of the system and usually they are smart enough to see such underhanded pressure tactics from a mile so it only diminishes respect for you in their eyes.
Just ask it straight: "how long do you think this will take?" You'll get plenty of time to question the estimate and the engineer would be more than happy to take you though the code/config to explain why what seemed simple isn't so, assuming you are genuinely interested in understanding the rationale.
> don't expect engineers to do anything other than exactly what is requested. and no more.
> don't expect engineers to answer question that was not asked. be thorough in your requirements. don't make assumptions about prior knowledge.
The inverse unfortunately describes just about every PM I've had to work with. Good developers should be asking questions to fill in any gaps in requirements that aren't likely to be considered by non-developers, but it ultimately shouldn't be their responsibility to figure out the requirements. If a PM can't provide useful feature requirements, then they probably should be fired.
Here's how things typically go:
- PM comes back from meeting with product owners and writes a bunch of tickets with a title and single sentence like "do the thing."
- During backlog grooming, engineers are forced to ask the PM to provide more context and acceptance criteria. The PM pulls some AC out of their ass. Because the grooming is capped at an hour, all AC and behavioral descriptions are half-assed, and contain contradictions. Developers are burned out from constantly wondering WTF and just want to get out of there. Most if not all groomed tickets are wrong in some way.
- PM meets again with product owners and designers to discuss changes to features being worked on. PM fails to update most of the tickets that relate to said changes. Designers, who seem to usually work outside the sprint process, make changes to their mockups without notifying developers. Developers stumble across changes to the mockups midway through developing a feature and go "WTF?" Or they've already submitted a PR and another developer notices that the work doesn't match the mockups.
- Developers have Zoom meeting with PM and designers to ask "WTF?" Nobody takes responsibility. PM pretends to clear up ambiguity by taking suggestions from the developers and changing the AC of the ticket. Designers pretty much roll over to whatever the group decides because they just want to get out of there.
- PM presents merged feature to product owners. Turns out the PM didn't read their minds correctly, and so follow up tickets are filed. Some of those tickets vindicate the developer's concerns or revert changes made to the AC during the sprint.
- Developers are told to "ask more questions" in order to "close the loop" during sprints so that this circus doesn't happen again, passing blame to developers and further guaranteeing that the circus continues.
> Turns out the PM didn't read their minds correctly
that's what frustrating. why should the engineer ask the pm to ask the product owners to flesh things out.
pm has a responsibility to understand product requirement fully - outside of technical limitations. otherwise they are just a glorified middle man. just let the engineer speak to the product owner.
this is why i say don't expect engineer to answer questions that were not asked. why should we take that burden and blame.
consider the engineer as someone providing a service, like someone else commented "outsourcing to india" - yes in a way you are outsourcing to an engineer in your team.
if a PM doesn't understand a project, then why are they managing it. they should be title "email or communication facilitator" or something like that instead.
So you're saying that there should be someone between PM and the customers? That's just way too much indirection IMO.
Also engineering has not been "a service" anywhere I've worked and engineering typically has done QA as well, without an independent team. Product owner is whoever is ultimately responsible for what the product will do. Often it's PM, but on a lot of teams it makes sense for it to be engineering, especially if it's a product for other engineers.
> > remember that you are the PROJECT manager and not dev manager. don't overstep your position.
This suggestion really applies to both, but I just wanted to note that article is talking about product managers, and specifically recommends against making them project managers.
> Don’t make PMs hound you for information. Be proactive. When PMs do ask you for information, answer promptly and graciously
At a previous consulting engagement I ran across a rather toxic triangle involving the PM, the developers, and the manager of the developers. The PM did not report to the engineering managers, she reported up the chain elsewhere. The engineering manager made if very clear that bad news was not welcome from developers, and only the mildest concerns about risks and blockers was tolerable. Thus, the developers could not give the PM, or anyone, honest information without risking the manager's displeasure.
Which is all a long way to say: If PMs are seeing issues with communication from engineers, first eliminate the possibility that the developers are doing so because that's how they are managed.
> As always with power balances, just be gracious.
> Know that there are implicit power dynamics that should be managed graciously...
> So, be a good partner...
But that's assuming like you said that in the organization, developers and PMs have similar reporting chains. The OP doesn't entertain the possibility that orgs and incentive structures might differ.
Unfortunately true. Then when it all goes south, they are like "oh well, we tried". People really don't understand how hard it is to do something right, you know, the kind of things customers love and will stay in line to buy it. And when an engineer (an actual one) points out some flaw they immediately call him a jerk.
I never understood what people mean by "a jerk/asshole": sometimes they mean an actual jerk but a lot of times it seems to mean "people that don't agree with me".
I worked with many people I disagreed with. We would debate endlessly over how to solve an issue. I've worked with a few people who were assholes. They would lose their cool if anyone disagreed with them, and start threatening, calling names, etc...
I've been in a couple situations in my career where physical altercations even occurred.
Haha...let me just say that small companies fighting to stay afloat cause an enormous amount of stress. Every decision is scrutinized and debated. Egos flare and you end up with physical altercations.
Probably the most serious altercation is from the late 90s...the co-owner walked into a meeting, after yelling at the other co-owner for awhile, people stood up and the one co-owner knocked out the other. The one who threw the punch left and we never saw again.
Clear boundaries are important too. It isn't my job, as an engineer, to remember everything you requested. It's also not my job to know exactly what your corner of a platform looks like.
And it's especially not my job to negotiate against your constant attempts to creep a task's scope whenever we run into issues stemming from you not knowing your own platform and process well enough.
"It isn't my job, as an engineer, to remember everything you requested"
It's not your job to remember, but it is your job as a human being to set expectations about your favored communication style in a professional manner.
If you need something written down in an email or Jira task or whatever, for example, so you don't have to remember, you should ask for it.
If you think scope creep is a problem and don't want to keep negotiating (something very reasonable to ask for), you gotta communicate about this problem in the appropriate channels.
Well, if it's the same person denying change it without a counter-argument, then there's no solution other than changing teams or company.
If it's a string of PMs, all being unreasonable, some self-reflection might be necessary. Maybe the problem is not with their work, but with your expectations.
Sorry, you're right, that wasn't clear. It isn't my job to remember the history of every request your team has ever submitted to my team.
If you have a custom process that we don't know about or that your predecessor requested of my predecessor, I don't expect to be aware of that. And when it causes issues, I don't see why that's my fault
As an engineer, I consider all those those very much my job.
"Negotiating against" scope creep maybe not quite, but it is my job to provide decent time estimates for expanded scope so they can decide if it's worth it.
To be fair, I'm coming from a place where I have familiarity with pretty much our entire platform. If I were new, or delving into some aspect I haven't worked on before, I'd expect some understanding that it's going to take me time to familiarize myself with it, but I will familiarize myself with it in order to work on it. If the PM is an expert on that area, they should be willing to take the time to answer questions.
Have a solid software development background. There is a tacit understanding that nobody absolutely needs a PM, which leads to a lack of respect for the position. The best way to even that out is to show you understand where developers come from, but if you do not have a software background, this is far harder to pull off in a credible fashion.
The best PMs/managers I have had are the ones that were good/decent (but usually not incredibly amazing/gifted) programmers; they understood when we said it'll take time and adjusted things to balance the delivery with amount of work/effort.
However, a few others didn't have the technical background but took engineers into confidence and generally trusted/supported engineers when they pushed back on specific points. They knew what they lacked and treated engineers as partners that fill that gap.
For both kinds, the above actions made them earn the trust of the engineers which means that when these PMs/managers, (occasionally) said "this must go", they had the necessary support from the engineers. So I guess the common factor is that it was their standing up for the engineers and honest actions that earned the trust. To repeat the cliche, words are cheap, show me actions.
Being sort of a PM (as a BA) back in the day for one year, I sincerely believe PM should come from engineering but with solid understanding of product too. The best way to hire a PM is to grow your own, by moving an engineer to the business side for one year (or 50-50 for one year) and then give him/her a bigger salary.
The articles content is good, but the framing feels antagonistic. This is reflected in the defensive posture of many comments here, and I believe it comes from a significant percentage of developers never having even seen what a healthy cross-functional team actually looks like!
The two elements are competence and trust. Not everyone has to be perfect, in fact mistakes will always be made, but there needs to be willingness to address problems and stretch a bit to cover up one anothers gaps. Without that baseline competence and trust we get into finger-pointing and not-my-job territory where it becomes impossible to achieve anything non-trivial.
Ah, you used the A-word here. Why do you think the process you described in your article — especially this part: "Because PMs are most active at the start and end of projects - handing the steering wheel to engineers to execute and picking it back up when code is complete to deliver downstream" — is agile?
It's also not exactly "QA" in this case, it's more close to just validating things every once in a while...
Especially if the specifications aren't clear and "atomic" enough, a lot of implementation mistakes will slip in.
If a product manager is the one creating those specifications, they're the main ones who should be going around the product verifying if they're correct or if they actually "work" in practice. Developers and QAs can do it too as part of their job, sure, but it won't be as effective unless specs are ultra-clear, which they often aren't.
If your PM doesn't use your product enough to know every single bug then they don't understand or feel your customer/user pain. Ideally when they experience a bug there is already a ticket created that they can simply prioritize. I have a deal with my QA team: On every new build once they've gone through it, they pay me $10 per bug with no ticket. If I don't find any undocumented bugs then I buy lunch.
> The TLDR here is that PMs should not be running all project meetings. Engineering managers, IC project leads, or tech leads need to be managing engineering execution, not PMs.
I think this is a big one. Actually, in a way, maybe PMs shouldn't be termed "managers", but instead: liaisons. Maybe that'd reduce the implied power dynamic? I reckon ICs should pipe up more often. It's so upsetting to be in a meeting where there's a bunch of bored or irate engineers just begging through dulled eyes to get back to their desks. Nobody ends up happy. Everyone's bitter. Maybe if people saw the incentives of PMs more clearly, and vice-versa, there'd be more alignment and less bitterness? I've been on both sides of the equation and it's so interesting how immediately tribally entrenched one becomes. Same with scrum-masters.
Yep. Good and clear communication is also a neat trick to not being hated by technical managers, stakeholders and other teammates.
The older I get, I find this more important than technical skills. Technical skills are fixable by training, mentoring, or simply asking me.
I've seen bad communication causing delays, misunderstandings of business needs, developers who can't level up, and, in the extreme, fights between team members.
While this is a very good start and me having that skill helped me a lot, we should not forget that many PMs and all sorts of managers simply love changing requirements after just one call with the CEO or the finance department.
...And then they "forget" to tell you that they changed the requirements. And have not written down that anywhere.
...And then that happens 4 more times.
...And then a month later it's the engineer's fault that he's not part of the hive mind and does not read thoughts.
So I don't disagree, communication and other soft skills are certainly invaluable. But they don't filter out bad manager actors.
In my opinion this is a mind set problem. If you frame issues so it is an us-vs-them problem then perhaps the real issue is how you have framed the problem. I worked in a car factory (a very long time ago) when the war between management and workers was at the height. They were enemies, to the extent that workers would silently watch while management teams directed repairs to the wrong place. Those factories, which operated out of that mind set are long gone.
If this article applies to you, you might consider that the system in place to produce software is fundamentally broken.
When thinking about the technical and non-technical people I've worked with, ignoring technical prowess, it feels to me like the technical people had slightly higher general intelligence on average. Certainly the upper bound for what I perceive as general intelligence was far higher for the technical people. Of course, this isn't to say they were universally more intelligent, far from it, I've worked with some extremely sharp business guys. I've just felt a slight correlation in aspects like vocabulary, mental arithmetic, logical reasoning, etc, in favour of the tech people I've worked with.
All of this is qualitative opinion-based anecdata, but it is something I have noticed. Certainly it's no excuse to have an inflated ego about knowing more HTTP status codes than the accounting team.
The OP makes some pretty big generalizations:
> A common area for things to get messy is QA. In many agile teams, PMs end up doing UAT or requirements checking before tickets go live... A common way this happens is if the engineering team is much less tenured than the PM, and the PM knows how to test better than the engineers. In any case, PM acting as QA is not a healthy state. If PM is catching lots of bugs in UAT, engineering teams need to re-evaluate their QA strategy and fix the problem ASAP.
Well that's one possibility, but I've never seen it in reality, let alone call it common. Another strong possibility is that the team (PM in particular) didn't spend enough time thinking through use-cases and writing acceptance tickets. And/or that whoever's supposed to be communicating with the customer isn't doing that well. Or indeed that the customer themselves doesn't understand their needs well (in which case quickly getting them an MVP without much acceptance testing is entirely the right thing to do, then iterating - but ideally that should have been budgeted up front, which would be on the PM as much as anybody - and more so if they're "more tenured"). So, less blamespreading, more the team rolling their sleeves up. Especially if the PM really aspires to be a "partner" to developers (as they say elsewhere).
And btw if the "engineering team is much less tenured than the PM" is a recurring pattern, then that suggests trying to scale too fast, or antipatterns in hiring/ development/ budget/ management/ retention/ compensation (for example any developer with half a clue in that org would eventually either aim to get promoted/ jump ship into PM/ quit). The solution isn't always to whip the developers harder. It may be about mismatches in management/ budget/ incentives/ KPI.