[caskstrength]

> Being a manager is about more than just getting people to do their job well. You also need to plan things, you need to know what's changing over time, you need to test whether your processes are working. I use metrics to measure the aggregate impact of my influence on managing my teams, not that of any IC on any of my teams. Employee metrics are useful for a big picture view.

The point of the article is exactly that such metrics don't give you any kind of a good signal unless you are really into the fine details. And if you are, then you don't really need them in the first place.

> quantitative details (eg a count of how much output there is)

For example I recently spent a week producing several thousands of lines of tedious trivial code that parses some configuration out of JSON file in pure C. Then I spent a month writing less 1k lines of very dense low-level packet parsing code and the main loop also in C. So the metrics would show you the big picture of me slacking and my performance tanking which obviously wasn't the case. You can't substitute actually knowing and understanding of what your reports are doing with some tools providing you with trivia like number of commits, lines of code changed or tickets closed.