The Hagakure #68: The Curious Case of McKinsey

On holy wars, bridges burned, and perhaps a different perspective on the question of software developer productivity.

I never worked for the FAANGs, or MAANGs or MANGOs or whatever the acronym is these days.

Maybe I wasn’t good enough (Narrator: “he wasn’t.”)

But by the good grace of the universe I was afforded some diverse opportunities over the last two decades of my career:

• Software developer (full stack)

• Team Lead (first line manager)

• Director of Engineering (middle manager)

• VP of Engineering (executive, reporting to the CEO)

• Interim VP Product (let’s be honest, onlyfor 4 months)

• Leadership Coach (to tech/product leaders at all levels above + founders)

While this doesn’t make me any special or better than anybody else, it did give me one important thing: perspective. I remember how I used to look at my senior leaders when I was dejected, resentful, and tired. Why can’t they see the obvious?!

While there was a kernel of truth in that, I also couldn’t see some “obvious” stuff myself simply by virtue of never having been in their shoes. When I eventually did get in their shoes, I didn’t suddenly agree with everything in retrospect. But the resentment went down as the empathy and situational awareness went up.

Now, as a leadership coach, I am privileged to be able to spend a ton of time educating myself on things like neuroscience and psychology, and practicing them in every single coaching session. I became more aware of how change happens—or doesn’t. And also how difficult it is to bring it about.

If you’re wondering what all of this has to do with the “developer productivity” debate, the recent McKinsey article, and its many rebuttals¹, my answer to that is:

Everything.

But first let’s examine a take on how we got here and now.

The Great Debacle

I don’t remember where I heard this analogy, but the recent “macroeconomic environment” with its high interest rates, drying up of capital and all the attendant consequences is like the ocean tide receding and exposing a lot of junk.²

I am talking about the many businesses that had a rude awakening to the fact that they weren’t real businesses to begin with. The music stopped, the lights went up and the dancing emperor truly had no clothes. Default dead.

When you can no longer hire another 20 people to make up for the lack of leadership and management capability, you have to reckon with it. When you can no longer get another few million bucks to keep the game going, you have to get serious—or not play.

This is the stuff that happens when you’re playing a game that allows people to take life-changing money off the table without ever having to build a real business.³ Think about that for a second.

I do believe few founders who now find themselves in this situation had the level of awareness necessary to even understand the game they were playing.⁴ Hindsight is 20/20 and if you were a first-time founder, with no prior experience to draw from, that’s really all you got.⁵

The Great Fear

So, long story short, there’s a lot of free-floating anxiety in the system. No wonder.

Anxiety comes from fear.

As I wrote 6 months ago:

• Founders live in fear that their baby won’t make it.

• CEOs live in fear of their board, and that the forecast won’t be met.

• Senior management lives in fear of their CEO and of their performance targets.

• Middle managers live in fear of their bosses, and of their teams’ expectations.

• Individual contributors live in fear of the next performance review, and not meeting the sprint goals.

When we’re in fear, distressed and anxious, the amygdala takes over and the thinking brain goes offline. We stop responding and start reacting. Whatever our defaults, that’s what we will automatically resort to.

Credit: iStock (tatianazaets)

I’m again reminded of one of my favorite quotes by the Greek poet Archilocus:

“We don’t rise to the level of our expectations. We fall to the level of our training.”
―Archilochus

And what is that training (read: default) for most senior leaders in in most places?

Control. Tighten the ship.

So, that black box over there that is the engineering team we have been at best tolerating thus far? This feeling that many of these folks are coasting and not pulling their weight? Or too junior for their own good? And how they spend all that time working from home or cafés nowadays…

We should really crack down on that stuff.

How about we finally measure them like we measure everybody else?

Why should they be any special?

Because, as they say, what gets measured gets managed.⁶

The Great Divide

The fact of the matter is that there is a gigantic (and widening) gap between tech and non-tech folks.

• Most executives and managers don’t understand the work they want to measure, nor the people who perform it.

• Most engineers and engineering leaders don’t understand the business they’re serving, nor the “non-technical” people who drive it.

Kent Beck and Gergely Orosz teamed up to articulate a great response to the McKinsey article (part 1 and part 2). I found myself nodding along with virtually every point they made. But I couldn’t help notice that they are clearly speaking to software engineers and engineering leaders. They are speaking to their tribe.

Likewise, the McKinsey article is obviously speaking to CEOs and CFOs. Their tribe.

Meanwhile, both sides are talking past each other, and increasingly mistrusting one another. Executives’ obsession with gathering “productivity data” is symptomatic of this. While Kent Beck mentions in his response:

Get comfortable with your own judgement. Executives relying unnecessarily on “data” seem to be running from responsibility.

I really don’t know if it’s about running from responsibility as much as it is saying, I’m done trying to talk to you, give me cold hard data, so we can make our decisions.

Zero trust.

Credit: Ivy Liu

Ironically, while remote work literally saved thousands companies during the early innings of COVID back in 2020—which theoretically should have increased mutual trust—the fact that people liked it a little bit too much made the pendulum swing all the way to the other side. Why?

It’s not hard to see why.

2020 and 2021 saw massive influx of cash in the form of stimulus for handling the COVID downturn, leading to frothy markets and general insanity. Many were living well above their means. And when there’s money, “all is quiet in the western front.” But when the bubble burst in late 2022, anxiety ensued. And whatever trust there was got deflated like a baloon.

“I told you this remote work lunacy doesn’t work. Nobody’s working hard.”

We fall to the level of our training, alright.

But… it takes two to tango. Engineers and engineering leaders have also been promoting this rift (even if sometimes unknowingly or unwillingly) for a long time. As Beck and Orosz point out, the question of engineering productivity has historically been a nebulous one leading to an inevitable perception of lacking accountability.

The fact of the matter is that in the absence of true understanding of “the other side” a vicious cycle follows and gathers strength: expectations not met lead to further entrenchment and avoidance of commitment, leading to even less meeting of expectations… and the gap keeps widening.

This, to me, is the crux of the matter: without trust, shared understanding and, dare I say, compassion, this holy war will never end.

And building bridges will not happen simply by virtue of pointing to the other side and saying, “be better!”

The Great Disconnect

If a divide is not enough, we have a disconnect, too. And it underpins this whole story. To illustrate it, here’s an interesting bit of McKinsey history.

John Seddon, right at the start of the introduction to his great book, Beyond Command and Control, quotes veteran BBC journalist and broadcaster Peter Day:

“When I asked Marvin Bower [the architect of management consultancy McKinsey] what his main regret was in 60 years of advising the top people in first American and then global business, he did not hesitate in his reply: ‘The prevalence of command and control,’ he said.

When I put the same question to Peter Drucker, his answer was immediate: ‘I heartily agree with my friend Marvin Bower,’ he said. A one-line answer that addressed the abiding problem of most organisations then and now.”

And what was that ability to “command and control” rooted in? Seddon goes on to explain:

One hundred years ago James McKinsey – he of the eponymous consulting firm – solved a problem that had been plaguing Alfred Sloan, the chairman and CEO of General Motors. With the invention of budget management, McKinsey provided a grateful Sloan with a means of bringing order to the amorphous mass that was the sprawling US car firm at the time. Unfortunately, he had also unknowingly created the keystone of the command-and-control management model lamented by Bower and Drucker, which is now as far beyond its sell-by date as house-sized gas-guzzlers with fins. Re-thinking McKinsey’s century-old invention is fundamental to escaping – going beyond – the prison of command-and-control management.

Interesting, right? Management by spreadsheet, as I affectionately like to call it. This, by the way, is the same McKinsey who now claims that “Yes, you can measure software developer productivity.”

Some things never change.

Personally, I had to become a VP Engineering myself to finally be exposed to a company budget and to see how everything stems from it. Target setting, forecasting, and resource allocation all in one place—an incredibly bad idea, when you think it through. It literally is the root of all evil.⁷

When that “master spreedsheet” becomes the holy grail, codifying how the future must manifest or else bad stuff happens, can you blame those who own it for craving certainty and predictability? For doing all they can to bring it about?

For being particular susceptible to open their purse to those who speak directly to what keeps them up at night and offer them a solution?

Here’s the problem, though.

What do executives have as a means to achieving those results? As I wrote in an earlier Hagakure:

Yep. Nothing more than a bunch of humans, all quirky, each one a beautiful snowflake with their own story, issues, hopes and ambitions. Each one with their own life experience, cultural background, childhood traumas, mental models and cognitive biases.

In other words, what you have to work with is a complex (human) system.

And one thing a complex system is not amenable to is control. But control it we try, with all our might:

• By seeing the entire enterprise as a machine to optimize, with “inputs, outputs, drivers, levers,” and all other sorts of metaphorical mechanical language—and we wonder why people feel like cogs in the machine.

• By introducing all sorts of bureaucracy to ensure everyone stays in their lane—while thoroughly dehumanizing the enterprise in the process.

• By mistaking complexity for the merely complicated⁸ and thus always resorting to “divide and conquer” strategies. Enter OKRs and all sorts of detailed metrics, breaking everything down to its parts in the hope that it will all neatly ladder up to success at the top—and the inevitable disappointment when it doesn’t.

When you put it all together—the debacle, the fear, the divide, and the disconnect—is it any wonder that McKinsey swoops in with a confident solution and makes bank?

What Now?

This post is long enough already.

I hope it gave you, dear reader, perspective on how we got here, and why the McKinsey statement would always, inevitably stir things up.

I think this is an opportunity.

In an upcoming post, with hopefully clearer eyes, we’ll get back to this topic and explore what can be done from here. Starting with bridging the divide rather than perpetuating it. Here’s a spoiler, though: it won’t just take brains. It’ll take heart, too.

If you’re an executive or engineering leader who’s not willing to allow for the idea that change is first about emotion and needs, my prognosis for you and your organization is not very good. You can keep doing what you’re doing, and get the same exact results.

But if you believe otherwise, as I suspect many of my readers do, let’s continue.

Work works better when we bring compassion and intellect together, and we build bridges rather than burn them.

Credit: XiaoYun Li

1. Notably Kent Beck and Gergely Orosz’s joint response (parts 1 and 2)

2. As an aside, I find it equal parts amusing and sad how “layoffs” got smoothly rebranded not only as “reductions in force” but conveniently hidden behind the acronym “RIF”. What a soothing balm for the soul, ain’t it? The power of language in creating our reality never ceases to amaze me.

3. It is entirely possible (and legal) for founders to take millions into their own pocket in so-called “secondaries” as part of a fundraising round, all while the company is burning cash. Idea being it “de-risks” things for the founder, lowering their anxiety and allowing them to better execute from then on.

4. To all founders who were aware of the risks but literally rationalized seeing people as commodities to do their bidding, I try to be compassionate with you. But it’s really, really hard.

5. And often poor advice from investors who can’t help but pattern-match with their experience in widely different contexts. Like with everything else, some VCs are awesome advisers, too.

6. A poignant reminder of Grace Hopper’s beautiful words: “Don't try to manage people; you manage things; you lead people.” Yet, we insist on measuring people, so that we can manage them.

7. I highly recommend reading This Is Beyond Budgeting by Bjarte Bogsnes in order to fully understand the pernicious effects of the budget in modern knowledge work organizations. Eye opener.

8. The Cynefin framework helps understand this crucial difference.