Limitations of Goodhart's Law

Yes.. I mean at Amazon. The WBR (when I was there) was held on Monday at the director level, Tuesday at the VP and Wednesday at the S-team.

The following is purely my opinion:

The constant churn of employees and directors at the lower levels meant the data is mostly massaged or explained away.

The really good old-timers would focus on exceptions and single anomalies - much to the frustration of poor engineers and managers. But they intuitively knew that those small issues can snowball and catching them early helped mitigating the issue. But as the systems grew more complex and the number of teams expanded massively, the feel for the pulse became more mechanical and remote. New managers, directors and VPs did not come from a similar culture and the constant politics sidelined the more experienced employees who quit. Once that knowledge is lost, it takes multiple years to get it back and I do not think Amazon got that mojo anymore.

It felt more mechanical and ritualistic, rather than genuinely trying to uncover issues (which is when I quit). It is Goodhart's law at the next level.

Campbell's law is not simply a "social variant" of Goodhart's law. The two have a subtle but crucial difference.

To paraphrase a DonaldTrumpism, Goodhart's law says "Sounds good, doesn't work".

Whereas Campbell's law adds "Worse still, it'll certainly backfire", and makes that the focus.

Incidentally, the other "law" alluded to in the text, also has a name:

> The (Lance) Armstrong Principle:

"If you push people to promise more than they can deliver, they’re motivated to cheat."

A more general rephrasing: if you create / hold people accountable (e.g. by forcing a promise) to unreasonable expectations of performance that cannot be delivered there will be a motivation to cut corners, e.g. cheat.

(Popularized by Andrew Gelman; I first encountered this in an article by friend/colleague Nick Yeung, about the bad side of forcing phd students to publish, also an interesting article in its own right: https://www.nature.com/articles/s41562-019-0685-4 )

That's like- the whole point. If you as a manager set a goal, those three choices are all the choices the people under you have to meet the goal, and you often set it up so that the preferred choice (actually make things better) is impossible. Its saying that decision makers need to be aware of this and adjust your behavior.

Like you said, if they don't, the people dealing with it have no choice- so, it'd be impossible to offer advice for those people, since they have no way of actioning it (unless its convincing the decision maker of that point)

If people are serious about rooting out people who lie or cheat to appear on-target (beneath them in the management chain) they need employ anonymous whistleblowing straight up to them.

But I think many people in charge see the corruptness of the people below them as "headaches to deal with" and "if it's not squeaking it must be working" which I think is exactly backwards (it's the "if it compiles it's working" approach to management).

One of the subtler points Eli Goldratt makes indirectly is essentially that, "this type of culture is established" as you put it, in situations of abundance.

So Goldratt's description of "crunch time" is a company which starts out every quarter doing things in the (as they see it) "right way," then they close out every quarter doing everything in the "wrong way" or taking shortcuts or spending considerable costs to finish projects to make their revenue come in.

The spin I'm offering is: when you have a season of abundance, you do not have to face crunch time, and you get, as you put it, "predictable bullshit and they don't feel responsible for it." But effecting change during crunch time, by contrast, seems much easier. As long as you can keep your head straight. Goldratt's starting point begins, "maybe these 'shorctuts' we take under pressure are not the 'wrong way' per se."

I personally hate learning abstractions without examples, so let's get concrete. Your software project gets overdue and you and your peers start approving each others' merge-requests after only skimming them for flagrantly bad code, rather than "is this method in the right class?" and "does this have adequate test coverage?" you are now instead looking for "okay that's a raw SQL query, could that accidentally drop the whole database? no? approved! anything else we can add tests and refactor in a month." That attitude, right?

Goldratt says, "no, pay attention to that!" ... you say "but that's not how it should be done, we must review code as we go, tests are good to have" and my-imaginary-version-of-him replies, "sure I understand that you have a need for code safety, I am not saying that you don't. But the fact remains, you accepted the bypassing of this process when crunch-time came, which means that it constrained the team in unacceptable ways overall. So if we believe in working smarter-not-harder, we need to get imaginative now, because the 'logical place' for code safety measures to get injected, is too slow. And there are lots of imaginative solutions. We could hire someone whose only job will be code review, they could start reviewing your code before you're even done writing it. Or we could mandate that everyone must commit their code to the main branch every single day with only pro-forma code review, this will force us to adopt out-of-band practices to make things safe. Other things like that."

So what does effecting change look like in a system that does not have the luxury of abundance? It looks like a "crunch time" that never "ends", but does "get better." Goldratt's point is essentially that you don't want to meet this punch with a counterforce, as that will hurt: you instead want to yield with it and let its own momentum carry the both of you to a better solution.

I have a theory about how this works on software projects but I didn't quite get the chance to run the experiment at my last job, so if this intrigues you and you have the headcount to hire me... :)