
Ask HN: As a Product Manager, what can I do to make my engineers' lives easier? - Daktest
As a PM, I believe that one of the things that I should focus on making my engineers’ lives easier. I care deeply about our engineers not having a shitty experience with me as the PM on the project. For example:<p>- I never set meeting times with my engineers that will interrupt their working flow (I love PG’s “Maker’s Schedule, Manager’s Schedule” essay)<p>- I always try to clearly explain the “why” of what we’re doing, provide detailed designs&#x2F;documentation, and remove any blockers when any arise<p>- When possible, I try not to force engineering shortcuts or trade-offs. I prefer that we build features or systems that are well-tested and clean<p>What have the best PMs you’ve worked with done to make your life as an engineer easier?
======
lol131234
The best PMs are those who don't act like managers. Engineers don't report to
Product nor Project Managers. Unfortunately, many PMs act like they are real
managers and bully engineers around.

This only leads to confusion and bad culture. Senior devs don't take orders
from PMs but junior devs usually end up confused and create more issues.

In my 10 years of experience as software engineer, a PM has never forced me or
my team to take any shortcuts or work extra hours to meet their deadline.
Every time we had disagreement, my boss backed me not PM.

~~~
jf22
110% this.

My worst professional experiences have all revolved around product people
pushing aggressive deadlines.

The best shops I've worked at have had product people who are subservient to
technology teams.

Product exists so that developers can focus on code and implementation and not
have to play politics and attend endless meetings.

~~~
mdinic
How do you deal with an issue where engineering provides estimates but does
not deliver even on their worst case? I agree PM/PO should never push. What if
engineering is the issue?

------
natalyarostova
This is more of an attitude but I like it when "we're in it together" so to
speak. Rather than the attitude that I've frustrated or upset you due to an
unexpected system complexity, for example. When people feel like they are in
it together, they are less defensive. I love going to a PM I trust and saying
"hey man we have some problems cause XYZ is harder than expected" and knowing
they will help us work through the problem, find areas to descope, and manage
communication for us.

------
amirathi
Best thing you can do is to bring customer problems to engineers & come up
with solutions together. Far too many PMs create detailed spec documents
(solutions) on their own and throw it over the wall to engineers.

Benefits of this approach,

1\. Engineers get to know more about the customers & their pain points first
hand.

2\. Engineers are bought into the solution as they co-created it.

3\. You usually come up with better solutions as both business and technical
constraints are all on the table.

~~~
Daktest
Great points! What would you do in situations where your engineers aren't all
that interested in customer conversations?

In the past, I've tried to bring in our engineers to user interview/feedback
sessions or customer meetings, but most of them didn't seem that interested in
coming again.

~~~
amirathi
In that case, I would frame the conversation as a problem solving session. You
can do the legwork of customer inputs, cross team talk, management buy-in etc.
And once you zero in on the problem (and have it prioritised) just talk to
engineer and together brainstorm the ways to solve it.

------
muzani
I think it helps a lot when PMs decide on the lines of responsibility.

Like recently we had a project with a lot of mutual dependencies. The app
scans a QR code for access and then access is denied. Who is at fault? The app
developer? The API developer who gave them the code? The guy who integrated
the code? The back end system handling roles?

Is this thing being worked on or is the responsible person waiting on someone
else for a fix?

The lazy approach here would be to adopt scrum, which settles issues like
this, at a great cost.

But I find a good PM makes it clear what the progress of the project is,
without having to bother the engineers for it. They still do things similar to
quick 5 minute meetings, but they slot it into the flow, like when the
engineer gets back from lunch. Something like Trello helps a lot in this
background monitoring, and the good PM encourages them to use it as it's what
cuts down the meetings.

One thing I did as manager was to print out every page of the app, paste it on
a wall, and then tick off whatever was done, whatever was high priority, or
who needed to do it.

It's also important, but much harder, to make sure that the team gets along.
When the team gets along, they communicate. When they communicate, they know
what's going on. This might include posting memes on Slack as icebreakers or
talking about their favorite football match. This might also mean allowing the
team to head down and have a half hour tea break at 4 PM.

------
madduci
\- Give them interesting challenges

\- Make them feel free in boundaries (e.g. allow creativity flow for a period
of time)

\- plan time for personal enrichment (attending conferences, studying new tech
improve in other areas rather than coding)

\- don't make deadly strict timelines that are unreasonable short. Make a
buffer in your estimation

------
algaeontoast
Be exceedingly clear when a given task or project has a hard deadline or when
someone is picking up a task that is likely to halt production if it isn't
completed within a narrow window of time.

Some of my worst experiences have been when my boss got on my case for
something I said would be done in two days as a best case scenario, and then
exploding when I told them I'd need an extra half day for a problem that
showed up and required a change of plan (corroborated by other team members or
the PM).

Or when a PM would let me know they just need a status check, but didn't take
care of backing up my decision with my boss - which also leads to my boss
exploding. Idk, maybe I had a toxic boss in a shitty org?

------
AnimalMuppet
Once you define the features that are going to be in a release, don't change
them unless you really need to. If you do change them, change the schedule as
well. _Never_ add or change features without changing the schedule.

And listen to the developers when they tell you how long things are going to
take. Don't tell them that they can do it faster.

