6 Common Productivity Habits: Netflix, Google, Spotify

When I started my research for this article the goal was to answer this question:

“How do the best software companies and teams measure, benchmark, and improve product and engineering velocity?”

However, my search efforts returned little to no results. I searched to find articles on engineering velocity for companies, such as Netflix, Google, Spotify, Uber, Etsy, Instagram, Airbnb, etc. I wanted to find out how these companies measured and improved their engineering velocity. What I kept finding instead, were articles on engineering productivity.

This led me to believe that these companies placed little value on velocity but high value on productivity. Therefore, I ventured to explore how some of them approach their engineering teams’ productivity in an effort to find common best practices, which other software companies could learn from. The result is the information below.

Velocity vs. Productivity

Velocity is measured using the average amount of work a scrum team completes during a sprint, which can be measured in either story points or hours. This metric helps teams develop a stable work rhythm, predict project timelines, and manage stakeholder expectations. The velocity is calculated by taking the average of the total completed estimates over the last several sprints. For example, if a team completed 100 story points in five sprints, the average sprint velocity would be 100 / 5 = 20 story points. This value becomes more accurate and reliable over time as more data becomes available and the team gets better at estimating work effort.

According to Atlassian:
“While velocity is a useful planning tool, it has limitations and shouldn’t be the sole performance metric for evaluating a team. For a more comprehensive view of team performance, consider tracking other Agile metrics.

One significant limitation is that velocity doesn’t measure the quality of work or the delivered business value. It’s a quantitative measure that doesn’t account for the qualitative aspects of individual user story complexity.”

The article “Myth: Velocity is Productivity” discusses the misconception that velocity is a measure of productivity in the context of Agile and Scrum. It emphasizes that velocity is a measure of the amount of work a team can tackle in a sprint and is not indicative of productivity. The author argues that using velocity as a measure of productivity can be misleading and explains that velocity is a planning tool rather than a specific measurement. The article also highlights the importance of focusing on value delivery rather than simply increasing velocity. It concludes by emphasizing that velocity is an output, not a desire, and should only be used to help make forecasts, not as a measure of value.

The article “Velocity, the False Metric of Productivity” further explores the concept of velocity in Scrum, emphasizing that it is not a metric of productivity. It questions whether teams are focused on value delivery or simply on increasing story points, and it argues that velocity should only be used for making forecasts by the Product Owner. The article also discusses how an increase in velocity does not necessarily mean that a team is working faster, but rather that they may be working smarter. It concludes by stating that velocity is only helpful to the extent that it helps the business make forecasts and should not be used for any other purpose.

Engineering Productivity at NETFLIX

Netflix invests in engineering performance by focusing on software delivery enablement, team productivity, and developer experience. The company emphasizes qualitative metrics, such as user surveys and sentiment around tooling, to gauge developer productivity. It is important to note that they focus on team performance and not individual performance.

According to Kathryn Koehler, director of productivity engineering at Netflix, the company invests in a lot of user surveys with questions such aiming to understand “what does toil look like for you,” and “how hard is it for you to do your job”.

Netflix also leverages the SPACE developer productivity framework, which includes factors related to satisfaction, performance, activity, communication, and efficiency.

The SPACE framework for understanding developer productivity consists of five dimensions:

Satisfaction and Well-being: Measures how fulfilled developers feel with their work, team, tools, or culture, and how healthy and happy they are.
Performance: The outcome of a system or process, which is hard to quantify in software development.
Activity: A count of actions or outputs completed in the course of performing work.
Communication and Collaboration: Captures how people and teams communicate and work together.
Efficiency and Flow: Captures the ability to complete work or make progress on it with minimal interruptions or delays.

Additionally, the organization aims to enable its technical community to focus on their day jobs through continuous improvement and by providing first-class supported infrastructure, language, and tooling.

“At its core, the greater Netflix productivity and platform division looks to abstract out anything that distracts developers from their flow state.” – The New Stack

While Netflix tracks some quantitative (Example DORA) metrics, it prioritizes continuous improvement over measurement for the sake of change management.

Engineering Productivity at GOOGLE

Google’s approach to engineering productivity focuses on optimizing the workflow for collaborative code development, ensuring modularity of architecture, and maintaining near-continuous integration.

The company emphasizes the importance of managing technical debt and optimizing velocity while considering the long-term implications of configurability in software development.

Google’s Engineering Productivity Research team employs a mixed-methods approach to measure developer productivity, capturing three key aspects: speed, ease, and quality. This approach involves both quantitative and qualitative research, including the use of logs, surveys, and interviews to assess the developer experience.

Here is a little more about each of the key aspects:

Speed: Google emphasizes the importance of speed in software development, aiming to enable rapid exploration of new ideas, quick responses to changes or issues, and efficient deployment of code. This involves optimizing workflows, managing risk, and enabling developer velocity at scale.
Ease: The company seeks to make the development process as smooth and efficient as possible, reducing cognitive effort and streamlining tasks. This involves investing in tools, infrastructure, and processes to speed up development, automate routine tasks, and provide opportunities for upskilling.
Quality: Google places a strong emphasis on the quality of code and processes. This includes measures such as automated testing to increase code coverage and reduce bugs, addressing code review feedback, and investing in infrastructure to ensure high-quality code.

Google’s approach to measuring these aspects involves a combination of quantitative and qualitative methods, including capturing various metrics through developer experience surveys, system data, and a mixed-methods approach to measurement. The company’s Engineering Productivity Research team uses these measures to understand the developer experience and identify areas for improvement, ultimately aiming to optimize the engineering process for faster delivery and polished products.

To enhance engineering productivity, Google invests in tools and infrastructure that facilitate automated testing, code reviews, and rapid deployment processes. The company also prioritizes a balance between speed, ease of development, and code quality, recognizing that improvements in one area should not compromise another.

Google’s engineering productivity team, which includes a diverse group of engineers and UX researchers, collaborates with various departments to understand and improve the overall developer experience. This holistic approach aims to deliver frictionless engineering and improve the effectiveness and efficiency of software delivery teams.

Engineering Productivity at SPOTIFY

Spotify measures and improves the productivity of its software engineering teams through various metrics and initiatives.

The company measures engineering productivity, efficiency, and effectiveness by using several metrics and indicators. These include:

Time-to-10th PR: This metric measures the time it takes for a new engineer to merge their 10th pull request, serving as a proxy for the overall complexity of the engineering ecosystem2.
Number of merges per developer/day: This metric reflects the time spent on jumping between different tools and looking for information, allowing more focus on shipping code2.
Reduced context switching: Measured by the number of different tools an engineer has to interact with to complete a certain job, aiming to reduce interruptions and help engineers stay focused2.
Ease of discovery: Metrics like search success rates, click-through rates, and search results relevance are used to measure an individual contributor’s ability to quickly find the information they need within the internal shared knowledge base.
Reduced context switching – By minimizing context switching, engineers can maintain focus and productivity. We gauge this by the variety of tools an engineer needs to use to complete tasks, such as making changes, deploying them, and ensuring they work properly in production.
Build time: The number of builds on the continuous integration pipeline per day impacts developer satisfaction, reflecting the speed at which things are built2.

Additionally, Spotify conducts an official engineering satisfaction survey called EngSat to gather feedback from its engineering teams every quarter.

Furthermore, Spotify’s Platform Insights team sets OKRs and metrics to connect developer productivity with company-wide objectives.

The company has also worked on improving developer productivity for its DevOps teams by providing the right tools, automating processes, reducing complexity, and creating best practices like Golden Paths.

Are you facing hurdles in optimizing your software development process and boosting engineering productivity?

As a tech company owner or leader, you’re likely juggling numerous challenges, from managing technical debt to ensuring seamless collaboration among your teams. My Fractional CTO services offer a solution tailored to your specific needs. I can help you navigate these challenges effectively, providing strategic insights and actionable recommendations.

Ready to take your tech company to the next level? Reach out now to learn more about my Fractional CTO services.

Common Habits

When it comes to measuring and improving engineering productivity every company is different and does things differently. However, upon examination of their best practices, some common habits emerge across all three Netflix, Google, and Spotify.

These could be used as inspiration to create your own best practices at your software company and thus improve the productivity of your own engineering teams.

Productivity is Not an Afterthought
Each company is very intentional on measuring and improving its engineering teams’ productivity. In most cases there are dedicated people and teams focused on these efforts.

Focus on a Streamlined Development Process
Prioritizing the developer experience, aiming to make the development process as smooth and efficient as possible. They invest in tools, infrastructure, and processes to speed up development, automate routine tasks, and provide opportunities for upskilling.

Attention to Developer Satisfaction and Happiness
Regularly measuring developer satisfaction and well-being to understand how fulfilled developers feel with their work, team, tools, or culture, and how healthy and happy they are.

Focused and Distraction-free Environment
Making intentional efforts to reduce distractions, context-switching, and create processes which allow engineers to get and stay in the zone.

Infrastructure and Tools
All three companies invest in tools and infrastructure that facilitate automated testing, code reviews, and rapid deployment processes.

Continuous Delivery and Fast Deployments
Placing importance on measuring and improving engineering activities that really matter. In other words, the ability to regularly integrate code changes and regularly deploy them into production.

Conclusion

In conclusion, the research into engineering productivity at Netflix, Google, and Spotify reveals a nuanced approach to measuring and improving productivity.

While velocity is a useful planning tool, it has limitations and shouldn’t be the sole performance metric for evaluating a team.

Instead, these companies focus on a combination of quantitative and qualitative measures, including developer satisfaction, ease of development, and code quality. They invest in tools, infrastructure, and processes to streamline development, reduce distractions, and create a focused and distraction-free environment.

By prioritizing the developer experience and continuous improvement, these companies aim to optimize the engineering process for faster delivery and polished products.

“Engineering is, of course, a science, which is why high-performing organizations like Netflix, Google, LinkedIn, Spotify and Atlassian are all measuring their platform teams’ impact on developer productivity. The difference is that they are focused on measurement not for change management’s sake, but rather for continuous improvement of their own craft.” ~ The New Stack