The developer’s productivity can’t be measured in McKinsey’s way. An Analysis.
I have been managing and leading different teams for the last two and a half years and analyzing the productivity and performance of teammates with different backgrounds.
McKinsey published a report and laid down some productivity indicators to build a framework for tech companies.
As soon as I read this report, the first question I asked myself was, Do I measure the productivity of my team members? If so, do I use one generalized approach for all? The answer is no.
Is it important to measure the productivity of software developers?
Yes, every company needs the best talent and wants to replace the least productive engineers with the most productive ones. However, the productivity parameters of one developer completely differ from those of the other.
It is impossible to apply one formula that fits all and expect accurate results. It will be disruptive.
Let’s say there are three developers, A, B, C, and D, working in a team and putting in 100% effort.
Developer A is working on new features and delivering them regularly.
Developer B is reducing tech debt by optimizing code for scalability and paving the way for new feature development at a rapid pace.
Developer C is blocked most of the time due to third-party dependencies and couldn’t get it delivered.
Developer D is building with a completely new stack, and the development pace is slow, but things are getting done as per contractual expectations.
Who will get more recognition and be considered more productive in typical C-level meetings? Does it mean, by any standard, that one is less productive than the others? A person solving bugs or reducing tech debt might seem less productive than one delivering features in a typical tech company.
A summary of the McKinsey report
McKinsey thinks they have a solution to measure the developer’s productivity.
This article explores the significance of measuring software developer productivity and proposes a novel method for doing so. It emphasizes that, in contrast to other corporate operations, software development has generally been undermeasured. However, because most businesses now rely substantially on software, it is critical to analyze and optimize developer performance.
Given the complexity and collaboration required in software development, the essay acknowledges the difficulties in assessing developer productivity.
The article’s innovative technique involves assessing production at three levels: system, team, and person, using DORA and SPACE metrics and Opportunity-focused metrics.
It introduces new measures, including deployment frequency, change lead time, and contribution analysis, to evaluate performance and find areas for improvement.
The essay emphasizes the need to avoid measurements that are unnecessarily simplistic, such as lines of code, and encourages organizations to move beyond antiquated mindsets that imply software engineering cannot be measured.
The article concludes with suggestions for getting started with measuring developer productivity, such as learning about software development, assessing existing systems, developing a plan, and understanding that measuring productivity is contextual and aimed at improving the entire development environment. The goal is to boost developer productivity and overall corporate performance by increasing openness and insight.
An analysis from a developer’s and engineering lead’s perspective
The report is more focused on building a framework for C-level managers than considering the software development lifecycle and the developer’s journey from building to delivery.
1. A non-engineering person gauging developers' productivity and influencing decisions
This is where the problem starts.
It’s just a button or an API connected to the database.
To a non-techie, it might look like just a feature, but the concepts of tech debt, architectural decisions, and feature implementation are naive.
The question is, when the CTO is spearheading the technical side, shouldn’t he be calling the shots and firing and hiring developers based on their performance?
Not to mention non-engineering people, I have witnessed leads and managers struggling with developers working on the other tech stack. I have witnessed backend leads who don’t understand how a page loads on browsers and, out of ignorance, rank frontend developers low.
Learn the basics. All C-suite leaders who are not engineers or who have been in management for a long time will need a primer on the software development process and how it is evolving.
It’s a welcoming statement, but not all tech companies are building the same product. R&D, architectural decisions, and overhead vary. The developer and software lifecycles in a fintech startup are different from those in a typical SAAS. So the question is: are C-level managers willing to learn from the context of their product?
2. Entire focus on coding
From both a productivity and personal-experience standpoint, maximizing the amount of time developers spend in the inner loop is desirable: building products directly generates value and is what most developers are excited to do.
The document thinks that the more code a developer writes, the more productive he or she is. The irony is that it indirectly insists on building a coder mindset in organizations.
There is no mention of how much different aspects of software engineering, such as building a system design, taking architectural decisions, and discussing scalability, influence the course of the product.
3. The outer loop is completely generalized for all developers
The absence of platform engineering and DevOps standardization will impede development progress and make developers focus less on their jobs.
It makes sense that the developers should be unblocked for CI/CD pipelines and deployments, but excluding meetings, security, and compliance from a developer’s activity is rather a generalization.
It’s true for most tech companies, where unnecessary prolonged meetings and standups happen and should be reduced to a point where developers just attend meetings where they are actually required.
A developer working in Fintech and Banking is considerate of security and compliance. If development evolves the product, then obviously these factors come into play. Who will then implement those features?
4. No mention of automated and manual QAs or DevOps engineers
Productivity can vary from developer to developer, depending on the job description.
Developers are not the only ones building the product and need to be productive. The QA team and DevOps play equal roles. Here, no indicator is defined to measure their productivity.
The manual QAs and the ones doing automation need different criteria, as do the DevOpsers.
5. Developer Velocity Index
DV, in fact, adds to the efficiency of a developer’s and the overall software development cycle. The developer’s productivity will fall to zero if they get stuck in CI/CD pipelines, manual unit testing, tedious code promotion strategies, etc.
6. Overlooking non-coding contributions of developers
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.
The company went wrong here, and this model is not a viable one.
It can be assumed that the most talented developers should know the ins and outs of the product and the internal dependencies overlapping across the teams. Who is supposed to take the lead, create, or assess designs and system designs? Are those talented developers or others hired for these specific roles? Were those developers completely turned into coding bots?
Let’s say there is a major feature implementation that requires ongoing communication between the teams. It’s a common practice that managers, with the help of developers, handle this and point out the shortcomings and successes of the integrations and implementations.
Creating a separate role for this creates only friction rather than good code and products.
7. The framework doesn’t address contextuality
Remember that measuring productivity is contextual. The point is to look at an entire system and understand how it can work better by improving the development environment at the system, team, or individual level.
It’s a welcome point in the report, and it’s true.
At my job, my manager gauges my productivity and performance in a different context than I do for my team members on a different tech stack.
At the team level, my developers get blocked for a couple of days due to an external issue, although a feature has been completed. When they get unblocked, they might have to change a feature implementation due to a third-party requirement, and the delivery gets delayed. In this context, the team is not a non-productive one. But if it is clearly monitored, the team is indeed productive, as they have delivered the feature in the time required to do all the work.
To some C-level managers, the developer might look non-productive as the feature is getting delayed, but the reason is not the productivity issue.
Similarly, if the team or developer underestimates the ETA and there are no blockers, they fail to defend against delays, and productivity and performance issues will come into the spotlight.
It’s easier to gauge performance with a given set of points, such as clean code, unit testing, number of bugs, tech debt accrued, etc.
8. The impact of the developer on the team is greater than the coding
This is one of the most important aspects of an outstanding developer, but there seems to be no mention of it. If you are a senior developer on the team, you will be expected to help out the juniors, review code, and suggest solutions. The amount of time spent coding will not be a big factor in your assessment.
The greater your impact, the more productive and exceptional you will be considered.
Summary
It’s a very welcoming report, but it comes with some basic flaws. Every manager wants to know the productivity level of his or her team and how to improve it. But it can’t be generalized and applied across organizations. Every developer or team has different tasks and circumstances. Similarly, each developer comes with different strengths and weaknesses, which have an impact on the product being built. Some are good at unblocking teammates and building solutions, while others write exceptional and optimized code. Those who implement this framework will produce more coders than software engineers who build solutions.
Thanks for reading.
Let’s connect on LinkedIn.
