The Modern Leader
Yes, I am talking about the McKinsey report titled “Yes, you can measure software developer productivity”. Gergely Orosz and Kent Beck did a great job responding to this report with a two-part series (Part 1) (Part 2) so I’m not going to regurgitate everything they just said, but I will summarize two points that stuck out most to me and why this matters for you as an engineering leader.
1. Developers are more than just code.
I’m going to start with the end of the McKinsey report here, because this idea actually made me laugh out loud:
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.
First off… what?!
Second… those “noncoding activities” are extremely valuable for engineers to build cross-functional muscles and relationships with those outside of engineering. Morale sinks when engineers are forced to work in a silo and focus on code and code only. They also miss a lot of context when they aren’t aware of what other teams are working on or how their work may impact others or the business.
I do think it’s important to minimize the number of meetings engineers have per day so they have the time they need to focus on the work at hand, but the idea that this time spent doing noncoding activities is time not well-spent is nonsense.
2. Measure at the team level, not at the individual level.
I can’t speak for every team out there, but I can speak for my team in that while I do my best to avoid context switching from one project to the next, engineers will occasionally have to jump into another project to help get it over the finish line if it has a tight deadline we’re working against. Engineers are working on projects with different levels of complexity – some, for example, may be updates to an existing feature, or some may be net new – and as a result, one engineer may appear to be “doing less work” than another. This is why lines of code, story points, etc. will never work as an accurate attribute. If you give someone the rules, there will always be people who will find a way to game the system.
This is why it’s significantly more important to measure success at the team level. Are projects getting shipped on time and according to schedule? What sorts of regressions are you facing, and how quickly are they remedied? Are these repeated regressions? How much time is being spent on net new work vs. infrastructure upgrades vs. bug fixes?
Any engineering manager can tell you who on your team may be pulling less weight. It’s obvious when you have boots on the ground.
And I think that’s the crux of the issue here. The McKinsey report wasn’t written for engineering leaders. It was written for C suite executives outside of engineering to try to fit a round peg in a square hole. Metrics are not one-size-fits-all – you cannot apply the same rules to Sales or Recruiting as you do to Engineering. Doing so sets a dangerous precedent for your team.