How to Measure Productivity as a Developer

Upon doing research for this post, I was thinking of the ways friends at certain FAANG companies talk about their work. Often nonchalantly, they describe their days as mostly consisting of working 3-4 hours, checking off their work tickets and punching out 40 full-time hours. While the pandemic has taken away their access to nap pods and recreational basketball on campus, they are left unsure of what to do with the rest of their allotted work hours. It all became far too realistic once I stumbled upon a Hacker News forum post from January of 2020. A pleading developer asked fellow peers:  With nearly 1,500 upvotes and just under 1,000 replies, the developer dilemma that has been hiding in plain sight from engineering managers for decades has now turned to disenfranchisement for many. How do you measure developer productivity, and are we really seeing value from these metrics?

Input and output measurements: the good and the bad

Input measurements are the general basis of how not just developer efficiency is measured, but really any organization. Input comes in many forms; most commonly, you see input as a measurement of hours worked. 40-hours a week of work means good, efficient work was produced, right?

Output measurements in the developer community are a disaster. Gauging work output based on lines of code or amount of pull requests is very similar to measuring a restaurant’s success by the amount of leftover food they have at the end of a night. It may be beneficial to some extent in determining the overall success of the restaurant, sure. However, if there was too much food ordered or one item was more popular than another on a given day, then this measurement provides little utility.

Another problem is that most of these metrics can easily be manipulated by the developer. A task set for 1 week could potentially take a programmer mere hours to complete, resulting in missed opportunities for the business to grow at a much faster rate. Measuring bugs, tickets completed and metrics similar to this also resolve tricky waters. Developers can purposefully write more lines of code, without ever being checked for code quality and awarded at their job. The same goes for much of anything else ticketed to their weekly tasks.

Measuring developer productivity: the right way

While the case for individual productivity metrics has been hotly discussed, at the end of the day, productivity and developer efficiency are both individual and team sports.

Development teams are much like a basketball team’s rotating 10 rosters. Some players are shooters, specifically, put in to generate points and seek a lead. Others are defensive specialists, who come in during tight moments and shut down a fiery assist maker or take the right charge on a paint-driving play. Some are just overall role players! They come in, put up generalist minutes and come back out. The team functions together with individual player attributions summarizing an inevitable outcome.

That being said, individual characteristics make up the general whole. Sharpshooters need to produce a certain field goal percentage for a given team’s needs, a defender needs a track record of tight defence and a low point allowed percentage, and this goes on and on.

This is the same way development teams should work. You may have force-multipliers, team members who come in and generate a lot of buzz for the workload, while others are more janitorial - they go back through, test and reconfigure buggy code and make sure all of it runs the way it should be. These types of team players are difficult to gauge in terms of productivity but are critical to the health of the organization. Their individual output, however, is an essential facet of how this team succeeds and will continue to succeed based on their previous work assumptions.

Measuring development velocity and agility

Arguably two of the most effective ways to measure developer productivity are through measuring velocity and agility. Development velocity calculates the net total tasks completed by a team over a set period that rely heavily on the developer’s own predetermined set boundaries for the time allotted. Velocity is a planning measure, and a planning measure solely. Velocity works best when it’s paired with foundational questions like, “how much work can my team get done this month?” Velocity provides contextual data to support this response.

Development agility measures any given response to change. It’s iterative, generally software heavy, and aims to deliver working software to any particular customer quickly. Collaboration and incorporating the individual’s unique skill into the team is what drives developer productivity.

A developer in agile development, as described by , “acknowledges that software is developed by people operating in groups which the talents of those folks, their ability to collaborate is at the core for the success of the project.”

The third agile principle

The  is a sort of sacred document for developers. In this, the founders reiterate the mission, to “[b]uild projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The only genuine way to measure developer productivity is to make sure organizations incentivize developers to be the best they can be.

Developers are most productive when they can run and operate on their own schedules. By leveraging which input and output benefits are conducive for your team, assessing the need for individual success to make the team shine, as well as getting a firm understanding of velocity and agility, your development team will be ready to improve code quality and work more efficiently than ever before.