
So a product manager asks you to fix a bug… - ajallow
https://medium.freecodecamp.com/youre-asked-to-make-a-fix-e156b802ad92#.y86cumyot
======
jimmywanger
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.

~~~
tehlike
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.

~~~
jimmywanger
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.

~~~
tehlike
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.

~~~
tehlike
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.

~~~
jimmywanger
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?

~~~
tehlike
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.

------
phodo
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.

