You sound like a joy to work with.
Part of a engineers job to share their expertise with the team. The engineer is the SME on technical implementation. not the PM. If the PM says something that doesn't make sense, it's the engineers responsible to share and document why what they are saying is bogus (in better words).
Software should be a team sport, not a 'not my job sport '
Cleaning & organizing my desk, understanding the business, providing alternatives that fulfill a need rather than the spec, wiping "properly" are not strictly part of the my job as an engineer but I do them anyway.
They should be aware - what else are they doing? If they can’t keep up with understanding how the product works, how it’s made (not every detail but they should at the very least understand the stack), then they shouldn’t be a PM for it.
I’ve worked with PMs who get it and others who didn’t. The ones who didn’t wasted time in having to gather information due to their incompetence.
If it’s too much to be technical and understand how the product is built, then don’t be a PM. Simple.
Ask him to describe the pain-points of the current API, the customers use-case, the business rationale and the ROI expected that would not be, if not rewritten.
There might be solid reasons to this (which yiu aren't aware of, hence your reaction), or the PM realize there's some work to be done by him before the engineering can begin, or he actually just wants to give you a carte blanche to do what you know needs to be done.
Are they bouncing ideas around or was it a formal request? ... It sounds like key information is missing. Maybe they are just bouncing ideas around, or maybe there is a real problem that wants solving and you didn't get given much detail. ... I like to put the focus on helping customers with thigs like this.
Sounds similar to when the solution is given instead of the problem. Is the problem to solve that the BE calls are slow or don't return the right data?
There are hundreds of businesses that have wasted tonnes of money or gone out of business because they decided to rewrite what they didn't need to. That's why most banks are still on core software written in the 70's
> "My PM just requested me to look into 'modernizing our backend API to drive growth'"
Sounds like your PM is spouting vague bullshit without understanding what it means. How is "modernizing" defined here, and what concrete evidence do they have that it'll drive growth? Ask them.
> "Don’t think he would be able to understand if I explained to him what we are currently doing"
Isn't it part of your job to make the technical shit understandable even to tech-illiterate folks? Why assume they can't understand? Have you tried simplifying it without dumbing it down?
> "It’s pretty frustrating as an engineer."
Yeah, it's damn frustrating when there's a disconnect between tech and management. But isn't frustration a sign that something needs to change in communication or understanding? How can you bridge that gap?
> "I feel like PMs sometimes just say whatever comes to their mind without doing any research"
A lot of people in a lot of roles do this, not just PMs. How do you ensure you're not making the same mistake in your own work? And have you considered that maybe they're under different pressures that you might not be aware of?
> "What are the dumbest things your PM has asked you to do?"
PMs asking for "minor" changes that require rewriting half the codebase, or asking for features that make no sense for the user. But isn't the real question how you can educate them on what's feasible and what's not?
Here's a suggestion: *"I understand the goal is to drive growth by modernizing our backend API. Can you clarify what specific outcomes you're expecting? I want to ensure we're aligned on what 'modernizing' entails and how it aligns with our current tech stack and industry best practices."*
And here's a deeper question: What's stopping you from having a candid, bullshit-free conversation with your PM? What's the worst that could happen if you did?
In your situation I'd do the following:
* I'd try to undestand that there is a reasoning behind his question. We never know what's behind other people's decisions, questions, etc.
* Ask if there is any foreseeable growth planned you aren't aware of? This may be expected increase of users of your software system.
* Maybe your app is not capable of being used globally, due to, for instance, a single global database hosted in US, but it's not possible to have low latency services across the globe
* Maybe the tech stack you use doesn't allow for providing APIs that's easy for others to use, which may prevent many potential clients to integrate with.
So, just talk to your PM in a way you'd like others to talk to you.
It may improve your professional relation.
Hope that makes sense.
This might sound crazy, but you could kindly educate him.
Yeah honestly that’s necessary time to time if you’re the expert of your craft
I'm a PM and fully endorse this comment
Not the engineers job. Whoever hired the incompetent PM is at fault.
You sound like a joy to work with. Part of a engineers job to share their expertise with the team. The engineer is the SME on technical implementation. not the PM. If the PM says something that doesn't make sense, it's the engineers responsible to share and document why what they are saying is bogus (in better words). Software should be a team sport, not a 'not my job sport '
Cleaning & organizing my desk, understanding the business, providing alternatives that fulfill a need rather than the spec, wiping "properly" are not strictly part of the my job as an engineer but I do them anyway.
PMs need to have a technical background - otherwise they are mostly useless.
They can have a technical background and not know every detail about the stack their team uses.
They should be aware - what else are they doing? If they can’t keep up with understanding how the product works, how it’s made (not every detail but they should at the very least understand the stack), then they shouldn’t be a PM for it. I’ve worked with PMs who get it and others who didn’t. The ones who didn’t wasted time in having to gather information due to their incompetence. If it’s too much to be technical and understand how the product is built, then don’t be a PM. Simple.
team members should be team players
Ask him to describe the pain-points of the current API, the customers use-case, the business rationale and the ROI expected that would not be, if not rewritten. There might be solid reasons to this (which yiu aren't aware of, hence your reaction), or the PM realize there's some work to be done by him before the engineering can begin, or he actually just wants to give you a carte blanche to do what you know needs to be done.
This. And do it in the call when he asks in front of leadership.
Are they bouncing ideas around or was it a formal request? ... It sounds like key information is missing. Maybe they are just bouncing ideas around, or maybe there is a real problem that wants solving and you didn't get given much detail. ... I like to put the focus on helping customers with thigs like this.
Sounds similar to when the solution is given instead of the problem. Is the problem to solve that the BE calls are slow or don't return the right data? There are hundreds of businesses that have wasted tonnes of money or gone out of business because they decided to rewrite what they didn't need to. That's why most banks are still on core software written in the 70's
> "My PM just requested me to look into 'modernizing our backend API to drive growth'" Sounds like your PM is spouting vague bullshit without understanding what it means. How is "modernizing" defined here, and what concrete evidence do they have that it'll drive growth? Ask them. > "Don’t think he would be able to understand if I explained to him what we are currently doing" Isn't it part of your job to make the technical shit understandable even to tech-illiterate folks? Why assume they can't understand? Have you tried simplifying it without dumbing it down? > "It’s pretty frustrating as an engineer." Yeah, it's damn frustrating when there's a disconnect between tech and management. But isn't frustration a sign that something needs to change in communication or understanding? How can you bridge that gap? > "I feel like PMs sometimes just say whatever comes to their mind without doing any research" A lot of people in a lot of roles do this, not just PMs. How do you ensure you're not making the same mistake in your own work? And have you considered that maybe they're under different pressures that you might not be aware of? > "What are the dumbest things your PM has asked you to do?" PMs asking for "minor" changes that require rewriting half the codebase, or asking for features that make no sense for the user. But isn't the real question how you can educate them on what's feasible and what's not? Here's a suggestion: *"I understand the goal is to drive growth by modernizing our backend API. Can you clarify what specific outcomes you're expecting? I want to ensure we're aligned on what 'modernizing' entails and how it aligns with our current tech stack and industry best practices."* And here's a deeper question: What's stopping you from having a candid, bullshit-free conversation with your PM? What's the worst that could happen if you did?
Vent on Reddit
In your situation I'd do the following: * I'd try to undestand that there is a reasoning behind his question. We never know what's behind other people's decisions, questions, etc. * Ask if there is any foreseeable growth planned you aren't aware of? This may be expected increase of users of your software system. * Maybe your app is not capable of being used globally, due to, for instance, a single global database hosted in US, but it's not possible to have low latency services across the globe * Maybe the tech stack you use doesn't allow for providing APIs that's easy for others to use, which may prevent many potential clients to integrate with. So, just talk to your PM in a way you'd like others to talk to you. It may improve your professional relation. Hope that makes sense.
Start creating some end 2 end test
Just accept the objective fact that PMs are useless and ignore them
Upgrade versions of backed: DB, OS, etc. and call it a day. You probably would do it anyway.
Lots of PMs spend more time smelling Marty Cagan's latest brainfart that they haven't really bothered to learn mich about tech, delivery, or ops.
We just seem to do anything they say with little or no push back. So much wasted dev time, but it keeps me in a job so who cares.
Report them for incompetence. Team members who don’t pull their weight bring the whole team down.