Developer Productivity: How to Measure It

What is Developer Productivity?

Developer productivity is simply measuring how efficiently a developer can handle tasks within a specific timeframe. Measuring and enhancing developer productivity is intended to accelerate the release of features, apps, bug fixes, and indirect revenue growth.

However, while tracking and measuring developer productivity is great, organizations usually do this by measuring the wrong metrics or basing productivity on just inputs and outputs. The problem here is that this doesn't take into account the quality or innovative endeavor of the whole software development process. 

Poor metrics: Metrics you shouldn't measure

Jordan knows that while there are a lot of metrics out there, picking the right metrics to track his developer productivity matters. These metrics need to be valuable, or he will do more harm than good. A few of these metrics are hours worked, the number of commits in version control, lines of code, bugs fixed, and computer activity.

Although these measures may seem like the obvious and logical choice, they are harmful to your developer's drive. Metrics like these don't consider the quality of code or innovative endeavors, nor do they factor in business value, but rather measure productivity based on the number of mouse clicks and version control activity. The worst part is that your developer can easily game these metrics. 

Let's look at a few of these metrics and why you shouldn't use them to measure developer productivity.

Line of Code (LOC) and Git-Based Metrics

Using LOC or git-based metrics as a productivity metric will encourage your developer engineers to write verbose code and include more comments. Comments are great for maintainability, but too many comments can clutter your codebase and make it difficult to debug when adding new features. Additionally, when viewed at an individual level, these metrics lack context.

This goes for similar metrics like the number of commits, pull requests, static code analysis scores, and issues closed. While these might look impressive in your version control history, they offer less value to the project. They also put unnecessary pressure on your developers and will have them making small but frequent commits and adding more complexity to the codebase in production. The bottom line is that this metric prioritizes quantity over quality, which would create more bugs and lead to poor-quality source code.

Hours worked

Despite popular belief, staying on your laptop all day, working long hours, or closing late doesn't always mean productivity. Long work hours are also unhealthy as it has been established that they can lead to burnout and increase errors and oversight. Don't get me wrong, investing time and effort in a project is great, but only if results can be seen.  

To be more productive, you need to get work done efficiently within the shortest time possible. So, rather than measuring productivity by prioritizing hours worked, focus more on quality and efficiency. This way, your developer will focus on delivering higher quality work in less time.

Measuring Developer Productivity the Right Way

We have talked about what is futile and ineffective. So let's answer the questions engineering leads—like Jordan—want to know: how do you measure developer productivity, and what is the right way? 

Let's take a look at some strategies.

Using frameworks

There are three ways one can go about this:

• President Dwight Eisenhower's Box
• The SPACE framework
• The OKR framework

President Dwight Eisenhower's Box

Dwight Eisenhower was said to be one of the most productive men you have ever met. He achieved this using the Eisenhower Box, a brilliant time and task management technique to boost and ensure productivity daily and long-term.

The Eisenhower Box uses a decision matrix to organize tasks and take action into four possibilities:

• Urgent and important (time-sensitive, so act immediately)
• Important but not urgent (schedule for later)
• Urgent but not important (delegate to others)
• Neither urgent nor important (not urgent tasks)

While this matrix seems primarily for prioritization, it offers much more insight into where your team spends most of their time.

The SPACE framework

Developers have this "flow" state; they feel hyper-productive, motivated, and have fun coding out the task. The SPACE framework aims to get developers into this flow state by focusing on five pillars:

1. Satisfaction

Here, productivity is measured based on employee satisfaction, efficacy, and burnout. The aim of this pillar is to increase productivity by improving the developer experience and promoting a healthy team culture. This is primarily because there is a strong correlation between the working environment and employees' productivity.

2. Performance

Productivity will be measured based on the outcome of their work. This can be tricky because a developer's role isn't customer-facing. However, you can use developer-specific metrics such as reliability, adoption, app rating, and the number of issues or bugs found to get insights into performance.

3. Activity

Though git-based metrics like LOC and commits can be misleading and cause more harm than good, they can be useful if measured accurately. How? by laying more emphasis on the outcome rather than the count or output. For example, look at the context rather than capturing the number of commits. If this is done, you might find that perhaps more peer review sessions or high-value commits were made that impacted the software development at scale.

4. Communication and Collaboration

The whole software development process is more of an iterative process, which requires a lot of feedback from the team. Thus, it is important to prioritize your developer team's communication and collaboration experience. I'll elaborate on how in the subsequent session.

5. Efficiency

The efficiency pillar focuses on minimizing interruptions and latency by simply improving coordination between and within teams. This can be achieved by adding accountability and metrics—deployment frequency, lead time for changes, change failure rate, and time to restore service—from DevOps Research and Assessment (DORA). 

The OKR framework

The OKR framework is a framework that promotes objective and goal setting. Tasks are broken down into clear and qualitative objectives. This way, your developers can think big while keeping it realistic and actionable. This is a smart approach, especially since each objective can be connected to an outcome or impact.

Measuring teams, not individuals!

No developer works in isolation; they work in teams. 

While individual metrics are great, team metrics are better. For starters, they give you a full picture of the development process. Teamwork and collaboration foster robust progress. Individually, a few team members could look like they're slacking, but looking at it closely, it tends to make much more sense. For example, a few are dealing with technical debt while others work on shipping the new features. 

When looking at your developer productivity, it is great to look at the overall team metrics, like the output of this sprint compared to the previous or the number of features delivered per iteration. Additionally, if the team has been experiencing low productivity for a while, something is wrong and needs to be considered.

The keys to developer productivity: flow, iteration, and feedback

The software development process is a lot more human than the green commit square you see on the contribution graph of your favorite version control platform. Therefore, it's critical never to undervalue the impact that a supportive workplace environment has on the efficiency of your developers. An average-performing developer team would be more productive than a team of top-performing developers operating in an unfavorable environment.

The lifeblood of any excellent software engineering team is flow, iteration, and feedback, which are fueled when this team is supported by accountability, collaboration, and a contribution culture. Hence, it is important to design a work environment with little distraction that encourages collaboration. Less distraction because it gets them into a flow state. On the other hand, collaboration brings about feedback, which is the key enabler for continuously delivering your releases. Team bonding, regular meetings, improving the onboarding experience, investing in pair programming, and having quality code review sessions are a few ways to achieve this.

How can Bird help with developer productivity?

Tools that automate and make communication between your engineers and the business team simple are crucial for streamlining the feedback loop and collaboration process. Bird Eats Bug— Bird for short— is a tool that enables developers to screenshot, record, and capture technical data and bug reports. The business team can also use its mic and camera features to describe issues quickly and give feedback easily. 

So how does Bird help developer productivity? First, it makes everyone's work, including your developer, run smoothly. Developers can have quick code review sessions, and everyone gets in the loop because of Bird's integration capabilities with almost every channel. This way, one can release features and iterate feedback faster in the software development workflow.

You should check out this article to learn how to use Bird to run a remote QA team and optimize business impact.

Wrapping up

Neglecting developer productivity will impact business, so it is no wonder why engineering leads frequently ask questions about how to measure and improve developer productivity. Unfortunately, there isn't a single metric to measure developer productivity.

Everything from your workflow, team, communication and work culture can affect your team's productivity. However, despite how multifaceted the question can be, there are established frameworks, strategies, and tools that can help every Jordan out there.

Incorporate these strategies and watch how productive your team gets and how competitive you are in the market. Find this article useful? Feel free to share it.