Matches my thoughts, in particular I want to discuss the following quote:
> It can’t be that you want your org to run without numbers. And it can’t be that you eschew quantitative goals forever!
Metrics are used by experts to enhance their ability to reason about a system. You should use metrics, you should not rely on metrics. Metrics don't mean anything onto themselves. Given the depth that the author is thinking through problems with them it seems very likely that he is using metrics in this manner. But once that intuition of how the team is doing has been accomplished, they have done their job.
The issue in this article is less that it describes a good system, but more that without those actual insights and ability to tweak them as Goodhart comes into play, giving out this system in the form of this article is harmful to anyone who tries to use it who isn't an expert already. Anyone who does not understand how to manage a team and build software who is using metrics to decide what to do without attempting to learn the underlying dynamics is focusing on the wrong thing.
Side note: I'm really curious how often he puts out tasks with an essential complexity of 0 with a high accidental complexity. I'd imagine in any decent team that should be a decent number of tasks. In the ones that track metrics sloppily, a majority of them.
> It can’t be that you want your org to run without numbers. And it can’t be that you eschew quantitative goals forever!
Metrics are used by experts to enhance their ability to reason about a system. You should use metrics, you should not rely on metrics. Metrics don't mean anything onto themselves. Given the depth that the author is thinking through problems with them it seems very likely that he is using metrics in this manner. But once that intuition of how the team is doing has been accomplished, they have done their job.
The issue in this article is less that it describes a good system, but more that without those actual insights and ability to tweak them as Goodhart comes into play, giving out this system in the form of this article is harmful to anyone who tries to use it who isn't an expert already. Anyone who does not understand how to manage a team and build software who is using metrics to decide what to do without attempting to learn the underlying dynamics is focusing on the wrong thing.
Side note: I'm really curious how often he puts out tasks with an essential complexity of 0 with a high accidental complexity. I'd imagine in any decent team that should be a decent number of tasks. In the ones that track metrics sloppily, a majority of them.