3 ms·

> It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not

> It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket. I know the comment came from a good place and you meant well. The situation you describe of “developers working on the wrong thing” can and sometimes does happen, however, as a manager the effective way to handle those situations is to address the root cause. Is it because the task is too big, not enough details, is it too early in the project that the requirements haven’t really surfaced organically? You want your team to be autonomous, you want to empower your team to make mistakes and at the same time actively minimize the chance for mistakes by greasing “things” so people around you can be more effective. There are few things as negative for a team performance as an insecure manager that needs to be making tactical decisions for the team as if developers were little kids.

9000 6y ago
I'm sorry, but I don't think that's what they were saying at all. To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. Thus, if the ticket is vague, or if they have a question about a part of the codebase they are less familiar with, they have to spend a lot of time trying to divine the answers themselves when they could just walk over or message their colleague for the answer on a normal work day. Spending three hours rederiving trivial knowledge that other members of your team already know (such as which package something is in, or the exact set of inputs that reliably reproduce a bug), IS spending time on the wrong things. I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.
- jhowell 6y ago
  > To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. I think in response to the OP, the user identified the "problem." I've worked places where the above was the norm, and other places where if ticket showed up in front of a developer and required additional clarification (from QA or other developers) this would be covered in detail during sprint retrospectives, with the intention of making sure that the team works hard to make sure that this never happens. It can blow estimates not only for the given task, but can have cascading effects as well. That said, this might not be easily attainable or the best practice for all organizations, but I think I prefer better processes over evening and weekend work.

9000 6y ago

I'm sorry, but I don't think that's what they were saying at all. To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. Thus, if the ticket is vague, or if they have a question about a part of the codebase they are less familiar with, they have to spend a lot of time trying to divine the answers themselves when they could just walk over or message their colleague for the answer on a normal work day. Spending three hours rederiving trivial knowledge that other members of your team already know (such as which package something is in, or the exact set of inputs that reliably reproduce a bug), IS spending time on the wrong things. I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.

jhowell 6y ago
> To me, it sounded like they were saying that when a developer works alone at nights or on the weekend, they cannot ask other members of the team, or the person who originally filed the ticket, any questions. I think in response to the OP, the user identified the "problem." I've worked places where the above was the norm, and other places where if ticket showed up in front of a developer and required additional clarification (from QA or other developers) this would be covered in detail during sprint retrospectives, with the intention of making sure that the team works hard to make sure that this never happens. It can blow estimates not only for the given task, but can have cascading effects as well. That said, this might not be easily attainable or the best practice for all organizations, but I think I prefer better processes over evening and weekend work.