Fair Ways to Measure Engineering Productivity for Software Teams

However, we do not evaluate the effectiveness of our engineers using productivity metrics, as software development is too complicated to be reduced to numbers only. We focus on the outcomes that include predictability of delivery, software quality, impact on customers, and team health. The metrics help us to see patterns and potential areas for improving but do not provide the basis for ranking individuals.
So far, one of the most fair approaches to assessing progress has been regular delivery reviews where we compare the commitments with outcomes. Instead of asking about the number of tickets done and lines of code written, we discuss if our team has delivered expected business value and what barriers have affected the progress. We also talk about what can be improved in the next iteration.

I try not to measure engineers by numbers alone because the moment people start optimizing for metrics, they stop optimizing for outcomes.

If I had to pick one rhythm, it would be a weekly conversation around what value we delivered. Did we solve a customer problem? Did we remove a bottleneck? Did we make the product more reliable? Those discussions tell you far more than a dashboard ever will.

The numbers are still useful, but they should help you ask better questions, not become the goal. When the team is focused on delivering real business value, the metrics usually take care of themselves.

The measure I trust most is how long a piece of work takes to go from started to in use by a customer, tracked as a trend rather than a target. It is hard to game without doing the right things: shrinking batch sizes, clearing blockers, reducing rework. And because it belongs to the whole flow rather than to any individual, nobody is put in the position of defending personal numbers.
The rhythm matters more than the metric. We review it in retrospectives as a question, not a scorecard: this took six weeks, where did the time go? The answer is usually waiting, handovers or unclear requirements, none of which appear in individual productivity stats.
What I deliberately avoid is anything that measures people rather than the system. Once a number affects how an engineer is judged, you tend to get the number and lose the truth. Measure the pipe, discuss it openly, and keep individual performance a separate, human conversation.

Over my last ten years building AI products, from scaling systems for millions of users at Leboncoin to now as CTO at AGO, I've found that pushing engineering teams to chase numbers usually just teaches them how to game the system. If you measure pull requests or story points, developers will naturally optimize for those metrics, but the actual software rarely gets better faster.

To gauge effectiveness without turning it into a math exercise, we rely on a single rhythm to see real progress across our projects: the weekly end-to-end demo. We generally don't look at how many Jira tickets a team cleared that week. Instead, every Friday, a team has to show a live, functioning update working in a staging or production environment.

When we were building the core engine for our autonomous AI agents at AGO, this rhythm meant an engineer couldn't just say they tweaked our retrieval models. They had to pull up a real screen and show the agent successfully handling a new edge case or automatically drafting a wiki update. It shifts the entire team's focus from tracking output to proving an outcome. If a team can consistently stand up once a week and demonstrate a tangible, working improvement, I know they are effective, regardless of what their burndown chart looks like.