7 ms·

If managers are spending their days watching the color of the circles next to their team member's names, maybe the managers need more work to do in order to "st

If managers are spending their days watching the color of the circles next to their team member's names, maybe the managers need more work to do in order to "stay engaged" at work. Of all the bad heuristics for trying to determine whether someone is being productive, this has to be near the bottom of the list. It's the digital equivalent of measuring engineer productivity by looking around the room and seeing who is at their desk. Except that it can be trivially gamed by a simple mouse jiggler script.

adamsmith143 4y ago
Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This also obviously breeds other bad incentives i.e. the faster you work the more work you get.
- dangerlibrary 4y ago
  It might be time to start looking for a team with a better work culture. There are many of them.
  - adamsmith143 4y ago
    I am definitely willing to concede I may be in a bad situation but are there really teams in Agile frameworks with fibonacci pointing where you can pick up a 3-5 point ticket, finish it before the end of a sprint and not work on anything else?
    - dangerlibrary 4y ago
      Yes, there are, though that question is weirdly specific. Is it important to you to work on a team using an Agile framework with Fibonacci pointing?
      - adamsmith143 4y ago
        Not at all, just trying to make a concrete example.
    - corrral 4y ago
      I've seen plenty where a point-a-day pace or somewhat under (maybe 0.8pt/day) would be a totally normal pace, and is absolutely achievable with under half a day of actual work per day, including meetings, if you know what you're doing. But then again, points are incommensurable between teams.
    - digisign 4y ago
      I don't think you're supposed to do nothing at that point. Leisurely improve your tools, read to improve knowledge/performance, etc. This compounds your efficiency over time, without the stress of more deadlines.
- nisegami 4y ago
  >the faster you work the more work you get. It took me about 2 months to learn this after getting my first job. Nowadays I intentionally add minor bugs that turn up during demos so I have stuff to "go back and fix" later.
  - digisign 4y ago
    That sounds... unnecessary. There is always stuff to refactor, and tests to add, folks showing up at the last minute with new requirements. Or you can just wait a day to push commits, etc. More honest, I think.
    - nisegami 4y ago
      The only tests we have are some for a project I worked on that I wrote to prove it could be done. Automated testing might as well be dark magic to my coworkers.
    - corrral 4y ago
      Refactoring and adding tests can be (and very often are) pushed into the backlog, and then never done. "We'll circle back to that after this sprint (narrator: they would not circle back to it) but for now focus on these new features" Bugs are more urgent.
      - digisign 4y ago
        Disagree. This is a misconception junior devs often have... that you need to ask permission to do your job. (Not unless the boss is dysfunctional, in which case it's time to leave.) Tests and refactoring should be done as part of every ticket and typically don't need to be explicitly called out. This naturally pushes "done" so you don't run out of tickets early.
        corrral 4y ago
        Yes, but the point of this was to generate (easy) work that others want you to do so they won't ask you to do other (more time-consuming) stuff instead. You'll have a very different experience telling the product owner you spent the whole week working on bugs that they noticed and they told you to fix (even if you left them in originally on purpose) than telling them you spent all week refactoring code. The former is an instant "great!". The latter is gonna get a concerned look and more questions. The topic wasn't correctly doing development work, but finding ways to slack off while looking good.
- paskozdilar 4y ago
  > from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This is true, assuming that: 1. the whole team has approximately equal skill 2. the system is uniform and well-documented 3. the people actually give a shit about the product If any of these assumptions are not met, then the expectation is naive.
  - fatnoah 4y ago
    I can't think of any environment that I've been in where this is true. I think the closest I've been was as part of a team of three people where each of us could really handle any task in the codebase. It was also true that there were things that we each cared far more about as individuals, so, in spite of comparable skills, we tended to gravitate to specific stories, anyway. As a manager, I have every expectation that we won't be doing scrum exactly by the book, but that's totally fine. I'm more concerned about (reasonably) consistently reproducible levels of productivity, not squeezing every point out of a sprint. If there's slack time, great. That seems to be when people are most likely to contribute new stories, learn something new, etc. Besides, rigidly following scrum feels anti-Agile, anyway. People and interactions over tools and processes.
  - laserlight 4y ago
    Picking up another task doesn’t mean that it has to be finished. If one lacks skill, they can train. If documentation is missing, one can document whatever they learn. The last one is difficult to address, but not impossible. If team members don’t give a shit about the product, I bet they can still find something they give a shit about that also contributes to the product.
    - paskozdilar 4y ago
      You make a good point. I guess as long as the people are passionate, the first two issues can be, over time, worked through. I guess the tarpit is that the "time" can be really long, especially for (skill-wise) heterogeneous team working on large undocumented projects.
AlwaysRock 4y ago
I had a manager like this. I eventually got some software to keep my computer awake/active from 7am-7pm. It was stupid.
- wreath 4y ago
  A long Youtube video should do the “trick”
  - bonestamp2 4y ago
    A youtube video won't work for me -- my work computer goes idle if the mouse or keyboard doesn't send input for more than 10 minutes. A lot of my work involves work off of my computer, so I just bought a USB mouse jiggler to keep my computer awake so I still get instant messages from my coworkers when I'm working offline.
    - AlwaysRock 4y ago
      Youtube didnt work for me either. VLC on the otherhand keeps my computer awake.
tsol 4y ago
Even if that's true, this unengaged manager still has the power to make your life difficult if they think you're not doing enough
- dangerlibrary 4y ago
  And you have the power to schedule a skip-level 1-1 or leave the team.
deleted 4y ago
[deleted]

adamsmith143 4y ago

Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This also obviously breeds other bad incentives i.e. the faster you work the more work you get.

dangerlibrary 4y ago
It might be time to start looking for a team with a better work culture. There are many of them.
- adamsmith143 4y ago
  I am definitely willing to concede I may be in a bad situation but are there really teams in Agile frameworks with fibonacci pointing where you can pick up a 3-5 point ticket, finish it before the end of a sprint and not work on anything else?
  - dangerlibrary 4y ago
    Yes, there are, though that question is weirdly specific. Is it important to you to work on a team using an Agile framework with Fibonacci pointing?
    - adamsmith143 4y ago
      Not at all, just trying to make a concrete example.
  - corrral 4y ago
    I've seen plenty where a point-a-day pace or somewhat under (maybe 0.8pt/day) would be a totally normal pace, and is absolutely achievable with under half a day of actual work per day, including meetings, if you know what you're doing. But then again, points are incommensurable between teams.
  - digisign 4y ago
    I don't think you're supposed to do nothing at that point. Leisurely improve your tools, read to improve knowledge/performance, etc. This compounds your efficiency over time, without the stress of more deadlines.
nisegami 4y ago
>the faster you work the more work you get. It took me about 2 months to learn this after getting my first job. Nowadays I intentionally add minor bugs that turn up during demos so I have stuff to "go back and fix" later.
- digisign 4y ago
  That sounds... unnecessary. There is always stuff to refactor, and tests to add, folks showing up at the last minute with new requirements. Or you can just wait a day to push commits, etc. More honest, I think.
  - nisegami 4y ago
    The only tests we have are some for a project I worked on that I wrote to prove it could be done. Automated testing might as well be dark magic to my coworkers.
  - corrral 4y ago
    Refactoring and adding tests can be (and very often are) pushed into the backlog, and then never done. "We'll circle back to that after this sprint (narrator: they would not circle back to it) but for now focus on these new features" Bugs are more urgent.
    - digisign 4y ago
      Disagree. This is a misconception junior devs often have... that you need to ask permission to do your job. (Not unless the boss is dysfunctional, in which case it's time to leave.) Tests and refactoring should be done as part of every ticket and typically don't need to be explicitly called out. This naturally pushes "done" so you don't run out of tickets early.
      - corrral 4y ago
        Yes, but the point of this was to generate (easy) work that others want you to do so they won't ask you to do other (more time-consuming) stuff instead. You'll have a very different experience telling the product owner you spent the whole week working on bugs that they noticed and they told you to fix (even if you left them in originally on purpose) than telling them you spent all week refactoring code. The former is an instant "great!". The latter is gonna get a concerned look and more questions. The topic wasn't correctly doing development work, but finding ways to slack off while looking good.
paskozdilar 4y ago
> from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example. This is true, assuming that: 1. the whole team has approximately equal skill 2. the system is uniform and well-documented 3. the people actually give a shit about the product If any of these assumptions are not met, then the expectation is naive.
- fatnoah 4y ago
  I can't think of any environment that I've been in where this is true. I think the closest I've been was as part of a team of three people where each of us could really handle any task in the codebase. It was also true that there were things that we each cared far more about as individuals, so, in spite of comparable skills, we tended to gravitate to specific stories, anyway. As a manager, I have every expectation that we won't be doing scrum exactly by the book, but that's totally fine. I'm more concerned about (reasonably) consistently reproducible levels of productivity, not squeezing every point out of a sprint. If there's slack time, great. That seems to be when people are most likely to contribute new stories, learn something new, etc. Besides, rigidly following scrum feels anti-Agile, anyway. People and interactions over tools and processes.
- laserlight 4y ago
  Picking up another task doesn’t mean that it has to be finished. If one lacks skill, they can train. If documentation is missing, one can document whatever they learn. The last one is difficult to address, but not impossible. If team members don’t give a shit about the product, I bet they can still find something they give a shit about that also contributes to the product.
  - paskozdilar 4y ago
    You make a good point. I guess as long as the people are passionate, the first two issues can be, over time, worked through. I guess the tarpit is that the "time" can be really long, especially for (skill-wise) heterogeneous team working on large undocumented projects.

AlwaysRock 4y ago

I had a manager like this. I eventually got some software to keep my computer awake/active from 7am-7pm. It was stupid.

wreath 4y ago
A long Youtube video should do the “trick”
- bonestamp2 4y ago
  A youtube video won't work for me -- my work computer goes idle if the mouse or keyboard doesn't send input for more than 10 minutes. A lot of my work involves work off of my computer, so I just bought a USB mouse jiggler to keep my computer awake so I still get instant messages from my coworkers when I'm working offline.
  - AlwaysRock 4y ago
    Youtube didnt work for me either. VLC on the otherhand keeps my computer awake.

tsol 4y ago

Even if that's true, this unengaged manager still has the power to make your life difficult if they think you're not doing enough

dangerlibrary 4y ago
And you have the power to schedule a skip-level 1-1 or leave the team.

deleted 4y ago

[deleted]