So a product manager asks you to fix a bug… | Hacker News Reader

So a product manager asks you to fix a bug…

medium.freecodecamp.com

15 pointsajallow8 comments

Actually, our job isn't to create software that works.

Our job is to add value for the company.

Also, we should follow the chain of command. Product should never talk to individual coders, they should talk to managers. Every time Product Managers can ask for individual bug fixes for problems to coders, unless you don't have a manager, the organization is not functioning correctly.

That reinforces beurocracy. My experience is that kind of chain of command does slow down progress. I had many fruitful and actionable discussions with product. That might maybe be unique to my situation, but i have seen how others got slowed down due to lack of direct communication.

No, in a well functioning organization, you should always have something on your plate like a feature you're working on or a production fix.

Sure, product can come in and ask you about how long (roughly) it might take to get something done, or what would be involved.

But, at the end of the day, you're working on something right now, and that's what your team and product has agreed is the most important thing at the current moment.

Context switching costs time. And product is really good at coming in and convincing you that whatever you're currently doing is "not as important" as what they currently want done.

That way lies madness. Unless you can get agreement from your manager that what you're currently working on is in fact less important, continue on what you're currently working on. Unless of course you're currently on call, and expected to be interrupt driven.

Otherwise you're answering to like 4 people, each of which has a slightly different idea of what priorities should be.

The assumption of manager making the best decision on prioritization is faulty. Priorities change, manager is busy, manager is not the one working on a project so may not be in the position to make the best decisions. Product always dont come with the brightest ideas. Eng could come up with much better ideas, as it should, and should be in a position to drive that product end to end, when necessary.

What i am trying to say, sure people think what they ask for is most important thing to do, but eng has their own thoughts, and they can / and should be able to prioritize. You should not commit to your priorities months in advance. If you think something is not important, you push back. If it's important and you agree, you do it. If some new project comes in, you reprioritize your own stuff - it might just take a day or two to implement and could prove to be of big impact.

Manager will ask the eng what he think of the project, and then there will be discussions, meetings, requirements, formal processes, which will not only kill the mood, but also will slow down the projects significantly.

No, you are not interrupt driven.

You do not get to interrupt engineers, especially if engineering has prioritization meetings every two weeks.

Don't bother engineers to tell them what they have to do RIGHT AWAY. That's been determined already.

If product doesn't have visibility two weeks into the future, what good are they?

oh the meetings. I have seen engineers got stuck into them, because someone decided that it should get priority at the beginning of the quarter, and management wants to check the boxes on the spreadsheet tracking the OKR goals for their EOQ OKR rating.

Once something is decided, it's pretty sticky, when it really shouldn't be.

In the same way there are 10x engineers, there are 10x PMs. And for that matter, 0.1x PMs. My point is, YMMV. Good PMs carefully balance the various trade offs including respect for engineering time / schedule / quality while acting as a net multiplier for the org.

Reply on news.ycombinator.com