3 ms·

I give the author full points for thinking through the problems and trying to mitigate the flaws, clearly he has significant experience and good intent. At the

I give the author full points for thinking through the problems and trying to mitigate the flaws, clearly he has significant experience and good intent. At the end of the day though, his obsession with quantifying dev performance is doomed to failure. Goodharts Law can not be routed around by adding more metrics to capture all eng considerations. This can only work in a sanitized environment with low expectations and homogenous feature requests. In fast growing tech companies, there is far too much chaos and change for anything like this to approach an objective measure of what activity is producing value. What I’ve learned over my decades a TL, EM, Director and CTO is that team performance has a human chemistry aspect to it where you need certain traits present, including a healthy dose of intrinsic motivation to do good work, and enough judgement on what that means in relationship to both short and long term business needs. Ultimately as a manager your only option to scale is to empower individuals as much as possible and relentlessly pursue and elevate those with the judgement and maturity to have more authority. Yes, it’s subjective, but there’s no faster way to kill the motivation of your top people than to reduce the output of their contextual reasoning to a metric. You’ve killed the golden goose while pursuing your control fantasy.

ItsMonkk 3y ago
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.

ItsMonkk 3y ago

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.