Selecting Meaningful Metrics with Goals and Signals

This is from the "Software Engineering at Google" book, https://abseil.io/resources/swe-book

Goals-Signals-Metrics seems like a nice way to organize thinking about performance. Predictive signals or metrics are the grail - lagging signals or metrics don't tell us much about what to do to improve.

Maybe it is interesting to compare metrics in the context of engineering centered processes (this) vs product development or product investment processes. The latter is more business focussed, and looks not our efficacy (SWE) but our business impact relative to business expenditure. Maybe that's a question of whether Product Management is sitting in Engineering or not. Are we getting things done well (SWE) or are we building the right things (product). The product POV never not has an impact on dev quality of life.

> Why Should We Measure Engineering Productivity?

I'm still waiting for the answer. It was not addressed in the article.

> [cited as valid reason not to measure:] You can’t afford to change the process/tools right now

I'd argue that cost to change vs cost of not changing is itself often a fluctuating value. Seeing trends there and being able to make estimates/predictions about the costs of tradeoffs is valuable. Especially when trying to change a system.

> The results will be used only as vanity metrics to support something you were going to do anyway

Those are most metrics I've seen. At least the ones that bubble up the management chain, in my non-Googley experience.

I realize it's a really twisted version of Goodhart's Law[1], but I claim metrics should shape human behavior. Any metric you can't respond to is useless. Metrics you will never respond to are useless. Metrics that potentially make you change behavior are meaningful. This was touched on in the article but the actual human behavior aspect seemed buried, to me.

[1] https://en.wikipedia.org/wiki/Goodhart's_law

I kept trying to think of meaningful usage of this many layers of abstraction, and I can't find a use in my head where the three-deep decomposition adds value.

Knowing that the stuff you measure is often not the actual stuff you care about is an advanced bit of cognitive development, but does this level of formalism really help?

Only a manager could find this useful. A metric is a statistic in the true sense of the word, i.e. it has a distribution is subject to random variation. In other words, looking at a metric every x days, is akin to flipping a coin and making a decision based on whether it came back heads or tails.