Engineering productivity starts with strategies, tactics, & metrics

A Google search for “engineering productivity” turned up 325 million results, three times more than a search for “Agile” and about the same number as “DevOps.” Clearly, engineering productivity is a sort of holy grail for most (if not all) development teams, but it’s equally clear that there is so much to say about it all.

We believe engineering productivity is achievable in any organization with the right combination of strategies, tactics, and metrics – and we did the Google searching so you don’t have to. Here’s everything you need to know to establish sustained engineering productivity in your organization.

What is engineering productivity?

The definitions of engineering productivity range from vague to granular, but generally speaking it’s a way to assess and measure the efficiency of the people, processes, tools, and outcomes in an engineering team. A truly “productive” engineering team will need less time to create and release code than is typical in the industry and will also be able to pivot quickly to adjust to new demands or changing business priorities. Teams on track also create high-value code that is directly tied to what matters most to the organization because engineering productivity has business alignment baked into it.

That’s all a long way of saying you probably won’t know engineering productivity when you see it. Instead, the process begins with measurement and metrics because it’s impossible to assess performance without actually tracking results.

Teams need a snapshot of where they are and a roadmap to where they want to be that includes business value drivers and a product outline, along with a commitment to regular metrics measurement. And, finally, a productive engineering team has to *stay* productive, so along with metrics and strategies and tactics, it’s important to support a culture of continuous improvement and re-evaluation – luckily metrics can really help with this. 

Why is engineering productivity important?

Every company may be a software company today, but that doesn’t guarantee the engineering process is either efficient or easy for the C-Suite to understand. Time to market has never been more critical and it’s well-documented that most tech organizations are being asked to do more with less. Also at play is the very real impact of employee burnout, coupled with a longstanding shortage of software developers. So it’s no surprise that making software development more efficient, while at the same time making it more transparent and aligned to business objectives, is job one for most organizations.

Surprising barriers to engineering productivity

When teams take a hard look at where they are, and what’s working and not, there will likely be some surprises along the way. We share this to underscore the importance of looking at your organization closely because one size will never fit all.

So it turns out the very nature of software development is what can slow teams down. For example, in any given week developers spend just 43% of their time coding applications, according to a survey done by Infragistics in March 2023. And when they’re not coding they’re… waiting. A lot. Retool’s 2022 State of Engineering Time Survey found 38% of non-management developers wait on other people and 42% are idle while machines do their thing. Other things that potentially undermine productivity include hunting for documentation and relevant context (37%), unraveling merge conflicts (34%), and resolving flaky tests or broken builds (41%). And the 2022 Stack Overflow Annual Survey found 37% of developers spend between 30 and 60 minutes every day just searching for answers to questions.

And then there is the question of developer happiness. The research is in and the answer is yes, happier software developers report that they are more productive and better at problem-solving. What makes developers less than happy? Being “stuck,” time pressure, and having to deal with bad code are the top three things that can tip devs over the edge. Like all creative endeavors, developers want to achieve “flow” in their work, meaning they’re rolling along, able to focus, and in the “getting it done” zone. Upsetting the flow through meetings, context switching, or other hiccups can also lead to increased developer frustration and reduced output.

Strategies to jumpstart engineering productivity

While there is no substitute for a well-thought-out productivity plan of action, sometimes it’s helpful to just have a quick win. Quick wins are just that – successes that come rapidly and don’t hurt too much. They can often be a morale booster and can help pave the way for the bigger conversations around engineering productivity measurement metrics and other sweeping changes that may need to happen.

Three approaches are regularly mentioned as productivity jumpstarts: the Pomodoro Technique, eating the frog (first thing), and the Pareto Principle. (We should add that these strategies stand in stark contrast to some well-known developer “busywork” patterns, aka Yak shaving.)

The Pomodoro Technique was invented in the 1980s by a then-college student in Italy who broke his work up into 25-minute chunks using a tomato-shaped timer. A bit like timeboxing, teams can divide work into “pomodoros” with breaks in between. A stretch of 3-4 pomodoros would then be followed by a longer break. The Pomodoro method is widely used in pair programming and is a popular time management method the world over. 

The idea of “eating the frog” is a way to get a time-consuming, annoying, or simply distasteful task over with early in the day. Get the worst stuff over with first, and the rest of the day looks much better in comparison. Engineering teams wanting to consume the frog might consider starting the day by tackling tech debt, or outstanding pull requests, or even code reviews.

The Pareto Principle might be better known as the 80/20 rule, meaning 80% of the impact is found in 20% of the effort. This is a well-known philosophy in software development (“80% of an application’s functionality is the result of 20% of developer effort” is an often-repeated statement), but it requires a clear-eyed understanding of the big picture in order to focus on what will matter most.

Tactics to support engineering productivity

On the journey to a maximally productive engineering team, organizations should consider anything that can block forward momentum and flow. Here are five areas to explore:

Start with developer experience (DX). From tools to processes, poor DX can quickly lead to poor retention rates and make it even harder to hire. Management needs to continually reassess the status quo and ensure the developer experience is actually positive, not just less painful. Experts suggest starting with tools because good tools can not only speed up everything but also allow teams to tackle really ambitious projects like observability or bringing in new technologies like AI/ML.

Automate everything, especially the annoying things. This probably goes without saying, but automation makes all things better for every team at every stage. The less human intervention required, the faster the process moves. Embrace all those DevOps principles and automate.

Cut down on context switching. It’s safe to say no one actually likes context switching but developers are sort of renowned for how much they dislike having their “flow” interrupted. As we’ve mentioned, there’s a lot of waiting around when you’re a developer, so ensuring meetings and group tasks are efficient and scheduled at optimal times can help offset the annoying nature of downtime.

Focus on concrete fixes. It’s safe to say most engineering teams experience slowdowns around technical debt, and code and pull request reviews. So these are obvious areas to focus on, and a great opportunity to bring teams together to brainstorm what might make the most sense in a particular team or organization. Technical debt might be chipped away at in 15-minute/day increments, while code and PR reviews might need a schedule and even a service-level agreement of sorts around how long they can sit around being ignored. It bears repeating that dealing with some of the more tedious and repetitive parts of the development process can really free a team’s time and energy to get creative, always a worthy goal.

It’s about results, not hours. No discussion of productivity would be complete without a gentle reminder that it’s never about the hours spent but rather what’s being produced. In order to get buy-in for a “productivity push” engineering teams need to be reassured that Big Brother, etc., aren’t taking up residence in the organization. Software development is inherently a very creative exercise and teams need to feel free to be in their creativity, find their zone, and create the code, all without being worried about potentially intrusive and unfair individual measurements. 

Key metrics to boost engineering productivity

There is no dearth of choices when it comes to engineering productivity metrics. Nearly all can be mixed and matched to create custom combinations that would work for any organization. When deciding which to implement, it doesn’t hurt to consider the way Google approaches metrics: they triage them to ensure the metrics are worth measuring. A systemic metrics measurement program needs to be easily repeatable, allow for clear alignment with business values, transparent to the organization, and, of course, worth measuring!

Start with DORA metrics

The DevOps Research Assessment, or DORA, metrics represent a way for teams to measure themselves against other DevOps practitioners. DevOps is a mix of culture, technology, and processes, something that makes it hard for many organizations to get (and keep) right. At about 10 years old now, the DORA metrics are a digestible and clear-cut “North Star” for teams trying to boost engineering productivity. 

DORA metrics have been tweaked over the last few years and today there are five recommended metrics: deployment frequency, lead time for changes, change failure rate, time to restore service, and reliability. For each metric, DORA provides a ranking of high, medium, or low-performing. To understand how the metrics work in the real world, DORA would rate a team that deployed code to end users multiple times a day as a “high” performer, while teams deploying between once a month and once every six months would rate as “low” performers. 

DORA is an ideal metrics choice for organizations new to DevOps, considering a digital transformation, or nearly any team looking for a solid, very do-able metrics program. Even metrics-resistant teams can’t complain too much about tracking just 5 measurements.

Source

Try SPACE as an option for teams and individuals

Born out of the Covid-19 pandemic and the resultant remote work explosion, SPACE metrics are more people than process-focused. Developed by well-known DevOps practitioner Nicole Forsgren and other experts, SPACE stands for satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. 

Think of SPACE as a way to take the temperature of engineering team members as well as get a closer look at some of the interpersonal interactions including communication and collaboration. Each of the broad categories has between three and five metrics in it, making it easy for organizations to pick and choose those that make the most sense. But don’t overdo it: Forsgren herself recommends starting with a handful that can give a broad view and then adding more (but not too many).

One of the strongest reasons to consider implementing some of the SPACE metrics is the opportunity to institutionalize one-on-one meetings with team members. Regular communication is always a powerful tool for any organization.

Bring it together with flow metrics

The engineering team is humming along nicely, deploying code frequently and collaborating well, but are they actually working on projects that will bring value to the business? To answer that question, try flow metrics, which are designed to bring software development and the business side together through shared goals and language. Created by Dr. Mik Kersten in 2018, the flow metrics break software development into four stages (also known as “flow items”) that can then be mapped to the six measurements: velocity, time, efficiency, load, distribution, and predictability. 

The flow metrics work with SPACE, DORA, or any other metric, but, as they’re interdependent, teams must be sure to track all of them in order to get the most correct picture of performance.

Choose even more metrics

From measuring work-in-progress to commit size, type of code produced, and planned versus unplanned, there are a host of other valuable metrics teams can consider as well. No one wants to over-measure, however, so follow Google’s lead and triage all the metrics, and then make the best choices. And, of course, be open to the possibility that what’s being measured this year might be different from what’s measured next year.

Improved engineering productivity won’t just happen

It takes time, patience, communication, and the right mix of strategies, tactics, and metrics to help teams reach their maximum level of productivity. Software development doesn’t always happen in a straight line, and better productivity doesn’t either. But one small consolation: 325 million search results must reflect that nearly every organization is struggling with this issue, so start the conversations because clearly, they’re happening everywhere.