The Developer Productivity Trap

A short ramble inspired by John Cutler and his post on Developer Counter-Performance

Often CTOs and heads of Product, fall into the trap of measuring what they believe to be Developer productivity. KPIs such as lines of code, number of commits and user stories closed become the focal point for department performance. Dashboard are created and targets communicated in department all-hands meetings. Managers are told to implement changes within their teams to ensure these metrics turn green. The CTO dreams about showing a trajectory change with lots of green in their next quarterly review.

Why do these metrics get tracked?

Tracking Developer productivity is often a reaction to pressure from other departments who feel the R&D and Product org is not shipping enough features and bug fixes fast enough. "We're going to lose big customer X because they've been waiting for a bug fix for over a year," or "big prospect Y is going to competitor because we didn't have this feature on our roadmap," start to be overheard in revenue meetings.

If you are overhearing these comments in your organization, please know, this is not unique to you. Please also know, the R&D and Product organization likely does have a velocity problem, it happens and it's solvable; however, measuring "developer productivity" will not solve the problem.

Velocity is the distance travelled to a particular destination.

Speed does not care about direction.

Therefor increasing speed can, and often does, decrease velocity.

The lever that drives velocity.

Speed is definitely a factor. However, the bigger lever is often clarity on where you are going.

A telling question to uncover if clarity exists or not is, how does the organization decide what is worked on and what isn't?

There are few important parts to this question.

1. The focus on, "organization." Notice, I did not use the word department. How departments decide what to work on is often easier to answer than how the organization decides. Unfortunately this is a big problem. If it's easier to articulate how a department prioritizes then it means departments are likely prioritizing different things.
2. The explicitness of, "what is not worked on." If we are not clear about things that won't be worked on across the organization, then that person with influence in X department will continue to think it's still on the table. I know, I know, it's not the roadmap or the PPT slide. Trust me, they still think it's a possibility and they probably will still move pieces around to find ways to make it more of a possibility.

Let's bring it back to Developer Productivity.

John Cutler has a wonderful post on tracking Developer Counter-Productivity. He starts with the reflection that it's not the amount of work that infroms productivity, but instead it's the type of work. Working on high-leverage things increases productivity. The challenge is that high-leverage things are often hard to define. The good news is that low-leverage things are usually clear. John does an excellent job outlining what these are in his post. https://cutlefish.substack.com/p/tbm-240-the-ultimate-guide-to-developer

Some examples include, unplanned-work, context switching, admin and compliance work, ineffective planning and poorly managed documentation.

If we can ensure Developers are spending less time on low-leverage work, it increases the probability of them spending time on high-leverage work.

If you are in a position where you are either tracking Developer productivity or considering it, consider tracking Developer counter-productivity instead. See if the dots connect towards developers working on low-leverage work items and departments being misaligned on what is most important to the organization in terms of where it wants to go.

There is no doubt that this a hard problem to solve; especially at the individual level. It requires trust building and a common understanding of the problem across all departments. At Humxn.Studio we've helped facilitate the installation of Org-wide prioritization frameworks. The clarity on destination across the business empowers the humxns in the organization to do their best work.

Reach out if there's anything on this topic you'd like to chat about. We're always happy to chat and share what we know.