On this page
The Dev Better podcast discusses the flaws and impacts of traditional developer productivity metrics, such as lines of code written or tickets closed, which often fail to capture the full scope of a developer's work and can lead to a culture of overwork. The guest, Abi Noda, proposes an alternative approach: focusing on Developer Experience (DX). DX provides a more holistic view of productivity, leading to better organizational decisions and policies. The podcast also highlights the importance of direct communication with developers for a more accurate understanding of their productivity, rather than relying solely on system-based measures.
How does it apply to you?
This knowledge can be applied in real-world scenarios to improve the productivity measures of a software development team. By focusing on Developer Experience (DX), organizations can make better leadership decisions, increase developer productivity, and retain skilled engineers.
Flawed Measures of Developer Productivity
Many organizations adopt flawed measures of developer productivity in their pursuit of profit. These metrics often push developers to work harder, faster, and longer, but not necessarily smarter. These metrics give the appearance of control but often lead to a lot of frantic activity that does not necessarily result in more business value.
The content highlights the flaws in traditional developer productivity metrics like lines of code or the number of tickets closed. These metrics often fail to capture the full scope of a developer's work and can lead to a focus on quantity over quality. Software development organizations can use this insight to rethink their productivity metrics and focus on more holistic measures that capture the full scope and quality of a developer's work.
Focusing on Developer Experience
The content introduces the concept of Developer Experience (DX) as an alternative metric for developer productivity. DX focuses on the quality of a developer's work environment and the tools and processes they use. Software development organizations can apply this concept by prioritizing improvements to their development environment and tools, and by focusing on policies that enhance the work experience for their developers.
Avoiding the Pitfalls of Misguided Metrics
The content discusses the potential negative impacts of misguided metrics, including manipulation of metrics, overwork, and a hostile work environment. Software development organizations can use this knowledge to avoid these pitfalls by ensuring that their metrics are accurate, fair, and do not encourage harmful behaviors.
Direct Feedback from Developers
The content suggests that one of the best ways to understand developer productivity is to ask developers directly. This can be applied in software development organizations by regularly soliciting feedback from developers about their work experience, productivity, and any challenges they are facing. This direct feedback can provide valuable insights that may not be captured by traditional metrics.
Learning and Development
The content can also be used as a learning resource for software development organizations. The insights and discussions can provide valuable lessons for developers, team leads, and managers about the pitfalls of traditional productivity metrics and the benefits of a more holistic and developer-focused approach.
Developer Checklist
Understand the Limitations of Current Productivity Metrics: Acknowledge that current metrics, such as lines of code written or tickets closed, may not accurately represent developer productivity.
Avoid Misguided Metrics: Be aware that misguided metrics can negatively impact software engineering teams and the quality of their output.
Consider Developer Experience (DX): Consider adopting Developer Experience (DX) as a metric, which can lead to better leadership decisions, increased productivity, and retention of skilled engineers.
Be Aware of Metric Manipulation: Understand that metrics can be manipulated to present a false image of productivity, which can negatively impact team morale and business outcomes.
Consider the Unintended Consequences of Metrics: Recognize that well-intentioned decisions to measure productivity can have unintended negative consequences.
Avoid Toxic Metrics: Avoid metrics that encourage developers to game the system and focus on meeting the metric criteria rather than producing quality work.
Understand the Limitations of System-Based Measures: Recognize that system-based measures, such as commits and pull requests, may not provide a complete picture of productivity.
Ask Developers Directly: Consider asking developers directly about their productivity, rather than relying solely on system-based measures.
Use Psychometric-Based Approaches: Instead of one-on-one discussions or retrospectives, use rigorous, psychometric-based approaches that provide quantitative data.
Leverage the Power of Surveys: Use surveys to collect more detailed data, they can provide more information than just looking at pull requests, tickets, and commits.
Ask Developers Questions: This approach provides more data about what's holding back productivity and how things are going. It also helps avoid developers feeling like they're being measured by irrelevant metrics.
Treat Developers as Humans, Not Machines: Focus on the social interactions of your developers, rather than treating them like a financial system or the stock market.
Understand the Impact of Microservices on Team Productivity: Microservices have complicated the development process and require a deep understanding of the psychology of teams and how they operate.
Consider the Role of Psychology in Engineering Productivity: It's crucial to manage not just the technical aspects like pull requests and story points, but also the morale and motivation of the teams.
Focus on Developer Experience (DX): DX should be the focus of industry discussions rather than metrics like story points or cycle time. Understanding the psychology of engineering teams is more important than attempting to quantify their output.
Acknowledge There's No Silver Bullet in Engineering: There is no secret formula for enhancing engineering productivity. It's not about plugging numbers into a formula to achieve desired outputs.
Recognize the Role of Culture in Developer Experience: Culture plays a pivotal role in the developer experience. Leaders need to understand this link between technology and leadership for the safety and sanity of their teams.
Use DX to Improve Leadership: DX can improve leadership by enabling better understanding of the team's needs and challenges. This approach helps unblock developers and allows them to work more efficiently.
Enhance Developer Productivity through Improved Processes and Tools: To enhance developer productivity, improve the processes and tools that developers use rather than pressuring them to increase output.
Understand Developer Experience and Productivity Perception: Understanding and improving productivity is not about punishing or pushing developers, but rather about helping and enabling them.
Address Toxic Culture and Its Impact on Developers: Recognize the negative impact of unrealistic deadlines and toxic work cultures on developers. Treat developers as humans, not tools.
Promote Psychological Safety and Fast Feedback: Create a psychologically safe environment for developers where blameless post-mortems and open discussions about mistakes are possible.
Implement Developer Experience as a Key to Team Success: Implementing DevEx correctly can lead to improved retention rates and loyalty among engineers, thereby elevating a team's performance and productivity.
Challenge the Status Quo and Toxic Traditions: Encourage leaders in your organization to challenge existing norms and toxic traditions. Focus on improving the developer experience to increase the overall value and productivity of the team.
Value of Developer Experience: Understand that improving developer experience not only benefits the team but also leads to the production of more valuable software, increasing the company's worth.
Opportunity for Growth and Improvement: See the shift towards better developer experience not as a threat but as an opportunity for growth and improvement. Implement changes that foster this growth.
Connect with Industry Experts: Follow industry experts on platforms like LinkedIn for regular insights about developer experience and productivity. Subscribe to relevant newsletters for research and insights.
FAQs
What are some flawed measures of developer productivity? Flawed measures of developer productivity often focus on the quantity of work, such as the amount of code written or the number of tickets closed. These metrics fail to capture the full scope of a developer's work, which includes activities like design, architecture, bug fixing, and customer support.
What is the impact of misguided metrics on software engineering teams? Misguided metrics of developer productivity can harm software engineering teams and reduce the quality and value of the software they produce. They can also lead to distorted behaviors, such as developers writing more lines of code or unnecessarily breaking up their work into smaller units to demonstrate faster cycle times. This not only harms the business and development team, but also affects morale negatively.
What is the proposed alternative to flawed productivity measures? The proposed alternative to flawed productivity measures is the Developer Experience (DX). This metric leads to better leadership decisions and organizational policies. Benefits of this approach include increased developer productivity, business value, and retention of skilled engineers.
What are the limitations of output-based metrics? Output-based metrics, such as lines of code or tickets closed, provide a limited view of developer productivity. These metrics do not account for the quality or complexity of the work performed.
What are some negative impacts of collecting productivity metrics? Negative impacts of collecting productivity metrics can include the manipulation of metrics to present a false image of productivity, and the fear that tracking metrics such as pull requests may lead to a culture of overwork. The speaker also highlights the potential for these metrics to be weaponized, creating a hostile work environment.
What are the unintended consequences of productivity metrics? The unintended consequences of productivity metrics include the manipulation of metrics to present a false image of productivity, and the fear that tracking metrics may lead to a culture of overwork. When a metric becomes a target, it loses value. The speaker also discusses the negative effects of gamification in agile enterprise and the resultant bad practices that are being promoted.
What are the limitations of system-based measures? System-based measures have limitations such as being easy to count how many activities are happening and how quickly, but difficult to assess the quality of these activities. For example, it's easy to count the number of code reviews, but difficult to assess the quality of these reviews.
What is the proposed method to understand developer productivity according to the speaker? The speaker proposes asking developers directly to understand their productivity, instead of relying on system-based measures.
What method does the speaker emphasize for collecting data? The speaker emphasizes the use of rigorous, psychometric-based approaches that provide quantitative data.
What is the role of surveys in data collection according to the speaker? Surveys are powerful tools in collecting data according to the speaker. They can provide more data than just looking at pull requests, tickets, and commits and can provide both qualitative and quantitative data.
What is the impact of asking developers questions? Asking developers questions can provide more data about what's holding back productivity and how things are going. It can also help avoid developers feeling like they're being measured by irrelevant metrics.
What is the speaker's view on treating developers? The speaker emphasizes the importance of treating developers as human beings rather than as machines. Developers should be treated as a social network with conversations that need to be had across multiple teams.
What is the intersection of psychology and engineering? The intersection of psychology and engineering is where true productivity lies. It's crucial to manage not just the technical aspects like pull requests and story points, but also the morale and motivation of the teams.
What is the speaker's view on Developer Experience (DX)? DX should be the focus of industry discussions rather than metrics like story points or cycle time. The focus should be on understanding the psychology of engineering teams rather than attempting to quantify their output.
What is the role of culture in Developer Experience? Culture plays a pivotal role in the developer experience. The focus should be on how DX can enable better leadership.
How can DX improve leadership? DX can improve leadership by enabling a better understanding of the team's needs and challenges. This approach helps unblock developers and allows them to work more efficiently.
How to enhance developer productivity? To enhance developer productivity, leaders can either pressure developers to work faster or improve the processes and tools that they use. DX is about the latter approach.
What is the speaker's view on productivity perception? The speaker emphasizes that understanding and improving productivity is not about punishing or pushing developers, but rather about helping and enabling them.
What is the impact of toxic culture on developers? Toxic culture and unrealistic deadlines have a negative impact on developers. It's important to treat developers as humans and recognize their needs.
What is the importance of psychological safety and fast feedback? Creating a psychologically safe environment for developers where blameless post-mortems and open discussions about mistakes are possible fosters a fast feedback loop within the engineering team, leading to more effective problem-solving and productivity.
What is the role of Developer Experience in team success? DevEx is a crucial factor in elevating a team's performance and productivity. Implementing DevEx correctly can lead to improved retention rates and loyalty among engineers.
Why should leaders challenge the status quo and toxic traditions? Challenging the status quo and toxic traditions can lead to a focus on improving the developer experience. This not only makes the team more valuable to the organization, but also leads to the production of more valuable software, increasing the company's worth.
How does the speaker view the shift towards improving the developer experience? The speaker sees this shift not as a threat but as an opportunity for growth and improvement.
Where can listeners connect with the speaker for regular posts about DevEx and measuring developer productivity? Listeners can connect with the speaker on LinkedIn.
What resources does the speaker offer for insights and research on developer productivity? The speaker mentions his company's website (get dx. com) and a weekly newsletter available at newsletter. ob by not a. com, which provides insights and research on developer productivity for engineering leaders.
Resources
Abi Noda
Book - The Mythical Man-Month: This book by Frederick P. Brooks Jr. is a classic in software engineering. It discusses the concept of the 'mythical man-month', which is the idea that adding more people to a late software project will make it later. This book is a must-read for anyone interested in understanding the complexities of software development.
Article - The Agile Revolution: This article provides an overview of the Agile Revolution in software development. It discusses how the focus has shifted from tools to people and processes, and the impact this has had on the industry.
