How to Be an Engineer That PMs Don't Hate
staysaasy.com
staysaasy.com
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.
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.
The link to that exact article is literally the first sentence of this one.
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.
[0]: https://news.ycombinator.com/item?id=36466224
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.
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.
Out of curiosity, did the P in your role stand for "product" or "project"?
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.
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.
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.
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 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.
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.
PM is the product owner by proxy for the stakeholders.
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.
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.
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.
What kind of value did this person provide to the organization? Plausible deniability?
Easy-peasy. Always agree with their estimates, never complain, never ask for a raise, work additional hours.
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've been in a couple situations in my career where physical altercations even occurred.
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.
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.
Could you clear this up a bit? If the PM makes a request to you, who's responsibility is it to remember it?
It's both people's job to talk to one another to ensure the captured request is correct.
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
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.
> you gotta communicate about this problem in the appropriate channels.
After years of repeating myself I have quite frankly given up. No one listens and nothing ever gets better on this front.
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.
"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.
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.
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?
Hard disagree.
The PM shouldn't be finding a lot of bugs, when theyre not doing QA then a lot of specification bugs inevitably slip into production.
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.
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.
That's for sure valuable skill which gives you advantage over other engineers, or to say people in general :)
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.
...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.
If this article applies to you, you might consider that the system in place to produce software is fundamentally broken.
Pretty obvious to state, but this is generally a good thing to live by in and out of the office.
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.
It gets old being condescended to by someone who is lower paid, lower skilled and whose job is to pedantically follow a checklist.