Andrew Boyagi
Contributor
Andrew Boyagi is a DevOps Evangelist at Atlassian with extensive experience in software delivery and service management in enterprise organizations. He provides a practical perspective on how teams and organizations can maximize the benefits of DevOps based on real-life experience.
There’s an unhealthy obsession with companies looking for a way to measure developer productivity.
Over the last 20 years, I’ve led multidisciplinary technology teams across some of Australia’s largest enterprises. Most recently, I led the development of an internal development platform, supporting the experience of over 7,000 engineers as an executive manager at the Commonwealth Bank of Australia. Today, I lead the DevOps Evangelism team at Atlassian, where I regularly meet with Fortune 500 companies, traveling the world sharing insights and guidance on optimizing for high-performing and engaged software teams and leadership.
In my conversations with senior leaders, I’ve come to understand the desire to measure productivity. Senior leaders are under pressure to deliver results while capitalizing on their investments in teams and technology. There are no sinister intentions behind measuring developer productivity; leaders genuinely want their teams to be as productive as possible. The problem is that developer productivity is incredibly difficult to measure, resulting in organizations allocating disproportionate effort and resources while trying to find the magic measure. This investment in measurement takes precious time away from initiatives that could help developers be more productive.
Imagine the possibilities if the same amount of time and energy was invested in improving developer productivity rather than trying to measure it.
Fact: Happy developers are productive developers
Happy employees are productive employees may seem like an obvious statement, but this gets lost in the developer productivity discussion.
Think back to any high-performing developer you’ve worked with; chances are they’ve gone above and beyond what was formally expected of them. This developer was likely highly engaged, had everything they needed to perform at their best, and generally enjoyed their work.
The behaviors associated with employees who “exceed expectations” are known as have organizational citizenship behavior (OCB) and are driven by job satisfaction. Thousands of academic research papers back the notion that satisfied employees are productive employees — software developers are no exception.
So, if satisfied developers are productive developers, developer productivity is a by-product of developer joy.
Inputs to developer joy
There are two main inputs to developer joy: developer experience and engineering culture.
You can think of developer experience (DX) as how developers feel about the tools and frameworks they use to build software. DX is heavily influenced by the quality of tooling and efficiency of processes used by developers to create software within an organization.
Developer experience refers to how engineers emotionally connect with their work, while engineering culture encompasses how work is done within an organization. It’s a fusion of an engineering organization’s values, practices, and norms. Leadership style, company mission and vision, team structures, decision-making processes, and the overall work environment heavily influence culture.
Leadership can influence culture but needs to be molded and evolve over time. On the other hand, organizations have direct control over the experience of developers within their company. Intentionally improving developer experience significantly impacts developer joy and, therefore, leads to improvements in productivity.
Steps to intentionally improve developer experience
Intentionally improving developer experience is the most potent way to improve developer productivity within an organization. Every organization has different challenges and needs to go on its own journey, but three common steps can turbocharge progress.
Step 1: Understand the current experience
Developer experience is how engineers feel about the tools they use to create software within their organization. The only people who know what the developer experience is like at a company are the developers, so the first step should be to get their perspective.
I once spent two full weeks asking developers one simple question: “How can we improve the way we deliver software?”
I walked away from two weeks of conversations with a two-year backlog of things we could do to improve the developer experience and, as a by-product, improve productivity. If you ask developers how to improve their experience, they will definitely tell you. This is free, requires no preparation other than memorizing a single question, and you can start today.
Speaking to developers is a significant first step, but it’s not scalable across a large organization.
Developer experience surveys are a great way to get a pulse check on developer experience at scale. You can use the information gathered in DX surveys to track improvements in specific focus areas and identify new focus areas.
Step 2: Empower a platform team
Platform teams are an internal group focusing on providing a great developer experience. Platform teams provide internal services to software delivery teams, enabling them to self-serve and work autonomously. These services might include infrastructure, CI/CD, monitoring and logging tools, or making it easy to understand and comply with company standards and practices.
Remember that DX is about how developers feel about the tools and frameworks they use to deliver software.
Centralizing these tools and frameworks under a platform team means one group is responsible for these within an organization. Logically, enabling a positive developer experience should be the primary goal for a platform team.
Step 3: Drive DX at scale with a developer experience platform
Platform teams use platforms as a vehicle to deliver an excellent experience for their customers — the developers. A good developer experience platform does this in three ways:
Reduces cognitive load for development teams. This means reducing the amount of information they need to remember while working in your organization.Promotes a healthy engineering culture. This is achieved through learning and continuous improvement.Allowing developers to easily extend the platform. This allows developers to solve your company’s unique challenges.
Thoughts on measuring developer productivity
A lot of people misquote Peter Drucker’s “You can’t improve what you don’t measure” when it comes to developer productivity and use this as a justification to measure the wrong things in the wrong ways.
Developer experience and engineering culture are the two inputs to developer joy, which results in developer productivity. These two inputs are unique to every organization and can’t be replicated; given their huge impact on developer productivity, what you choose to measure should also be unique to your organization. Copying metrics from another company is unlikely to work for your company and will probably make things worse.
This doesn’t mean you need to start from scratch; some companies are doing this well. Rather than copying their metrics, you should take inspiration from their journey to find suitable measures for their organization. Learn about the process they went through to find appropriate measures and follow similar steps. It will be a journey well worth the time and effort.
Developer experience for the win
Improving developer experience within an organization leads to satisfied, more productive developers.
Companies that work toward improving developer experience and engineering culture will have productive developers and will outperform their competitors.
Other companies will still be looking for ways to measure developer productivity.
I know which type of company I would prefer to work for.
