{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://www.vidyasource.com/blog/the-mckinsey-developer-productivity-analysis-is-a-ruse/",
  "url": "https://www.vidyasource.com/blog/the-mckinsey-developer-productivity-analysis-is-a-ruse/",
  "mainEntityOfPage": "https://www.vidyasource.com/blog/the-mckinsey-developer-productivity-analysis-is-a-ruse/",
  "headline": "The McKinsey Developer Productivity Analysis Is a Ruse",
  "description": "The McKinsey developer productivity analysis is worse than wrong. It's bad faith. Your organization can do so much better.",
  "datePublished": "2023-10-09T00:00:00.000Z",
  "author": {
    "@type": "Person",
    "name": "Neil Chaudhuri",
    "jobTitle": "President",
    "url": "https://www.linkedin.com/in/neil-chaudhuri/",
    "sameAs": "https://www.linkedin.com/in/neil-chaudhuri/"
  },
  "publisher": {
    "@id": "https://www.vidyasource.com/#organization"
  },
  "image": "https://www.vidyasource.com/img/blog/mckinsey.jpg",
  "keywords": [
    "Leadership",
    "AI",
    "Government",
    "Programming",
    "Testing",
    "Security",
    "Cloud Computing",
    "Software Engineering",
    "Architecture"
  ],
  "articleBody": "There is a popular debate on Tech Twitter that rears its head every few weeks but has become particularly salient recently.\n\nNo, not the one about whether HTML is a programming language. Or the one about whether Tailwind CSS is good. Or the one about whether microservices are a disaster.\nOr the one about whether you need to hustle and grind to have a career in tech. Or even the one about whether you need a computer science\ndegree to excel in tech.\n\n(We sure do have a lot of dumb whack-a-mole arguments in tech, don't we?)\n\nIt's the one about whether, and how, you can measure the productivity of individual software developers in an organization.\nThe industry is focused on the idea lately since the job market in tech has faced upheaval coming out of the pandemic and since famous CEOs have\nbrazenly made it clear they think very little of the tech workforce—from Elon Musk's mission to fire anyone who isn't\n\"[extremely hardcore](https://www.theregister.com/2022/11/16/musk_twitter_ultimatum/)\"\nto Mark Zuckerberg's \"[year of efficiency](https://www.reuters.com/technology/meta-lays-off-tech-teams-battering-employee-morale-2023-04-19/).\"\n\nIt turns out this isn't a debate at all: _You cannot measure individual productivity._ As we will see shortly, research has settled the question, but\nthat hasn't stopped people from [trying to make fetch happen](https://www.youtube.com/watch?v=Pubd-spHN-0).\n\nMcKinsey recently released a report called\n*[Yes, you can measure software developer productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity)*.\nAs the title suggests, the authors affirmatively declare that you *can* measure individual productivity, and they offer a framework for doing so.\nMcKinsey is wrong, but it's worse than that. McKinsey is motivated now more than ever to offer tech managers this fiction,\nand it's all just a ruse to get paid for telling CEOs what they want to hear.\n\n## Who is McKinsey anyway?\n\nMcKinsey is a management consultant company. In theory, they help managers become better managers. McKinsey is like [The Bobs in Office Space](https://www.youtube.com/watch?v=j_1lIFRdnhA)\nwith the elite pedigree of [\"the kids\" in Succession](https://succession.fandom.com/wiki/Roy_family).\n\nManagement consulting isn't a bad idea. In fact, it's a great idea! We have all known managers who...aren't awesome. They can use help.\nLuminaries like Eliyahu Goldratt, Susan David, Peter Drucker, Amy Edmonson, Daniel Goldman, Adam Grant, and many others\nhave made significant contributions to management consulting and organizational psychology. The problem is McKinsey\n[gets a lot wrong](https://x.com/TrungTPhan/status/1688583089323438080?s=20) and, even worse, has [sold its \"expertise\"\nto the worst clients and themselves have done legally dubious things](https://fortune.com/2023/06/21/mckinsey-hiring-ethics-salary/).\n\nNow their ethical and moral lapses, and even their long track record of really bad predictions, don't necessarily mean\nMcKinsey's analysis of software development productivity is wrong, but they do provide context for how McKinsey does business\nand why they might find it valuable to weigh in on the issue.\n\n## What's in it for McKinsey ?\n\nWith all the problems in the world, why would McKinsey spend time analyzing the feasibility of measuring individual software development productivity?\n\nI am a retail investor, and one thing I have learned is Big Tech does not optimize for profit *per se* but for share price. You\nmay know Big Tech stocks took a big hit coming out of the pandemic for a lot of reasons, and there are two things Wall Street\nwants to see from companies in trouble that they want to see succeed: layoffs and buybacks (companies using\ntheir cash on hand to buy their own stock). So predictably and sadly, Big Tech recently engaged in mass layoffs. In waves! Lest you\nthink it was because of a lack of resources to pay people, [they had the money to execute buybacks as well](https://finance.yahoo.com/news/tech-giants-embrace-stock-buybacks-120012389.html).\n\nThe Street loved the combination as it always does. Big Tech stock went up once again.\n\nThe good news for software engineers is The Street now wants to see big investments in AI, so Big Tech is slowly hiring again—often the\nsame people they laid off. That tells you it's not about developer performance or the numbers on a balance sheet. Just stock price.\n\nSo what does all this have to do with McKinsey?\n\nMcKinsey is a firm with no ethical compunctions about contributing to\nmass layoffs, and they know there are deep pockets willing to pay them large consulting fees for a framework that makes layoffs look\nlike the result of rigorous academic analysis rather than a cynical ploy for the next shareholder call.\n\nIt's a ruse.\n\n## What does McKinsey get wrong about measuring the productivity of individual developers?\n\nLet's assume for the moment McKinsey did their analysis earnestly in good faith. Then McKinsey does not understand how software development works in the real world because they're consultants not\nengineers. I recommend you check out [Daniel Terhorst-North's post](https://dannorth.net/mckinsey-review/) also critical of McKinsey's report,\nincluding a terrific point on the absence of gender diversity among its authors, for a detailed analysis, but\nlet me add some thoughts.\n\n### McKinsey thinks code is the unit of productivity, so the best engineers churn out the most code\n\nIt's true that we sell products and products are made of code, but you and I know code is the easy part. So much so\nthat Generative AI can write a lot of it. The hard work is understanding your customers, learning the business domain, reviewing code because not all code is good code,\nexperimenting with new tech, manually verifying accessibility, supply chain security, cleaning up technical debt, integrating with legacy systems, writing tests,\nautomating cloud deployments, mentoring inexperienced engineers, writing documentation, creating a design system,\nand lots of other things essential to mature software delivery.\n\nPut more simply, McKinsey thinks of code like Pez coming out of a dispenser, which is what people who don't build software think\nbuilding software is like. The reality is it's not about code; it's about _features_ that users will enjoy. Code is only\na small part of that. Maybe even the easiest!\n\n### That Outer Loop/Inner Loop Dichotomy is Nonsense\n\nMcKinsey distinguishes \"Outer Loop\" activities from \"Inner Loop\" activities where the latter is productive and the former is waste.\nAs you'd expect, the Inner Loop is about churning out code. They suggest teams should aim for 70% in the Inner Loop. Where does\nthat number come from? Who knows? They made it up like a middle schooler who forgot oral reports are due today.\n\nIt's also telling they put \"Security and Compliance\" in the Outer Loop. It's that kind of mentality that causes so many large\ncompanies, many of whom are likely McKinsey clients but should know better regardless, to suffer embarrassing breaches that compromise our data. In fact, all the Outer Loop activities\nare important because they are critical to feature delivery, which is what matters. Users pay for features, not code.\n\n### \"Contribution Analysis\" and \"Talent Capability Score\" Have No Basis in Research\n\nBased on the book of the same name, the movie [Moneyball](https://en.wikipedia.org/wiki/Moneyball_(film)) is the true story of the Oakland Athletics (aka the A's),\na baseball team that lacked the resources to sign the most clearly talented and therefore most expensive\nplayers and devised a data-driven approach to assemble cheap, undervalued players into a very good team that could challenge\nrich teams who could afford the big names. The A's were at the vanguard of the analytics movement that is now commonplace\nin baseball, and one of the key objectives of this approach is to isolate the value of a particular player from the rest of the team.\nIt's a great idea, but it's really hard and not necessarily always successful. In fact, the most popular modern statistic is Wins Above\nReplacement (WAR), which seeks to measure how much better one player in isolation is than a \"replacement\" you can find anywhere, but\n[there are three variations on WAR](https://www.mlb.com/glossary/advanced-stats/wins-above-replacement) because the three references\ndon't agree on how to calculate it.\n\nMeasuring the productivity of an individual in the context of a team is all but impossible.\n\nIt's even harder in software development where so many different, unquantifiable activities go into delivering a feature from talking to users\nto building design systems to setting up automated deployments to observability and instrumentation to compliance with laws and\nregulations and on and on. McKinsey's obsession with productivity as lines of code and PRs submitted is reductive and naive.\n\nBut it gets worse.\n\nLet's imagine a developer who is struggling. After all, that happens. It's happened to me. No matter your line of work, we all have Imposter Syndrome\nand other crises of confidence. If it persists, that isn't the developer's fault. It's the fault of organizational leadership to\ncreate the conditions necessary for [flow state](https://leaddev.com/culture-engagement-motivation/why-flow-matters-more-passion).\n\nIn fact, this leads to the biggest problem I have with the McKinsey report.\n\nThe authors have the nerve to pay lip service to the [DORA metrics](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance)\nand the [SPACE framework](https://queue.acm.org/detail.cfm?id=3454124) (more on these shortly), both pioneered by the legendary Dr. Nicole Forsgren\nand her colleagues on the basis of years of research, only to shove them aside in favor of contrived jargon like \"Contribution Analysis\" and \"Talent Capability Score\" and\n70% \"Inner Loop\" activity with the pretense of the same academic rigor.\n\nAre you kidding? It would be like if I said \"Einstein's great. He's my guy. But I would like to complement his Theory of Special Relativity expressing the equivalence of mass and energy\nwith my own Theory of Artificial Quantum Matrix Superposition that states the nutritional value of [Sour Patch Kids](https://sourpatchkids.com/) is directly proportional\nto the nutritional value of the fruits they represent. These are two equally valid theories!\"\n\nThis is how you know it's a ruse. McKinsey has no interest in creating a framework to measure developer productivity. Ever the ethically challenged firm, McKinsey has an interest in\npersuading tech CEOs to pay them lots of money to rationalize layoffs to juice stock prices _under the guise of a research-driven framework_ to measure developer productivity.\n\nIt's an insult to the tech industry, to our intelligence, and worst of all, to software engineers devoting so much of their time and\nmental health to organizations that blame them for the failures of management.\n\nThe good news is we can trust Dr. Forsgren and her teams to show us real, good faith metrics grounded in research that we can use\nto improve software product delivery.\n\n## Forget McKinsey. Give Yourself SPACE\n\nIn his seminal book *Lean Startup*, author Eric Ries introduces the concept of the Minimal Viable Product (MVP):\n\"[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.\"\n\nWhile tech has taken the MVP to mean an alpha or beta version of a product, Ries means something different—a cheap, lightweight\nform of the product that helps you validate or reject your assumptions about what customers want before you invest time and money into building it.\n\n>>> In the book, Ries makes it clear the product doesn't even have to be tech. He gives an example of a laundry service in India that uses a prop washing machine on a truck as its MVP!\n\nEven before you start building and certainly as you continue building, you need to continuously validate your organizational performance\n(the **_P_** in SPACE) at giving customers and other stakeholders what they want. This is *building the right thing*.\n\nYou also need to establish a culture of teamwork, psychological safety, flow state, and commitment to quality to promote a delivery pipeline that delivers to\nusers the product they want with the efficiency (the **_E_** in SPACE uniting all the other dimensions) they demand. This is *building the thing right*.\n\nWith SPACE and DORA metrics, Dr. Forsgren and her teams have given us the blueprint to accomplish both. McKinsey has weaponized their\nwork to promote their own proprietary, lazy nonsense to appease layoff-hungry CEOs.\n\nTo be fair, the SPACE team [acknowledges](https://queue.acm.org/detail.cfm?id=3454124) there is value in tracking raw development activity (the **_A_** in SPACE) like the kind\nin McKinsey's Inner and Outer Loops:\n\n>>> Developer activity, if measured correctly, can provide valuable but limited insights about developer productivity, engineering systems, and team efficiency. Because of the complex and diverse activities that developers perform, their activity is not easy to measure or quantify. In fact, it is almost impossible to comprehensively measure and quantify all the facets of developer activity across engineering systems and environments. A well-designed engineering system, however, will help in capturing activity metrics along different phases of the software development life cycle and quantify developer activity at scale.\n\nBut they also clarify that activity tells you nothing on its own without context about the broader systems in place. Activity ≠ Productivity.\n\nThere are many ways to achieve the goals SPACE and DORA lay out, and how you get there depends on the nature and culture of your organization.\nFor example, a 100% remote workforce of experienced engineers may have different ways of working than a hybrid workforce\nof various experience levels engaging with contractors around the world. You need to figure out what works best for\neveryone to encourage diversity in all its forms to deliver the best work, and if you maintain the research-driven SPACE and DORA as your\nguide and ignore bad faith ruses from mercenaries like McKinsey, you will succeed."
}