1 min read

Measuring engineering productivity

Measuring engineering productivity
Photo by Roman Synkevych / Unsplash

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.