3 ms·

I'd recommend prioritizing getting those numbers. Making the time to setup the measuring/monitoring is a bit of a pain but it's worth it. I worked in the same

I'd recommend prioritizing getting those numbers. Making the time to setup the measuring/monitoring is a bit of a pain but it's worth it. I worked in the same vertical (infra/"DevOps"/engineering productivity) before I shifted to becoming a people manager. Here's some of the things we're setting up now to measure this: - Using something like https://github.com/ImpactInsights/valuestream https://github.com/ImpactInsights/valuestream to measure number of deploys per week, build times across pull requests, length of time it takes a pull request merged across the entire team, etc. - If you want to get fancier, setting up simple tracking to measure how much time running "npm install" takes across all engineers on their local machines. This could get logged in something like Datadog/Grafana/whatever graphing solution you want. - Zoom out even further. Are releases being slowed down by other teams by accident? E.g. we had a feature delayed a week by accident because the marketing team didn't know a feature was finished, in production, but behind a flag waiting for them to write marketing copy. We're currently setting up a way to track "features in production but behind a flag" in Jira better and feed that "lag time" data into our overall deployment picture. The idea being, for every task you're executing to "improve developer productivity" you should have a hypothesis with about how much time it'll save the team. If you can't get that right away, I'd move on to a task that has a better measure to it and knock that out first. If you completely run out of tasks and measurements, that's when you can take bigger bets on tasks that have more fuzzy measurements next to them. In my experience the work here never dries up though.

UncleMeat 6y ago
> I'd recommend prioritizing getting those numbers. I'm also at Google. I know a few L7s/L8s who lead these sorts of engineering productivity teams and organizations. It isn't just that they aren't prioritizing getting precise numbers. It is that the entire industry has very little idea how to measure engineering productivity. This is a stupendously difficult problem and an area of active research. The metrics you describe here are okay (build times are easy to measure and can be directly valuable) but they really do represent a limited view. They don't capture all sorts of important stuff. What is the measured value of transitioning to a new C++ version? What is the measured value of best practices documentation and training courses? Measurements are stupendously valuable when they are feasible and meaningful. But there is real work that should be done that is almost impossible to convert to numbers, let alone dollars.

UncleMeat 6y ago

> I'd recommend prioritizing getting those numbers. I'm also at Google. I know a few L7s/L8s who lead these sorts of engineering productivity teams and organizations. It isn't just that they aren't prioritizing getting precise numbers. It is that the entire industry has very little idea how to measure engineering productivity. This is a stupendously difficult problem and an area of active research. The metrics you describe here are okay (build times are easy to measure and can be directly valuable) but they really do represent a limited view. They don't capture all sorts of important stuff. What is the measured value of transitioning to a new C++ version? What is the measured value of best practices documentation and training courses? Measurements are stupendously valuable when they are feasible and meaningful. But there is real work that should be done that is almost impossible to convert to numbers, let alone dollars.