Often FAANG employees describe their days as mostly consisting of working 3-4 hours, checking off their work tickets and punching out 40 full-time hours...
Upon doing research for this post, we were thinking of the ways friends at certain FAANG companies talked 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 we stumbled upon a Hacker News forum post from January of 2020. A pleading developer asked fellow peers: “I've been slacking off at Google for 6 years. How can I stop this?” With nearly 1500 upvotes and just under 1000 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 we currently measure developer productivity, and are we really seeing value from these metrics?
According to Axolo, assessing developer productivity starts with an organization designing objectives or specific acceptable baselines for their software developers.
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? The problem arises when this rudimentary way of measuring time and output is met with “negative work.” This is work that is done with such little consideration that it must be re-done later, resulting in dead hours of developer time and much more cost to the business.
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 into 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.
While the case for individual productivity metrics has been hotly discussed, at the end of the day, productivity and developer efficiency is both an individual and team sport.
Development teams are much like a basketball team’s rotating 10 roster. 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 roleplayers! They come in, put up generalist minutes and come back out. The team functions together, as a whole, with individual player attributions summarizing to an inevitable outcome.
That being said, the individual characteristics make up the general whole. Sharp shooters need to produce a certain field goal percentage for a given team’s needs, A defender needs a track record of tight defense and a low points 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 upon their previous work assumptions.
Arguably two of the most effective ways to gain an insightful metric for developers is through measuring velocity and agility. Velocity calculates the net total tasks completed by a team over a set period of time, that rely heavily on developer’s own predetermined set boundaries for 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.
Agility measures any given response to change. It’s iterative, generally software heavy, and aims to deliver working software to any particular customer quickly. A developer in agile development, as described by geeksforgeeks, “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.” Collaboration and incorporating the individual’s unique skill to the team is what drives productive development.
The Agile Manifesto 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 gauge developer productivity is to make sure organizations incentivise developers to be the best they can. To instill working environments that challenge and bring individualism, all the while being areas for growth and areas that allow for value to be added.
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.
