Bigfoot and the mythical 10x developer have a lot in common: Sightings are rare and not definitive. However, although many people have a fuzzy idea about what a Bigfoot looks like, the profile of the 10x developer—the developer who is 10 times more productive than their peers—is more elusive.
This is because notions of the 10x developer are based, at least in part, on undefined or commonly agreed-upon measures of individual productivity and the assumption that those measures can be deployed to assess the relative productivity of team members. One problem with the concept is that even if a reliable measure of personal productivity exists, it’s unclear how it can be reliably correlated with meaningful business outcomes. Instead, many IT leaders believe that focusing on eliminating the net negative developers would be more impactful.
Despite being derided and dismissed by developers since its inception, the concept of the 10x developer, first introduced in research published in Peopleware circa 1987, is alive and well with IT leadership. Why? It aligns with the prevailing assumption that productivity is primarily a people issue that can be addressed using management best practices and tools, such as recruiting practices, skill-gap analysis, training, activity monitoring, surveys, and compensation strategies.
As the theory goes, using these tools to find, develop, and retain top performers, i.e. 10x developers, will result in outsized levels of productivity. This approach aims to set and raise the individual productivity bar for the entire team in the hope that everyone can be a 10x developer, whatever that means.
Enter developer productivity engineering
Elite development teams understand that many traditional productivity management approaches, while necessary and effective, are not sufficient. They understand the limitations of an approach that focuses on scaling individual productivity from a 1x to a 10x developer. As a result, they are embracing a more modern approach to developer productivity called “developer productivity engineering” (DPE). DPE is an emerging practice used by the likes of Airbnb, American Express, Apple, JPMorgan Chase, Google, and Netflix to improve developer productivity and the developer experience. DPE shifts the focus of IT leaders from cultivating 10x developers towards building a 10x team.
If you are skeptical about the existence of 10x developers or the usefulness of the concept, it stands to reason that you would be 10 times more skeptical about the notion of 10x development teams. As a result, it’s important to frame the “10x development team” as a vision and strategy for continuous improvement that can be enabled by the practice of DPE. DPE will not by itself create a 10x team.
Further, a 10x team is a moving target where the relevant comparison is with your competitors’ development teams. As a result, the business value is in the journey and not the destination because you will never know if you have arrived as competitors strive continuously to move the goalposts. Yet navigating this journey successfully is mission-critical. Success is predicated on embracing three changes in strategic thinking that are at the heart of the DPE approach.
From people problem to technology challenge
10x teams change the focus of viewing developer productivity as a people problem, addressable primarily by management best practices, to a technology challenge, addressable by engineered solutions. Engineered solutions solve productivity bottlenecks and process friction with acceleration technologies and analytics that leverage automation and data.
In other words, while traditional developer productivity management focuses on answering questions like “How do we make developers more productive when waiting for build and test cycles to complete?” DPE asks ”Why does it take so much time for build and test cycles to complete in the first place? How can we bring data and technology to bear to fix this?”
For example, one of the biggest developer productivity pain points is slow builds and tests that cause idle time and unnecessary context switching. Engineered performance acceleration technologies like build caching, machine learning-driven test selection, and test distribution can bring build times down 90%. The result is that developers spend less time waiting, and they build and test more often while staying in the creative flow.
This re-engineering of builds and tests has a “shift left” effect on developer productivity and quality, as problems are less likely to show up in CI where they are more expensive to detect and fix. Additionally, when failures occur, troubleshooting broken builds can cause toil and frustration. DPE technologies like Gradle Build Scan make finding and addressing the root cause of build failures dramatically more efficient.
From individual output to team outcomes
Traditional developer productivity management focuses on individual output, whereas DPE prioritizes team outcomes. Elite development teams recognize that human metrics of productivity output are flawed (see The Pragmatic Engineer). They can be gamed, they don’t tell the whole story, or, in some cases, they’re completely arbitrary. Moreover, they can even violate the “do no harm” principle by incentivizing counterproductive behaviors. Consider the developers that spend less time exercising their prized mentoring skills because they are measured on their output in terms of function points, or bugs closed. Further, many output metrics are antithetical to the craft of writing elegant and concise code in favor of rewarding verbose code.
DPE targets the bottlenecks in the software development lifecycle and toolchain, and provides the data that can be used to speed them up. Key metrics include build and test time, cost avoidance savings, failure rates, and mean time to recovery from failures. Rather than targeting individuals, DPE solutions benefit all developers equally, increasing the base level of productivity for the entire team, like a rising tide that lifts all boats. Most importantly, these metrics can be tied reliably to business outcomes like software time to delivery, development costs, quality, and even brand.
From soft ROI to hard ROI investment decision-making
It’s impossible to determine the return on your investment in traditional productivity management initiatives. DPE metrics can deliver measurable business outcomes that can be monetized to determine a hard ROI, and used to justify your initial business case and on-going investments to mature your DPE practices.
For example, you can calculate the hard savings from achieving faster build and test feedback cycles leveraging DPE performance technologies by using a simple formula: Multiply the average time saved waiting for builds to complete by the number of builds per year to get total time savings in engineering years, and then multiply that by the cost of a fully-loaded engineering year. For many moderate-size development teams, this quickly translates into millions of dollars of cost avoidance based on double-digit savings measured in engineering years.
Ultimately, DPE represents a revolutionary approach to developer productivity because it uses modern technologies to raise the bar for team outcomes. Although practicing DPE will not by itself deliver a 10x team, it provides a strategy for continuous improvement. The business value is in the journey and not the destination, and navigating the journey is mission critical to any company’s competitive health. With that, instead of focusing on finding the next Bigfoot among software developers—the 10x developer—companies should embrace DPE in pursuit of the 10x team.
Hans Dockter is the CEO and founder of Gradle Inc., inventor of the open source Gradle Build Tool, and the world’s leading expert on and advocate for the emerging practice of Developer Productivity Engineering (DPE), for which Gradle Enterprise is the leading enabling technology platform. Hans has a long and proud history with the open source community. Gradle Build Tool is the most popular build tool for open source JVM projects on GitHub. Gradle Enterprise is an open platform that supports multiple open source build tools, including Apache Maven and Bazel, in addition to Gradle Build Tool.
—
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.