Developer Productivity: Understanding the Developer Role First
CTO Labs Principal Technologist Roger Almeida delves into the developer productivity debate and asks how non-technical leaders can best become collaborators in the intricacies of software engineering.
Developer circles have been buzzing after the recent McKinsey article "Yes, you can measure developer productivity". Responses were fast, and not entirely favourable, with some examples here and here and here.
In this article, I will share my impressions, both the positives and the risks for any business considering their approach.
The Goods
Firstly, to the positives.
>> Measurement matters
Let me say that measuring developer performance matters: for the individual, for peers, for the business.
Not having ANY way to measure performance is not an option for productive and competitive teams - and this is true for software development as it is other functions. There are risks in focusing too much at the individual performance level, but for now, let’s just agree that measurement matters.
>> It has the right audience
The McKinsey framework is not directed at CTOs, Head of Engineering or any other deeply technical audience. The article targets non technical C-level leaders and this is a good thing.
Engeering is unique and complex and non-technical leaders need information that helps to better understand the professional disciplines they are managing, because software developers being managed by non-technical leaders is a common scenario.
>> It makes sense for some scenarios
In some limited scenarios, the approach outlined in the article could make good sense. For instance when Technology is not a competitive advantage to the business, there would be less need to retain developer capacity in house and opt instead to outsource. In this case the “developer” could become more vendor-manager, and the McKinsey developer measurement methodology may provide a common language for professional services businesses engaged to provide developers as contractors.
But here’s my word of caution. While the McKinsey approach rightly states that today every business is becoming a software business, there is no single model for developer measurement that fits every business.
The Bad
Although full of good intentions, the McKinsey framework doesn’t align with best-case developer productivity. And here’s why:
>> Value added vs Non-Value added tasks
The framework seems to suggest that the only (or at least the most important) value-adding task for a developer is to “code”.
For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.
A developer would never classify Design Session and Managing Dependencies as non-valuable activity. Quite the opposite: these are high value activities that will reduce the effort involved in writing software.
The agile manifesto - the bible when it comes to best coding practice - is very clear here:
Simplicity--the art of maximising the amount of work not done--is essential.
Good product and technical design sessions can dramatically reduce the effort of creating software.
I’m not about to suggest that writing code is not the main activity for a developer, because it is.
It also is highly specialised. It’s hard to imagine a good product coming out of code written by a marketing specialist without significant technical training. So yes, prioritising and protecting the space for developers to do good work is vital.
But assuming that time spent by a developer not writing code is wasted time, is a dangerously shortsighted path.
>> A Developer is not a translator
Here lies another red flag. If the developer role is reduced to eg "translate these requirements to javascript/typescript/java/golang/etc..." then the overhead required to keep that team functional will expand well beyond necessity.
Experience has shown that if the communication between developers is not well managed it is common for parts of the code to be neglected, while other parts might be re-written several times times, leading to wasted time, duplication of effort and probably divergence from the collective goal.
Lets stop using the term Developer
Some time ago I personally stopped using the term "developer" in favour of the term "software engineer" and here is my definition of the term:
Software Engineer: a person who engineers solutions using software.
Take note - the output of a Software Engineer is solutions to problems.
Because Software Engineers can create software, they normally create software to solve problems.
Good Software Engineers though, pursue ways to minimise the amount of Software they have to create.
So if you are not using your developers to solve problems, then potentially you are wasting a good percentage of some of your most valuable employees (and quite possibly some of your most expensive ones too).
>> Developers can and should contribute to software decisions
As Marty Cagan, who started his career as a Software Engineer before moving to product states, if your business is not involving your Software Engineers in your product discovery activities, then you are not taking advantage of people who know a lot about your product and software in general.
Although this is not their primary task or skill, product discovery exercises are one of the areas where Software Engineers can and should always be contributing to because of the value this delivers to the business.
If you only reward your developer for the amount of software they are producing, you cannot blame them for not focusing on the outcome that their effort is generating.
The only way for software to return value is when it is available in a production environment AND its user’s perceive it to be of value.
>> But for McKinsey this is not the goal
Below is the mental model the McKinsey framework uses to measure a developer contribution:
Notice how it limits a developer to a role that codes and deploys code.
It is simplistic, and limiting, including:
Limiting the ROI on work of a developer
Limiting the growth-opportunity for the developer
The Ugly
The McKinsey Framework falls short on a fundamental truth.
>> Enterprise Software Development is a Team Effort
Perhaps the concept is not as integral for business leaders outside the software industry. But the most important Tech industry development in the last two decades is that of TEAMS (not individuals) as the key to productivity and performance.
Technical readers will be familiar with, for instance:
Today we know deeply that design and architecture of good technical solutions depend on the communication structure and shape of teams: This is Conway’s Law.
We also know what happens when engineers start to drift away from the team in their contributions.
A core element of CTO Labs M&A tech engagements involves analysis for investors of health of code in in a business (by way of our Code Forensics offering), where we quantify tech risks in eg developers not sharing their knowledge with the rest of the team. Our analysis shows clearly for investors and deal teams where, for instance, a developer leaving a project may lead to key knowledge loss.
Why? Because this puts capability, performance and security at risk, and it can continue to quietly corrode asset performance unless you know what to look for.
Another common case is lack of consistency between teams and the work of their members, which is reliant on regular and frequent interaction.
The picture below illustrates a real scenario where team members were interacting more with people from other teams than with their own team peers. This can be seen in the intensity (or lack) of connective lines across and within clusters.
To ignore the team dimension of developer performance is to act with peril. It incentivises patterns that put code health, productivity and performance at risk.
Conclusion
In this article, I've delved into just how complex an undertaking it is to measure developer productivity, beyond the framework set out by McKinsey.
In particular, I've made the case that coding isn't the sole value-adding task for developers; activities like design sessions and dependency management matter a great deal and have a high impact on the outcome generated by Software Engineers.
It's crucial to see software development as a team game with a focus on the value being delivered, not just lines being written. Also that the mindset of non-technical leaders becomes one of seeing Software Engineers as problem solvers well beyond executing on tasks.
Perhaps the real question is how best can we equip our non-technical leaders to be collaborators in the intricacies of our craft?
