JAjameshush·Mar 14, 2021
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 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 othe
Read the rest
r 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.