Want to fix developer productivity? Then stop focusing on it.

Those in the software development space are probably aware of McKinsey’s article from August of last year, “Yes, you can measure software developer productivity.” 

Starting with software legend Kent Beck, signer of the Agile Manifesto and founder of the extreme programming methodology, outrage quickly took the developer community by storm. 

The article boasted a condescending tone, lacked structure and critical information, and oversimplified the roles developers play in organizations.

Fernando Villalba, Developer Advocate at OpsLevel, joins the podcast to discuss where the article went wrong, functional metrics leaders can rely upon, and more.

The premise of the McKinsey article

The article claims that McKinsey is capable of measuring developer productivity with existing data and surveys by using a combination of DORA, SPACE, and opportunity-based metrics. 

McKinsey did not offer a detailed explanation of the specific metrics used but boasted a proven track record of measuring productivity — an act Fernando sees as disingenuous. 

The issues within the article

Fernando breaks down the problems within the article into four main categories:

Issue #1: The boastful statement

First and foremost, the article’s title could be considered misleading. By saying “Yes, you can measure software developer productivity”, it could lead executives to understand that software development teams can be guided to productivity through the same metrics they are using across the board with other teams and organizations — which Fernando says just does not work. 

Issue #2: Clumsy point delivery

Fernando believes the article does serve to make some compelling points — but it does so in such a clumsy nature that they may be glazed over or misinterpreted. 

“For example, there is one point where they say that infrastructure tasks are low-value for developers. I think what they're trying to say is that developers want to focus on coding. They don't want to be cognitively overloaded by doing infrastructure tasks,” Fernando says.

By stating that infrastructure tasks are low-value, this statement could be interpreted to mean that they contain no value, which, again, is not the case. 

Issue #3: Claims that are simply untrue

“The third point that I’ve seen people criticize them for is that some of their claims are simply untrue,” Fernando says. 

For example, one paragraph discusses a company that found their most talented developers were spending excessive amounts of time on non-coding activities, such as design sessions and managing interdependencies across teams. 

The company changed its operating model and clarified roles and responsibilities to enable their highest value developers to do what it is they consider they are best at doing — coding. 

“The reason why that is kind of wrong is because, when you have senior developers in a team, sometimes they are not going to be coding all of the time. They are going to have planning sessions. They are going to be talking to less senior developers. They are going to be organizing and mentoring,” Fernando says. 

Those non-coding activities bring immense value to the table (and allow coding to be performed with ease and brevity when it is done). 

Issue #4: Metrics that are not useful or too vague to be understood

Fernando states the metrics discussed in the article are heavily criticized due to the fact that they are not useful or too vague to be properly understood. 

“These metrics could be potentially harmful if they are implemented outright without thinking further into them,” Fernando says. 

This issue is further amplified, as SPACE, DORA, and opportunity-based metrics can be highly effective and functional. By poorly presenting them, it is noted that some industry leaders have begun inadvertently criticizing quality metric methodology, which is not good for the industry as a whole. 

Top-down productivity pushes are not the solution

“If you’re spending a lot of money hiring someone, you want to know that you’re getting value out of it. Productivity measurement is very seductive, but you need to take a step back and understand what that means and how harmful that can be,” Fernando says. 

What leaders consider to be productive for the organization as a whole may not match the definition of productivity for a specific team (and it may even be different for an individual team from quarter to quarter). 

If leaders enact top-down productivity metrics and push down on teams, developers are eventually going to find a way to play that system — even with quality metric measurement systems, such as DORA. 

“If you started incentivizing your developers by DORA metrics, I think developers would eventually break down everything as much as possible and end up doing 100 deployments each day,” Fernando says. 

While there may not be a tried-and-true, end-all-be-all solution to productivity management, Fernando believes that productivity and goal setting should not come in a top-down approach, but instead be left to the individual developer team leaders.

Potential solutions to productivity problems

After speaking with a peer who worked in developer productivity for Google for years, Fernando was struck with an interesting thought.

“He told me that the easiest thing to measure when it comes to productivity is what does not make you productive, not what makes you productive,” Fernando says. 

In Fernando’s opinion, the best thing a company can do is to measure all of the things that create friction, create productivity roadblocks, and reduce the speed at which developers can reach their top speed and potential.

The key? Embracing and bolstering flow state.

Fernando tells us that the flow state brings an abundance of advantages, and by stopping any processes that hinder the flow state, organizations can enjoy happy (and productive) developer teams.

One of the largest hindrances to the flow state, in Fernando’s opinion, is failing or bothersome communication channels. A calendar full of meetings leaves no room for productive work, but an open calendar and rapidly effective communication channels can offer productivity in abundance. 

Additionally, close analyses of tooling are crucial. Even when tools offer all of the latest functions and options, they could still be over-complicated to use in the day-to-day. Tools that are not user-friendly create massive amounts of underlying friction. 

“You find yourself in this situation where you have to do 30 steps to complete a task, whereas another tool that may be less feature-rich allows you to do it in one step. I'd say that the one-step tool is probably better for you. It's going to save you money and a lot of engineering hours in the long run,” Fernando says.

‍

Interested in learning more? Listen to our full discussion with Fernando, where we take a deep dive into productivity management, including what to do and what to avoid, productivity-boosting habits that successful teams adopt, how to form-fit this knowledge into your specific organization, and more. Listen on Apple Podcasts, Spotify, or your favorite podcast player.