Ask HN: Scaling and Measuring Engineering Productivity

Hey! I’m interested in finding resources, postmortems, case studies, as well as personal success/failure stories of measuring development teams while scaling them - when it gets harder to do that directly, as you would in a small team. Now, don’t get me wrong, I’m not advocating for metrics like tasks delivered, commits done, lines of code changed (hard to even write the latter ones down without cringing). This kind of “productivity output measuring” sounds easily-gamed, very stressful, and ultimately fairly useless. This can be a totally different approach - streamlining the identification of blockers, exploring what time sinks developers are being hindered by. I think this handbook by okay.com is a very good example of a great resource looking at the problem from that side: https://www.okayhq.com/handbook/getting-started/what-is Measuring the time CI/CD pipelines take, PR’s take to be reviewed, etc. looks like a very sensible approach. What are your experiences? What worked for you? What did you hate?