Measuring engineering productivity
You are what you measure. Except, engineering productivity has been really hard to measure. No one can agree on what metrics matter. And the larger a team, the more zoomed out these metrics need to be. Larger engineering organizations tend to measure productivity at the team level.
Someone out there reading this post is probably thinking - but wait, this was an unsolved problem until my startup figured out how to measure this. But the solution is usually to use a product that reports some of the following metrics. Jumble some of them into a category, and you get a vague idea of what's happening at an individual/team level.
- Commits
- Deployments
- Additions / Deletions
- Pull Requests
- PR Comments
- Code reviews
- Code funnels - Open -> Reviewed -> Merged -> Deployed
According to software.com, engineers code 52 minutes per day at the 50th percentile. If you code more than 2 hours a day, you're already at the 90th percentile. But what can we infer from the metric? Is the person coding 52 minutes daily using Chat-GPT to get help writing their functions? Perhaps they're getting more things done in less time. Is the person coding 2 hours a day slow?
It's hard to tell. Which is why none of these metrics make sense on their own. Although, if someone is looking at your code commits, it's usually a bad sign.