The 3 Stages of Evolution for Developer Productivity
In the past 10 years, technology organizations have started to understand the importance of keeping their software developers productive and happy by creating an environment where they can feel effective.
“An effective environment makes it easy to put useful, high-quality software into production; and to operate it so that the developers do not have to deal with unnecessary complexities, frivolous churn or long delays — freeing them to concentrate on value-adding tasks.” — Maximizing Developer Effectiveness, martinFowler.com
At YourBase, we’ve worked with hundreds of software companies and have identified 3 main stages of organizational evolution, based on the importance placed on Developer Productivity and Happiness.
Stage 1: Development Resources Merely Support the Business
Many organizations view development resources as supporting the business, and more highly value business metrics as compared with engineering-driven growth and innovation. These types of organizations may think of developers as a cost center, and may view engineering teams more as IT resources. For businesses like these, the developer experience may be an afterthought.
Ideas and initiatives arising from development are unlikely to gain traction. Developers, who can be a huge source of innovation and creativity for new technological opportunities, are overlooked. Developers face friction when trying to make changes in production and are stuck doing work to “keep the lights on”.
For organizations committed to moving to the next stage of evolution, the first step is to develop awareness of the pitfalls of treating development merely as a cost center. To move forward, organizations can start to observe and measure the friction points in the development process, for example, in terms of time developers spend waiting on humans or machines.
Stage 2: Developer Productivity Is Worth Tracking and Improving
These types of organizations have begun to care about developer productivity.
The company realizes that developers benefit from having a clear understanding of the business goals, and that they need access to tools and resources to do their job efficiently and well. In this stage, many companies begin to measure the developer experience, and start to invest in tooling and processes to help developer workflows proceed more seamlessly. While individual developers or engineering managers have started to internalize the importance of these investments, it is likely that a dedicated team for developer productivity has not yet been established.
As part of the transformation to a culture where developer productivity is valued, organizations may end up relying too much on metrics, despite good intentions. They may over-index on keeping devs “productive”, focusing on quantitative metrics, such as number of code commits or bugs introduced, which can be noisy and easily gamed. Or, grassroots efforts to improve developer productivity arise organically, but may have trouble gaining adoption across broad swaths of the engineering organization.
As Nicole Forsgren et al. shared in The SPACE of Developer Productivity, there are plenty of myths about measuring developer productivity, and “Far too often teams or managers attempt to measure developer productivity with simple metrics, attempting to capture it all with ‘one metric that matters.’”
While quantitative measures may provide some insight, the key is to develop a balanced quantitative and qualitative analysis program to enable devs to perform at their best. One organization described an approach where they used sentiment indicators and a measurement of build time and to pinpoint that build time variability was key for their development team’s productivity:
“We have a pretty decent idea of how long builds take and we have lagging indicators of sentiment…Even more than reducing the build time, it’s making build times less variable that’s been really important to us. When build times fluctuate a lot, engineers don’t have decent expectations for when they know they can check back in.” — Iain, Engineering Manager, Human Resources Technology Company
Stage 3: Developer Happiness Is a Critical Lever for Growth
These organizations understand that developer productivity is a point of leverage and competitive advantage for recruiting and retaining quality teams. They likely have teams dedicated to improving the developer experience and think about it as a critical company concern. In these companies, innovation arises from developers who bring their ideas to life with the help of tools that enable them, rather than getting in their way.
“Developer productivity affects more than just getting code out the door, but it can actually affect developer’s mental states, in a good way or a bad way. If you’re finding that you’re trying to push code out the door, and you’re getting stuck over and over again on something that you can’t change, that can really burn people out and cause them to go elsewhere.” - Kent Willis, Yelp, Developer Productivity at Scale
Developers are motivated by doing fun work. When developers feel they are stuck in a daily Sisyphean struggle trying to do their jobs, their frustration mounts, and they start brushing up their resumes. Avoid this by investing in a Developer Productivity and Happiness team at your organization.