5 ms·

So a product manager asks you to fix a bug…

15 points by ajallow 10y ago

jimmywanger 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        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 10y ago
        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 10y ago
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.

15 points by ajallow 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        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 10y ago

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.