My experience has been management is too stupid to properly employ metrics. If you let them pick, they pick the easiest ones. If they don’t get a choice, they just try to cheese the numbers to the detriment of the company. If you present options that make sense, they don’t understand them.
Maybe I’ve just worked for dumb companies, but they sucked hard with respect to metrics.
As an engineering manager who’s tasked with manually gathering a whole lot of metrics in the hopes that something jumps out that can then be improved, what would you say are the metrics that make the most sense?
As a former coder, I would say PR size (the smaller the better), automated test coverage, number of prod bugs, toil level (unplanned work, dealing with tools and environment issues) but also things like knowledge of the code base, level of collaboration, ownership of the process, org-wide collaboration and learning… Much of which is hard to measure but can be set as goals regardless.
Apologies if I misled you a bit. My experience is in manufacturing, not coding. My advice would be to identify issues in terms of cost. That’s what the company truly cares about. Talk to your people and find out what their biggest pain points are. Then order those issues in terms of effort to rectify vs return on investment. Problems that are low effort but high return get prioritized. Then just whittle the list down.
This takes a broader approach to metrics. But as I mentioned, metrics can be cheesed. It’s hard to cheese overall cost. If you prioritized number of bugs, I’d assume the time would go up. If you prioritized time, I’d assume bugs would go up. Prioritizing either doesn’t really solve the problem. You want the root cause of those bugs. Are certain bugs more prevalent (can bugs be categorized even?). Then work those down.
I’d be more then willing to flesh out some more details if you’d like. I genuinely love that kind of stuff. Unfortunately I don’t have coding specific experience.
My experience has been management is too stupid to properly employ metrics. If you let them pick, they pick the easiest ones. If they don’t get a choice, they just try to cheese the numbers to the detriment of the company. If you present options that make sense, they don’t understand them.
Maybe I’ve just worked for dumb companies, but they sucked hard with respect to metrics.
As an engineering manager who’s tasked with manually gathering a whole lot of metrics in the hopes that something jumps out that can then be improved, what would you say are the metrics that make the most sense?
As a former coder, I would say PR size (the smaller the better), automated test coverage, number of prod bugs, toil level (unplanned work, dealing with tools and environment issues) but also things like knowledge of the code base, level of collaboration, ownership of the process, org-wide collaboration and learning… Much of which is hard to measure but can be set as goals regardless.
Apologies if I misled you a bit. My experience is in manufacturing, not coding. My advice would be to identify issues in terms of cost. That’s what the company truly cares about. Talk to your people and find out what their biggest pain points are. Then order those issues in terms of effort to rectify vs return on investment. Problems that are low effort but high return get prioritized. Then just whittle the list down.
This takes a broader approach to metrics. But as I mentioned, metrics can be cheesed. It’s hard to cheese overall cost. If you prioritized number of bugs, I’d assume the time would go up. If you prioritized time, I’d assume bugs would go up. Prioritizing either doesn’t really solve the problem. You want the root cause of those bugs. Are certain bugs more prevalent (can bugs be categorized even?). Then work those down.
I’d be more then willing to flesh out some more details if you’d like. I genuinely love that kind of stuff. Unfortunately I don’t have coding specific experience.