Realworld
How to Measure Productivity in Product Teams: Learnings from Ocado Technology · LAB
Join our community.
We invite you to participate in the upcoming Runroom LAB and events we organize at Runroom. Check the upcoming dates.
Measuring productivity in product teams remains one of the biggest challenges for digital organizations. From the case of Ocado Technology, explored in a Runroom LAB with its Deputy CTO, Toni Tassani, we discover why measuring is not the goal, but the means to improve, and how to find the balance between metrics, impact, and team experience.
The Dilemma of Productivity in Digital Product
Productivity in product teams is not a straightforward metric. Unlike industrial environments, where output is easily quantifiable, software and digital product development involve factors such as quality, sustainability, and adaptability.
In this context, many organizations ask:
- What does it really mean to be productive?
- What should we measure?
- How to prevent metrics from distorting team behavior?
These questions were the starting point of the Runroom LAB focused on productivity, where the approach of Ocado Technology, a pioneer in logistics automation and technological development on a global scale, was analyzed.
The Ocado Case: Measuring to Improve, Not to Control
One of the main learnings shared by Toni Tassani is that measuring productivity is not an end in itself, but a vehicle for continuous improvement.
At Ocado, the approach starts from a key idea:
Before measuring, understand why you measure.
This change of perspective completely transforms the role of metrics:
- They are not used to evaluate individuals
- They do not seek to maximize short-term output
- They serve to identify frictions and opportunities for improvement
Therefore, the organization created a specific Engineering Productivity team, focused on facilitating developers' work and optimizing their environment, not on auditing their performance.
Beyond Output: A Systemic View of Productivity
One of the most common mistakes is associating productivity solely with volume (lines of code, features delivered, etc.). However, in complex environments, this can even be counterproductive.
Ocado opts for a broader vision based on:
- Code quality
- Ability to change
- Error reduction
- Development flow
- Team well-being
This approach aligns with models like SPACE, which integrate dimensions such as satisfaction, performance, activity, communication, and efficiency.
The Balance Between Data and Experience
One of the most interesting points of the LAB is the balance between measurement and culture.
Metrics provide:
- Transparency
- Alignment
- Diagnostic capability
But they can also generate:
- Stress
- Opportunistic behaviors
- Loss of focus on real value
That's why at Ocado, it is emphasized that each team should decide what to measure according to its context, avoiding imposing universal metrics.
Productivity as a Development Experience
A significant change in recent years is moving from measuring productivity to measuring Developer Experience (DevEx).
This involves focusing on questions such as:
- What frictions do teams encounter?
- How much time is lost on unnecessary tasks?
- How do tools impact their efficiency?
The hypothesis is clear:
👉 Improving team experience is the most sustainable way to enhance productivity.
What Product Organizations Can Learn
From the Ocado case and the reflections of the Runroom LAB, we can extract several key principles:
1. Define the purpose of measurement
Before choosing metrics, answer: what do you want to improve?
2. Avoid simplistic metrics
Isolated output does not reflect the real value generated.
3. Prioritize context over standardization
Each team needs its own indicators.
4. Measure the system, not the people
Productivity is a collective phenomenon.
5. Improve experience to enhance performance
Reducing friction is more effective than demanding more output.
Conclusion
Measuring productivity in product teams is not about dashboards or isolated KPIs. It is an exercise in deep understanding of the system, the people, and the context in which they work.
The case of Ocado Technology shows that the most advanced organizations do not seek to measure more, but to measure better. And above all, to use that information to build environments where teams can work more effectively, sustainably, and aligned with business value.
Tools and Resources of Interest
In the talk, Toni mentioned some tools. Here is the complete list to explore:
Here are several useful resources that Toni generously shared with us, in case you are interested in delving deeper into this topic. They are gold!
- Ocado Technology Development Manual: https://handbook.ocado.tech/
- Orosz, Gergely. 2022. Measuring Software Engineering Productivity. Newsletter. The Pragmatic Engineer. 5 July 2022
- Orosz, Gergely, and Abi Noda. 2024. Measuring Developer Productivity: Real-World Examples. Newsletter. The Pragmatic Engineer. 16 January 2024
- Orosz, Gergely. 2024. A New Way to Measure Developer Productivity – from the Creators of DORA and SPACE. Newsletter. The Pragmatic Engineer. 30 January 2024
- Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. 2021. The SPACE of Developer Productivity. ACM Queue 19 (1)
- Noda, Abi, and Tim Cochran. 2024. Measuring Developer Productivity via Humans. Martinfowler.Com (blog). 19 March 2024
- McKinsey & Company, Chandra Gnanasambandam, Martin Harrysson, Alharith Hussin, Jason Keovichit, and Shivam Srivastava. 2023. Yes, You Can Measure Software Developer Productivity. 17 August 2023
- Orosz, Gergely, and Kent Beck. 2023. Measuring Developer Productivity? A Response to McKinsey. Newsletter. The Pragmatic Engineer. 29 August 2023
- Orosz, Gergely, and Kent Beck. 2024. Measuring Developer Productivity? A Response to McKinsey, Part 2. Newsletter. The Pragmatic Engineer. 30 January 2024
- Beck, Kent, and Orosz, Gergely. 2023. Measuring Developer Productivity? A Response to McKinsey 2. Newsletter. Software Design: Tidy First? 31 August 2023
- Beck, Kent. 2024. Productivity Measurement as a Tradeoff. Newsletter. Software Design: Tidy First? 11 January 2024