Download to read offline
More Related Content
Similar to DevOpsDays Atlanta 2025 - Building 10x Development Organizations.pptx
![[NYC Scrum] 4 bad ideas about productivity... and what Agilists should do ins...](https://cdn.slidesharecdn.com/ss_thumbnails/nycscrum4badideasaboutproductivity-250320014757-d85c2fbe-thumbnail.jpg?width=640&height=640&fit=bounds)
DevOpsDays Atlanta 2025 - Building 10x Development Organizations.pptx
- 1. Building 10x DevelopmentOrganizations Using Developer Experience Metrics and Frameworks
- 2.
- 3. Every Myth hasan Origin
- 4. The Results -And The Truth of the 10x Org 21% Difference in Productivity Between Engineers Working In Same Organization 11.1x Difference In Productivity Between Highest and Lowest Performing Organizations “While this productivity differential among programmers is understandable, there is also a 10 to 1 difference in productivity among software organizations.” –Harlan (HD) Mills, Software Productivity in the Enterprise
- 5. The best performersare clustering in some organizations while the worst performers are clustering in others. Some companies are doing a lot worse than others. Something about their environment and corporate culture is failing to attract and keep good people or is making it impossible for even good people to work effectively.
- 6. Encouraging flow state andminimal context switching matters more than language, salary, and tenure.
- 9. DevOps, DORA, etc,have still not captured all bottlenecks, friction, and obstacles to throughput Many are hiding in plain sight, in the developer experience itself A 10x organization should consider every aspect of the developer value stream, internal and external
- 12. No one knowsmore about the friction in the software development lifecycle than developers. So what if we just asked developers…
- 13. Quantitative Metric QualitativeMetric PR Cycle Time I work on small, iterative changes: Never Rarely Sometimes Very Often Always Commit Frequency I have uninterrupted time for deep work: Never Rarely Sometimes Very Often Always Time To First Review I receive code reviews in a timely manner: Never Rarely Sometimes Very Often Always
- 14.
- 15. S Satisfaction P Performance A Activity C Collaboration E Efficiency DF Deployment Frequency LTFC Lead Timefor Changes MTTR Mean Time to Resolve CFR Change Failure Rate FS Flow State FL Feedback Loops CL Cognitive Load
- 16. The Core 4- DORA, SPACE, and DevEx
- 19. Each one-point gainin DXI score translates to saving 13 minutes per week per developer, equivalent to 10 hours annually. … and yes, the math proof is available. :)
- 20. Knowing how tomeasure productivity or even define developer productivity has remained elusive. The Core 4 is the best possible way available to do it.
- 21. Slides, Recording, andContact Info https://getdx.com/talk/devopsdays-atl- 2025/
Editor's Notes
- #2 The myth of the 10x engineer is pervasive, but, as we will explore throughout this workshop, it is just that, a myth. We’ve all heard of the concept, that engineer that is somehow able to produce at 10x the rate of their peers, but in study after study of organizational productivity, engineers within a single organization tend not to significantly outperform one another, with a few exceptions.
- #3 Every Myth has an Origin Story… In 1977, Tom DeMarco and Timothy Lister devised a study called the Coding War Games From 1984 – 1986, more than 600 developers from 92 companies participated The purpose was to discover the ”best” and “worst” traits of developers The competition unit was a pair of programmers from the same organization These were not peer programmers, in fact they competed against each other A program specification was fixed, and participants logged their time in completing it Participants used their own workspace using familiar tooling and languages This study is the foundation for an excellent book on building highly productive organizations, though part of why we are here today is that this book was last published in 2013!
- #4 Unpaired programmers from the same organizations performed at roughly the same level The average difference was only 21% between participants at the same company They didn’t work together on the task, but they came from the same organization The best organization performed 11.1x better than the worst
- #5 So, we don’t have 10x developers, *but we do have 10x organizations!* (11x, really)
- #6 Non-factors also interesting: Language - With the exception of assembly Salary - Only 10% diff in salary between top and bottom performers Experience - 2 - 10 years largely the same (dip at 6 months) Number of Defects - Top performers provided defectless code
- #7 DORA was really the first on the scene to try and measure DevOps outcomes. not only do the four key DORA metrics specifically apply to software engineering, but it gives a direction of what to do to get better. So this is where a lot of engineering leaders started, or do start today.
- #11 And so we have witnessed the rise of the platform engineer, a role that includes disciplines learned from DevOps, and combines them with optimizing the experience of the platform user, i.e. the developer, and delivering these platforms in a way a product manager would deliver to customers. Developers become internal customers.
- #12 Developer experience is all about going to the developers for the answers. So we can start an improvement cycle by asking devs about current conditions, setting targets, using other metrics to track progress, and then evaluate whether we’re reaching our goals.
- #15 Now we are getting somewhere!! We have some great sets of metrics with precedent, validated by real engineering teams… But could we streamline this even further? Each of these metrics can influence other metrics, we learned that from SPACE, could we reduce these based on those correlations?
- #16 YES! Presenting: the most modern developer experience and productivity metric framework available, the DX Core 4. The most effective metrics have been pulled by these three major metric sets, and move into four new dimensions of Speed, Effectiveness, Quality, and Impact
- #17 The DXI is a formative measure of how, and to what extent, the right conditions exist for developers to be able to deliver effectively. The DXI measures 14 dimensions (Figure 2) found to be actionable (and changeable) at both the manager and organizational level, such as deep work, local iteration speed, release process, and confidence in making changes. DX uses linear regression analysis to assess the strength of the relationship between the DXI and time waste, and for modeling the predictive relationship between them. The most recent analysis of DXI was conducted in early 2024, based on a sample of 50,000 responses from 200 organizations. The DXI is calculated by taking the mean 16 items corresponding to key dimensions of developer experience. Efficiency is calculated through a self-reported outcome measure of time loss due to inefficiencies in the work environment. Past research by DX identified a comprehensive set of factors underlying developer experience. In designing the 14 dimensions included in the DXI, our researchers took into account both the actionability of issues for management and predictive power against outcomes such as engineering velocity, quality, and efficiency.