My Response To The NONSENSE McKinsey Article On Developer Productivity

Consulting group McKinsey & Company have recently published an article called “Yes you can measure software developer productivity” which has been widely criticised. Grady Booth said “It’s rubbish”, Kent Back said “The report is so absurd and naive that it makes no sense to critique it in detail” and Daniel Terhorst-North said, “Don’t try to measure the individual contribution of a unit in a complex adaptive system, because the premise of the question is flawed”.

In this episode software engineer and author, Dave Farley joins in with the critique, and while agreeing with Kent Beck on most things, does look at the report in some detail to critique it. He finds that the McKinsey developer productivity article is as useless and ill-informed as the reactions of many other industry experts would suggest.

-

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

🖇 LINKS:

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

CHANNEL SPONSORS:

#softwareengineer #software #developer #productivity #mckinsey

[dafyddrees]

There are too many non-engineers managing software engineering. This would never happen in civil engineering or medicine. Fundamentally that's our problem.

[bryanfinster]

"This article is rubbish, completely misses the point, and is probably dangerous." Yeah, that's a good summary.

[maciej]

I recommend giving "When McKinsey Comes to Town" a read for pretty much all the reasons to disregard anything they produce, not because they are bad at what they do, but because they are very good at what they do. It just so happens what they do is drive profits and cut costs for companies/governments that hire them, and if that comes at the cost of employees, customers, the environment, or with a literal genocide in the background - oh well, it's just business.

[tlooy]

The McKinsey report shows a lack of systems thinking. It's best captured in this quote from Russell Ackoff: “A system is never the sum of its parts. It's the product of their interaction.”

[gilgamecha]

My background is in software but I once ran a sales team. The performance metrics for sales were totally gamed by the sales team and had almost no alignment to the interests of the company, short term or long term. I tried applying what I knew from software engineering to give the sales team slightly better aligned metrics (based on profit not revenue). They staged a mutiny and claimed to be too stupid to understand profit and loss. Of course nothing could be further from the truth - they clearly understood that profitability targets would be harder for them to game than revenue targets that were totally detached from cost, risk or feasibility.

[dovahnok]

I love how they acknowledge that "failing to move past old mindsets" is a pitfall and then propose a bureaucracy framework to overcome it. Oh, the irony!

[svarodzic]

I walked out of an interview once when a team lead asked me how many lines of code I write during my work day! 🤐 Don't want to work with damb people.

[fruitloopz]

Managerial consultants basically just tell management what they want to hear. c suites will pay millions so that they can try some PR spin and tell their staff that their “consultants” told them to do the thing they were already planning on doing anyway. If it goes sideways they can blame “bad consulting”. On reality, Management never had an open mind from the start!

[thought-provoker]

As for sales performance - I do remember one organization that used to be worth around $10m, until they closed a sales deal of $100m: Overnight, the value of the company went up by an order of magnitude.
The whole company, everyone together, worked hard to produce the pitch that would close the deal.
Ultimately, the sales rep who closed the deal got the profit share, and the others got bogged down to no end in work to fulfill on the contract.
You can guess who retired early, and who left in frustration.
Who benefitted from measuring an individual on a team outcome? Only the person who is able to claim the award. But both the other team members (who might have done more than 90% of the work) and the company as a whole lose.

Win-lose scenarios are bad, and individual performance metrics create them.

[boballen]

at 12;52 mark, Dave hits the nail on the head without actually naming Goodhart's Law by name, simply referring to gaming the metric. "Any measure that become a goal ceases to be an effective measure."

[disgruntledtoons]

The troubling part is that managers will embrace this article as if it had descended from heaven on tablets of stone accompanied by angels with trumpets. Managers as a class are addicted to having a sense of control, even if it's an illusion. Having a simple metric for judging performance provides this illusion.

[DavidBeaumont]

I've always been someone who spends a longer time writing more carefully designed software. My software rarely has bugs and generally works very reliably. The trouble is that there's no easy metric for the problems that didn't happen because my software was good, but it's easy for people to invent a mythical opportunity cost for what I could have done in the time if I worked faster with less care. I'm not saying my approach is better (I'm just a bit of a perfectionist and would find startup work awful) but it's a constant struggle to fight against some of these stupid metrics.

[PeterCaron]

Nonsense, yes. And dangerous when the C-suite starts to believe it. Tech leaders need to understand why this kind of false flag metric is problematic and more importantly, what to propose in its place that makes sense. If not, CEOs will make even more mistakes when deciding technical directions.

[_Mentat]

The best software engineering managers are ex-devs who are ardent users of the product. They snatch code from the devs, build their own releases, and are trying out new features even before the devs have said 'done'. The worst have never even used the product, don't know how to install it, and are doing everything by numbers: lines of code, story points, whatever; they like to imagine these are telling them something.

[YuriBez]

The irony for me in this, is that I've experienced McKinsey's twice, in two separate corporations, and both times their suggestions were implemented, they were absolutely catastrophic failures in time, money and wasted man-power. A chop-shop if ever I saw one. They are not called McConsey's for nothing.

[BrentBrewington]

“This Mckinsey report is harmful drivel”

Man, this guy does NOT pull punches. Love it.

[MarcoLenzo]

Thank you for not mincing your words and calling things for what they are. Unfortunately these bizarre ideas are often born in mid management and, when sold to the upper floors of a company, have a devastating effect on its culture and eventually productivity as well.

[AndrewBlucher]

Hi Dave, a sporadic viewer here.
I'm retired but still writing software, still learning, after 50 years. My minor thesis was on programmer productivity tools, in the '80's. Meaning that I've had an interest in this topic for 30 years. After watching your vid I went and read the report.
Apart from the issues that you highlight (I haven't chased up the other critiques) the biggest issue I see is a lack of transparency for how they came up with these "measures", what they actually measure, and how they have measured the performance of this model. Productivity was a hot issue when I started looking at it 30 years ago, and a lot of people have done serious work on it, but McKinsey say they've cracked it? They don't even provide examples of the kind of corporate culture that their approach was tried in.
A second issue is that they, like almost everyone involved in software, seem to lump all development work into a basket they call "coding". As I have taught in my programming classes: every line of code is a place for a bug. It's not entirely true, but it focusses beginners on thinking before they code. Well thought-through, well-_designed_ systems have fewer _opportunities_ for bugs. And it's usually faster too. This emphasis on coding misses that point.
I don't doubt that they've implemented it and seen improvements. If the existing approach is poor, and we implement almost any systematic change with a generally laudable goal and appropriate incentives, then we WILL see short term improvements. But they don't say how they measured the initial productivity, or the period of measurement.
So my conclusion is that the purpose of the report is to reduce everyone else's productivity as we critique it, then they can say "see, our way is better"!
'Till next time,
Andy

[rcrawford]

It's McKinsey. Someone wanted this conclusion. They measure "productivity", divide it by hourly cost, and "optimize the spend".

[ssssssstssssssss]

Productivity is measurable as it is just the rate of output given input. Overemphasis of productivity will get you in trouble in creative fields, though. Focusing on individual productivity in a collaborative field will get you in more trouble. Delivering value over the long term is what matters and you need to get your developers to focus on that. Overfocusing on productivity will get them to focus on their activities, not company objectives.