4 ms·

I think most of the work stream principles outlined in the article are sound, however, in my view having a manager dictate finely detailed priorities is in most

I think most of the work stream principles outlined in the article are sound, however, in my view having a manager dictate finely detailed priorities is in most situations an anti-pattern and a Taylorist trap. In my experience, heuristics that help people identify priorities themselves are usually more powerful. You can still break ties or give relative prioritizations when needed.

someguydave 5y ago
It's much better when managers prioritize than when they do not and let everything be urgent.
- 8note 5y ago
  I think what you're really saying is that it's nice when managers deprioritize items
  - someguydave 5y ago
    mostly yes. I think humans can only work on one thing at a time. If you hire a worker it is common sense that you should be able to identify that upon which he should work.
    - kqr 5y ago
      But this is the Taylorist trap mentioned in the top level comment. That somehow "managers" are hired to think, and "workers" are hired to do whatever the "managers" say. I fully expect the "workers" I supervise to be able to identify things which need work completely on their own. Many heads think much better than one. Besides, they are on the frontlines so they have a much better view of the situation than I. (As much as I try to also do technical work myself.)
      - someguydave 5y ago
        I understand. To me you resolve the paradox by getting management to admit to themselves that most engineers and programmers are also managers and need some explicit authorities to decide what needs to be done or not
        kqr 5y ago
        Right. Though I would phrase it a little differently: every role in a long-term successful organisation is a little bit leadership, a little bit skilled labour.
  - kqr 5y ago
    And the grandparent is saying that it's even nicer when engineers can do it, because the managers have coached them in the economics of the situation and they have the mental context they need to make deprioritisation decisions on their own.
- losteric 5y ago
  Or at least reach an agreement of reserved off-sprint capacity. For example, I've been on teams with minimal ops burden where the manager agreed to keep 1 head off-sprint to handle emergencies. On typical weeks, that gave the team 15% capacity towards tech debt/better OE... which reduced frequency of emergent events... and when there was a true emergent situation (eg log4j), it was immediately started by that reserved head with no impact on product commitments (that stability then also saved the manager and lead dev's time). That very same team had constant product priority churn, but personally I took no issue with that given the pleasant state of code.
  - kqr 5y ago
    Yes, this is the classic trade-off between optimising the time it takes to get things done, and the time spent doing things. If you want things to be done quicker, you counter-intuitively have to spend less time doing things. Keeping a person in reserve is one easy way of accomplishing that. (Why is it a trade-off? Because when in order to ensure you spend a lot of time doing things, you need to have a long queue of things to be done so you never run out of things to do. That long queue means everything takes longer to get done because it spends more time queuing.)
- kitsune_ 5y ago
  Well, yeah, sure. But that's not what I meant. The "Optimize for finishing work before starting new work" could be such a heuristic. Contrast two positives with an "even over" statement. If you have heuristics such as "maintainable software even over new features" (this is just an example, this could just as well be the opposite) that apply to the entire team, manager included, people don't need their manager to tell them whether to work on X or Y each time and they can prioritize their own work.

someguydave 5y ago

It's much better when managers prioritize than when they do not and let everything be urgent.

8note 5y ago
I think what you're really saying is that it's nice when managers deprioritize items
- someguydave 5y ago
  mostly yes. I think humans can only work on one thing at a time. If you hire a worker it is common sense that you should be able to identify that upon which he should work.
  - kqr 5y ago
    But this is the Taylorist trap mentioned in the top level comment. That somehow "managers" are hired to think, and "workers" are hired to do whatever the "managers" say. I fully expect the "workers" I supervise to be able to identify things which need work completely on their own. Many heads think much better than one. Besides, they are on the frontlines so they have a much better view of the situation than I. (As much as I try to also do technical work myself.)
    - someguydave 5y ago
      I understand. To me you resolve the paradox by getting management to admit to themselves that most engineers and programmers are also managers and need some explicit authorities to decide what needs to be done or not
      - kqr 5y ago
        Right. Though I would phrase it a little differently: every role in a long-term successful organisation is a little bit leadership, a little bit skilled labour.
- kqr 5y ago
  And the grandparent is saying that it's even nicer when engineers can do it, because the managers have coached them in the economics of the situation and they have the mental context they need to make deprioritisation decisions on their own.
losteric 5y ago
Or at least reach an agreement of reserved off-sprint capacity. For example, I've been on teams with minimal ops burden where the manager agreed to keep 1 head off-sprint to handle emergencies. On typical weeks, that gave the team 15% capacity towards tech debt/better OE... which reduced frequency of emergent events... and when there was a true emergent situation (eg log4j), it was immediately started by that reserved head with no impact on product commitments (that stability then also saved the manager and lead dev's time). That very same team had constant product priority churn, but personally I took no issue with that given the pleasant state of code.
- kqr 5y ago
  Yes, this is the classic trade-off between optimising the time it takes to get things done, and the time spent doing things. If you want things to be done quicker, you counter-intuitively have to spend less time doing things. Keeping a person in reserve is one easy way of accomplishing that. (Why is it a trade-off? Because when in order to ensure you spend a lot of time doing things, you need to have a long queue of things to be done so you never run out of things to do. That long queue means everything takes longer to get done because it spends more time queuing.)
kitsune_ 5y ago
Well, yeah, sure. But that's not what I meant. The "Optimize for finishing work before starting new work" could be such a heuristic. Contrast two positives with an "even over" statement. If you have heuristics such as "maintainable software even over new features" (this is just an example, this could just as well be the opposite) that apply to the entire team, manager included, people don't need their manager to tell them whether to work on X or Y each time and they can prioritize their own work.