Hacker News Reader

Comment by maerF0x0 | Hacker News Reader

> 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!"

View on HN

> 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.

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.

Except that it might have always been worth doing, but the team is underfunded. ie, the ROI on doing it was positive/high

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.

which seems like such a blatant failure of leadership. If I had 1000 ways that I could invest $1000 at a 20% return this year and like 5% recurring[1], why not hire 2-3 engineers get them done and keep the extra $200k plus have a better future?

The most compelling argument was opportunity cost against features (eg the time spent on feature work would return 100% per year or whatever seems enticing) ... That seemed to me to only suggest we should do _both_ (get more capital in the market if required)

[1]: some amount of recurring makes sense so long as things like customer retention, brand value, maintenance costs are factored in

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.

That only works if the programmers buy the managers' narrative -- and that's not a given. Usually it's the opposite.

Managers very often only optimize for them to look better in front of their superiors, to the detriment of the underlying team's efficiency, and very often to the detriment of the product itself.

People pulling the blanket towards them is not a new thing.

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.

"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.

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.

> 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.

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

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

Reply on news.ycombinator.com