How do you measure eng team productivity?

Question

I&rsquo;m finding very little resource on this topic. However, it is paramount to follow it as a team grows or a company grows - I&rsquo;ve known many companies whose developers effectively stopped developing anything of value, being burdened by bugs, bureaucracy, or poor relationships. To be precise, productivity is the measure of outputs over inputs. In the engineering world, outputs are usually value increments (the definition of which varies according to each team&rsquo;s mission and expertise. They could be user stories for devs, models for data scientists, terraform changes for ops), and input is time. I would note that I don&rsquo;t know whether to count maintenance tasks in or out (such as keeping versions up to date) or the output definition. However, anything that does not bring obvious value (bug fixing, refactoring) should be counted out of output in terms of productivity - don&rsquo;t get me wrong, refactoring is useful and important, because when done well it will improve future productivity. The term &ldquo;team&rdquo; deserves some definition too. A team in my question has two attributes: - a common mission - size between 2 and 7 peopleI&rsquo;m looking for testimonies and knowledge: - how is productivity measured in your team if you&rsquo;re an engineer? In different teams if you&rsquo;re at a management level? Conversely, is it not measured and do you know why? - how is productivity measured in companies you know, either through firsthand experience or well-documented sources? (Company articles, books) - are you aware of research in this area?On a last side note, I would count research displayed in Accelerate out of the productivity question. The DORA metrics don&rsquo;t delve into the complex details of &ldquo;what is value for my team&rdquo; and focus on the release level. The books and research are great, but arguably not about engineering productivity.

atomicnature · Accepted Answer

The organisation is like a complex organism, and engineering is merely piece of the whole. Each piece contributes to and depends on each other (roughly) to make a business function. Therefore, the word "engineering productivity" by necessity should be put under the category of "intangibles" (in most cases).
Still, we can consider some interesting thought experiments. Say, you start with a purely technical team; there are no marketers, no HR, no managers, etc, and the team gets a product going in the market. In such a limited case, one can characterise productivity with "revenue per engineer" (essentially - total revenue / number of engineers).
However, in reality, if the marketers, the HR, and various managers, leaders and salesman don't do their jobs, despite having a great product, revenue will approximate towards zero overtime. In reverse, if the marketers merely do their job perfectly, but there are no engineers delivering the product, again there won't be any profits.
Despite all these caveats, let me share why I think "revenue per employee" seems like the most useful metric here. Consider the "average revenue per employee" for these two companies:
ADP: $284,453
Apple: $2,560,571
Google: $2,020,329
Apple/Google are 10x ADP. I'd argue a good part of this 10x difference we see in the output primarily due to the differences in engineering sophistication. The engineers in these more profitable orgs are doing qualitatively different "types" of engineering (hardware? prototyping? deep research? higher standards?). Increasing engineering prowess, trying more sophisticated projects seems like the biggest boost to the bottom line.

softwaredoug · Answer

I have a better idea, measure how good you are at turnover. How negative is it when someone leaves? How easy is it for someone to join and be productive?
Well, specifically, you can measure onboarding, which is a proxy:
How quickly can someone get started on a feature and ship it to production? How obvious is it for them to follow your teams procedures, guardrails, tests, review processes, etc and go?
Maximizing this means maximizing the available colleagues that can work on your codebase and sets up a positive culture of enablement. It means maintaining your code is not an inscrutable mess.

sirobg · Answer

I worked in a company who measured productivity by attributing a score based on the Fibonacci scale. But they were doing this when the feature was done.
By doing that, it was fairly easy to give a relevant score to each feature.
Engineering team was doing this to measure solely engineering productivity, but product team could do this as well to measure added value to the company.
By tracking the start/end date as well for each feature, you can then measure productivity at any time scale you want.

alxmng · Answer

Why do you want to measure productivity?
You already know where you are. A measurement doesn’t help your team ship better or faster.
If you’re shipping product improvements at a regular cadence, and the customers are happy, then there’s no problem with productivity.
If you’re shipping poor quality, identify why and improve that.
If you’re shipping so slow that it’s negatively impacting customers, identify why and improve that.
Shoot me an email, I’d be happy to offer more perspective or advice.

przeor · Answer

I think, first principle is to build something that people want.
If you build this way, I feel more comfortable than building something fast, that at the end has close to zero usage.
2 - 7 eng dev teams is a small one. It means, just put people on top of things and things should develop faster than in a an average team in any corporation.
This approach/mindset might not work in corporations etc. since they want to have "reports"

matt_s · Answer

Look at the SPACE framework, its meant as a super() to DORA that is focused on developer productivity vs. systems performance: https://queue.acm.org/detail.cfm?id=3454124

toast0 · Answer

> However, anything that does not bring obvious value (bug fixing, refactoring) should be counted out of output in terms of productivity
Not counting refactoring as output makes sense, because it's more of repositioning for future output, and/or recreation.
But if fixing bugs doesn't bring value, why do you do it?