3 ms·

> People fixate on the numbers I've had an unsettled feeling for some time that managers, perhaps many execs, are mostly liabilities... Far to often I have see

> People fixate on the numbers I've had an unsettled feeling for some time that managers, perhaps many execs, are mostly liabilities... Far to often I have seen someone categorize _something_ as not a _something else_ to ensure it doesn't raise any suspicions of their superiors, manipulates the metrics etc. It's lead me to wonder if investment/effort is better invested to cultivate ethos more than measurement. Ethos like "We do what's best for the customer" or "We fix errors when we see them" instead of "Did we hit the SLO?"[1] or "How many open bugs are in the system"[2] Anyone else felt this, or am I just the burnt out, toxic, outlier? [1]: people start to categorize things as not downtime [2]: People start to chastise those who open JIRA bug tickets as "too many!"

rufus_foreman 4y ago
Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."
pklausler 4y ago
https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
cjcenizal 4y ago
> People start to chastise those who open JIRA bug tickets as "too many!" I know what you mean. I've seen teams treat a backlog's growth as being a root problem. They responded by closing issues with the explanation "We probably won't ever get around to this" or by creating scripts that will auto-close any issue after a set period of time. I'm still on the fence about whether this is productive or not. I guess it depends on the team's context. A growing backlog indicates strong demand for features and/or many defects being found in the product, at a rate which outpaces the team's ability to respond. My instinct is to make changes to any part of that system but the backlog itself, since it is real data with real value. My strong opinion weakly held is if you manipulate this data, you're just putting blinders on.
- throwawaysleep 4y ago
  One of my teams is going through this currently. Our Scrum Master keeps on wanting to erase our backlog as she thinks it makes us look bad to management.
- ip26 4y ago
  The best argument I’ve heard in favor of culling like this is that if it wasn’t worth doing two years ago, and wasn’t worth doing one year ago either, it’s probably never going to be worth doing. In this view, legitimately good ideas that never quite make the cut are dangerous because they eternally distract & waste time for no value. As a methodical person it’s hard to digest, but I’m starting to find it holds water.
  - maerF0x0 4y ago
    Except that it might have always been worth doing, but the team is underfunded. ie, the ROI on doing it was positive/high
    - rufyfhrj 4y ago
      I feel like the dynamic still holds true. If the team was underfunded two years ago, and still underfunded one year ago, they will probably still be underfunded with regard to tackling the problem now. The ROI argument seems similarly dubious since it might hold true for things with high upfront costs but otherwise if the perceived ROI had been high then a team short on resources would have already prioritized it.
    - Azkar 4y ago
      Yep. I've found that the ticket or tech debt isn't important until it becomes on fire and must be fixed ASAP. It doesn't matter that the possibility for the bug to happen has existed for 2 years, the organization doesn't find the investment worth it until it's burning down the house.
      - maerF0x0 4y ago
musingsole 4y ago
> managers, perhaps many execs, are mostly liabilities Reminds me of adages about parenting and children as well as government and the economy: more can be done to screw it up/make it worse than can be done to control let alone improve it. The role should be defined by restraint and temperance.
deathanatos 4y ago
"JIRA bankruptcy", is what I've heard it called. It's an idiotic way to sweep problems that still exist under the run. I have no idea why its so hard for suits to just ignore a list of bugs that isn't even intended for them in the first place. … I also had to fight (and mostly lost) the argument that "time to page getting resolved" was not meaningful. People would be chastised for having pages open too long. But, then, e.g., one page was because the underlying problem was real, and it was a problem in our cloud provider — one that our cloud provider couldn't fix. (They wanted us to just abandon the instance of that service we had, and migrate everything out of it. Problem was is that that was difficult, and expensive. Several months of work. We ended up having to do it. But that destroys a Goodhart "mean time to resolve" metric.) But people can process "you have to look at it on a case by case basis, and see if there was a good reason for it", as, Christ, that requires thinking! There was also metrics around hitting SLO, and the SLO was bananas. In theory, we were supposed to do a post-mortem if we missed the SLO. But the SLO got missed so often that, in reality, nobody did the PMs. (And in fact, it effectively killed the culture of "writing PMs" that had existed… and now problems don't really get addressed.) … and I agree about the managers/PMs. When engineering has no authority, the resulting crap isn't surprising.
johngalt 4y ago
It is the inherent conflict between authority and accountability. It's unfair to be accountable for something we have no control over, but if we have control over it, we can unduly influence it. There is no bulletproof answer to this problem. Fixes are mostly about allowing for the possibility of success.

rufus_foreman 4y ago

Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."

pklausler 4y ago

https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law

cjcenizal 4y ago

> People start to chastise those who open JIRA bug tickets as "too many!" I know what you mean. I've seen teams treat a backlog's growth as being a root problem. They responded by closing issues with the explanation "We probably won't ever get around to this" or by creating scripts that will auto-close any issue after a set period of time. I'm still on the fence about whether this is productive or not. I guess it depends on the team's context. A growing backlog indicates strong demand for features and/or many defects being found in the product, at a rate which outpaces the team's ability to respond. My instinct is to make changes to any part of that system but the backlog itself, since it is real data with real value. My strong opinion weakly held is if you manipulate this data, you're just putting blinders on.

throwawaysleep 4y ago
One of my teams is going through this currently. Our Scrum Master keeps on wanting to erase our backlog as she thinks it makes us look bad to management.
ip26 4y ago
The best argument I’ve heard in favor of culling like this is that if it wasn’t worth doing two years ago, and wasn’t worth doing one year ago either, it’s probably never going to be worth doing. In this view, legitimately good ideas that never quite make the cut are dangerous because they eternally distract & waste time for no value. As a methodical person it’s hard to digest, but I’m starting to find it holds water.
- maerF0x0 4y ago
  Except that it might have always been worth doing, but the team is underfunded. ie, the ROI on doing it was positive/high
  - rufyfhrj 4y ago
    I feel like the dynamic still holds true. If the team was underfunded two years ago, and still underfunded one year ago, they will probably still be underfunded with regard to tackling the problem now. The ROI argument seems similarly dubious since it might hold true for things with high upfront costs but otherwise if the perceived ROI had been high then a team short on resources would have already prioritized it.
  - Azkar 4y ago
    Yep. I've found that the ticket or tech debt isn't important until it becomes on fire and must be fixed ASAP. It doesn't matter that the possibility for the bug to happen has existed for 2 years, the organization doesn't find the investment worth it until it's burning down the house.
    - maerF0x0 4y ago

musingsole 4y ago

> managers, perhaps many execs, are mostly liabilities Reminds me of adages about parenting and children as well as government and the economy: more can be done to screw it up/make it worse than can be done to control let alone improve it. The role should be defined by restraint and temperance.

deathanatos 4y ago

"JIRA bankruptcy", is what I've heard it called. It's an idiotic way to sweep problems that still exist under the run. I have no idea why its so hard for suits to just ignore a list of bugs that isn't even intended for them in the first place. … I also had to fight (and mostly lost) the argument that "time to page getting resolved" was not meaningful. People would be chastised for having pages open too long. But, then, e.g., one page was because the underlying problem was real, and it was a problem in our cloud provider — one that our cloud provider couldn't fix. (They wanted us to just abandon the instance of that service we had, and migrate everything out of it. Problem was is that that was difficult, and expensive. Several months of work. We ended up having to do it. But that destroys a Goodhart "mean time to resolve" metric.) But people can process "you have to look at it on a case by case basis, and see if there was a good reason for it", as, Christ, that requires thinking! There was also metrics around hitting SLO, and the SLO was bananas. In theory, we were supposed to do a post-mortem if we missed the SLO. But the SLO got missed so often that, in reality, nobody did the PMs. (And in fact, it effectively killed the culture of "writing PMs" that had existed… and now problems don't really get addressed.) … and I agree about the managers/PMs. When engineering has no authority, the resulting crap isn't surprising.

johngalt 4y ago

It is the inherent conflict between authority and accountability. It's unfair to be accountable for something we have no control over, but if we have control over it, we can unduly influence it. There is no bulletproof answer to this problem. Fixes are mostly about allowing for the possibility of success.