12 ms·

What McKinsey got wrong about developer productivity

81 points by RHSeeger 3y ago

strict9 3y ago
>the McKinsey framework only measures effort or output, not outcomes and impact, which misses half of the software developer lifecycle. >“The McKinsey framework will most likely do far more harm than good to organizations – and to the engineering culture at companies. Such damage could take years to undo,” Orosz and Beck argue. I would go further and say it will likely damage user experience too. Cranking out features to game productivity scores and ignoring outcomes is a good way to get bloat, bugs, cluttered and overly complex UI, and an overall degraded user experience.
- bane 3y ago
  The incentives for software development are somewhat broken. In the "old" days, there was an infinite amount of basic software to write (Operating Systems, file editors, compilers, etc.) and very few developers working on extremely expensive equipment. They had to write software that would just work, features were added based on need, and the idea of a continuous, high-effort, software development activity for a piece of software wasn't the rule. Once the job was done, the developers simply got paid and moved on. Updating, patching, etc was hard to do. So the incentive was to deliver high-quality working software that did what it needed to do for decades without there being a continuous development effort to keep it "updated" because you only got paid by moving on to new jobs. Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". This translates into shipping broken, buggy, incomplete, software with the intention to keep the department occupied over the long-term with bug fixes, patches, feature updates and releases, and probably the occasional all-up rewrite. The industry says that the ideal form of this is to not only push releases every so often but to do it continuously in a never ending unbroken stream of work. But what happens when the software really is "done"? The answer is that we see it all the time. Often in various forms of enshittification (i.e. rent-seeking). Feature reductions, refactoring parts of a perfectly working system stack, changing languages. The incentive is to vertically integrate rent-seeking, companies are incentivized to seek new monetization sources (I want to say as a way to grow their business, but often it's to keep paying a crushing labor pool), down to developers who aren't incentivized anymore to ship-and-move-on. We also see other bizarre symptoms like taxi companies writing scalable message passing services and geospatial systems, or social networking companies building state of the art AI systems. So here's an idea, what if the way it should work is thus? - Developers are payed by the job, they pre-negotiate the price and the payment cadence (monthly, milestone, etc.) - Groups of developers could form an Agency if they want to centralize the negotiating and business bits. - Companies hire developers or Agencies for the job. A certain level of bug fixes are included in the contract. (x-number of months, so many bugs, certain number of hours, etc.) - Feature updates are new jobs. - Terms to include: "so long as we continue to use the software on our systems, the developers will get payed residuals." Modeled on how other Agency-based industries like acting or music continues to pay-out for use of the systems. - Good developers can end up on a big passive income stream, and could either continue working in the industry, or perhaps start spending part of or all of their time working on open-source projects that could provide reuse across projects within their industry. - The Best developers could go into a company, negotiate a nice contract, and the job could mostly be to yank the code out of a repo, compile, configure and run -- then collect passive income for the next few years as the company gets value out of that simple exercise. It's not the effort of the developer that bring value to the company, it's the value of the solution, so why doesn't the industry incentivize that?
  - deleted 3y ago
    [deleted]
  - drewcoo 3y ago
    > CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". CI is only about what happens before software is delivered. And I don't see what CD has to do with staff size. I think you're pointing out valid problems and misattributing their causes.
    - geodel 3y ago
      Well, looking into bookish definition of CI/CD will not help here. In real world I regularly CI/CD pipelines reflects to delivery/product managers how fast features are churned out by team to be presented to business. A 10K ft view of CI/CD is often used by group leads, executives to show whats being achieved even at company level.
      - UK-AL 3y ago
        CI/CD is making sure your code is always in a production ready state and validating with tests and other tools automatically.
        geodel 3y ago
        Okay. So? JIRA is supposed to track work that is to be done. Now JIRA is used to generate work when none exist because if there are hundred JIRA ticket resolved this week there must have lot of work done.
    - bane 3y ago
      Making an example up that I don't know to be true, but please just go with it: Google likely has a dedicated team who do nothing but tweak the front page of www.google.com I bet there's a Kanban-like board somewhere within that team with tickets like "change the button for image search to new branding icon" and "move the "About" button to the left-most upper corner from the right-most upper corner." "Make the corners on the search box more round" or whatever. Looking at the page now, somebody definitely had to generate work, and some poor front-end developer definitely had to perform the work to put the "Our third decade of climate action: join us". Every couple of years the team will take on some kind of task like moving the front-page to a new internal framework, or connecting it to some new search/advertising API. Remember when google would show real-time search results as you typed? "Let's put a Pacman game as the logo!" Here's Google's front page from 10 years ago https://web.archive.org/web/20130101000532/http://www.google.com/ https://web.archive.org/web/20130101000532/http://www.google... Somebody is making those changes, they exist. The decision to CD that page keeps them around. However, there is effectively almost no perceptible difference in the program performance, features, capabilities, or really even the aesthetics of that page in that time period to the user. It should be on maintenance mode with checking in on it being a part-time job for a single person. I bet that there's more than a dozen people who's sole job it is to keep that page "fresh". That's how CD results in inflated team sizes -- it's the "C". CI/CD never makes it over the wall into CM (continuous maintenance) and as a result becomes it.
- haolez 3y ago
  I'm very much a hacker myself, but isn't this a little unfair? There is an entire column in the framework described as "Outcome focus" and the items seem to make sense on a first glance. I'm not saying that the framework is good, but this specific criticism to it seems wrong.
boxed 3y ago
Another article missing the more fundamental point: You can't measure any productivity that has any cognitive component. Devs think it's ok when sales productivity is measured like this, and then they don't understand that this is the reason sales are selling features that don't exist. We need to all stand against this madness. This goes for teachers, sales people, programmers, doctors, everything.
- mandelbrotwurst 3y ago
  > You can't measure any productivity that has any cognitive component. Are you able to elaborate on why this is true please?
  - bane 3y ago
    How many units of thinking did you perform today? How do you charge or how are you payed per thinking unit?
    - RandomLensman 3y ago
      How much profit did that thinking create at the end of the year (or whatever the horizon is)?
      - Scarblac 3y ago
        I never understood how I'm supposed to know that. The company as a whole makes a profit, how do you know what it would have been if feature X wasn't implemented? And ten people had a role in deciding to implement it, four in implementing it. How can I possibly put a number on my contribution?
        RandomLensman 3y ago
        You can at least start from the top: the overall thing you are working on, how much did that make? Are features you worked on a contributing reasons for a sale/how much extra did they bring? Are you directly linked to some sales because you provided something specific? If you are doing internal software, could be cost reductions associated with that or also additional business. Your number won't be exact, but it doesn't have to be and double counting among the other people isn't always bad.
mistrial9 3y ago
is there more from McKinsey than this post[0] ? (I did read a recent 40-page glossy PDF on effects of AI on job sectors. I thought it was slightly over-confident but done well enough) [0] https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity#/ https://www.mckinsey.com/industries/technology-media-and-tel...
neaden 3y ago
McKinsey's whole business model seems to be hiring smart inexperienced people to go consult with experienced people who know a lot more then they do so I'm not surprised that they yet again got something wrong.
- pm90 3y ago
  Reputation laundering
- blamestross 3y ago
  And it is worth pointing out there is _some_ value to that. It gives a chance for implicit assumptions about how things work to be exposed, and allows the conscious choice on if to keep them. Now whether McKinsey is actually delivering on that idea, or just exposing the implicit assumptions of "don't be an asshole and don't do things that are harmful to everybody else" and encouraging dropping them, is a problem.
- fnordpiglet 3y ago
  Their whole business model is taking smart, malignant, experienced people and convincing senior leadership to outsource responsibility for something crucial but obscure (from the leaderships perspective) to them, then installing a lot of smart well spoken but inexperienced people into the organization in a giant bait and switch with the authority to drive strategy but the inability to craft a useful strategy. Over time they work to pit leaders against each other to drive a wedge they can fill with more people. After enough of this they can create a permanent dependency on McKinsey consultants until the board gets sick of the ineffectual leadership that’s been divided and conquered by McKinsey and hires McKinsey to devise a turn around, recommend new leadership, etc, as slowly the once proud enterprise devolves into a McKinsey zombie driven by inane process garbage rather than a vision. Somewhere along the way a private equity gets brought in by McKinsey and the transformation is complete.
  - marcosdumay 3y ago
    https://en.wikipedia.org/wiki/Ophiocordyceps_unilateralis https://en.wikipedia.org/wiki/Ophiocordyceps_unilateralis
mixedbit 3y ago
Found today on reddit: https://www.reddit.com/r/Jokes/comments/17ezr6c/a_shepherd_is_tending_his_flock_in_a_remote/ https://www.reddit.com/r/Jokes/comments/17ezr6c/a_shepherd_i...
nancyp 3y ago
John Oliver published an episode about them recently. https://www.youtube.com/watch?v=AiOUojVd6xQ https://www.youtube.com/watch?v=AiOUojVd6xQ
albertgoeswoof 3y ago
Here’s the link the article is referencing, if you want to read the source https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity#/ https://www.mckinsey.com/industries/technology-media-and-tel...
miked85 3y ago
I'm still mystified why companies hire a firm like McKinsey - they have no actual experience, but are telling people with experience what they should do.
- staunton 3y ago
  For example, they advise executives to do what they already want to do (layoffs and increased executive compensation) and thus justify that decision (blame outsourcing). A more generous take: when a business or project is stagnating due to bad management and communication, almost any advice that leads to change improves the situation. Especially when the situation is such due to some "principal actor" type issues, introducing more actors with different inscentives can rebalance things in the short term.
- lo_zamoyski 3y ago
  Probably because management can CYA by claiming to have done due diligence to their higher ups. "Well, we consulted McKinsey and took their advice, so if they got it wrong, then the industry is getting it wrong." (These are the same guys that tell countries with successful agricultural sectors to embrace corporate farming. Cui bono?)
  - distortionfield 3y ago
    I had a manager once who reminded me that “no one ever got fired for following McKinsey’s advice”
- RandomLensman 3y ago
  For certain problems, it will be people having looked at the same problem many times/speaking to industry leaders frequently, the junior people drawing slides etc. are not why you'd hire them.
  - philipodonnell 3y ago
    Don't forget "intel on if/how your competitors have solved them"
jhawk28 3y ago
Metrics are useful until you use them. If people know the metric, they will game them. Its better to track metrics to see symptoms of what is going on and then "walk the floor" to figure out why.
- daveslash 3y ago
  https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://web.archive.org/web/20040602185208/http://blogs.msdn.com/larryosterman/archive/2004/04/20/116998.aspx https://web.archive.org/web/20040602185208/http://blogs.msdn...
hkt 3y ago
Nobody should be surprised that management consultancies measure and manage the wrong things. That's the story of the last half a century. I've managed to avoid them for most of my career but if you ever want an inefficient, dehumanising work environment, go anywhere where the CTO listens to McKinsey and co.
- deleted 3y ago
  [deleted]
chiefalchemist 3y ago
> McKinsey argues that the objective of productivity measures is to incentivize developers to code more. This diminishes the idea that developers are creative workers. As for the last sentence, they buried the lede. And let's not forget, the incentive for McKinsey is to develop a product they can sell. How good that product is and it's "unintended consequences" are a distance second. McKinsey needs something billable, something upper management and leadership will buy into. Rarely is that the soft metrics. Many of us know what lack of appreciation for the soft metrics feels like as an employee. (Hint: it sucks.)
simonw 3y ago
I put together some notes on applications for Redis 13 years ago which are still surprisingly relevant today: https://static.simonwillison.net/static/2010/redis-tutorial/ https://static.simonwillison.net/static/2010/redis-tutorial/ I think that speaks to how extremely well designed Redis was from the very start - it's been remarkably stable over time, and those original ideas are still very much applicable 13 years later.
- simonw 3y ago
  Oops, this was meant to be a comment on another thread.
aranchelk 3y ago
> And, in a world where agile methods have long taught us that you can’t improve what you can’t measure. Edwards Deming, who in terms of process optimization, is (in my carefully considered opinion) head and shoulder above everyone I’ve ever encountered pushing related ideas in software development, challenges the idea of “you can’t manage what you can’t measure”. His belief was it’s far more important to understand the system in which a worker operates, after which you can absolutely make improvements affecting global output without a local measure.
- rrr_oh_man 3y ago
  Can you give a concrete example or elaborate a bit more?
Aurornis 3y ago
> the McKinsey framework only measures effort or output, not outcomes and impact Measuring outcome and impact gets messy when the developers aren’t the ones deciding what to work on. I had a VP of Engineering who was all about measuring impact and ignoring everything else. He was also adamant that product people decided what we work on, while engineers decided how it was implemented. This created an environment where your fate was determined almost entirely by what product team you got assigned to. If your product managers wanted you to implement a feature nobody wanted, it didn’t matter how well you did. You weren’t going to be able to show positive impact if nobody used it. Impact is only a good measure when you let people make their own decisions.
- vinay_ys 3y ago
  Ugh. A quintessential engineering mind is always curious, critiquing and questioning everything and will always want to know the why of the what and ask why not an alternate what. Such a mind be motivated by a higher purpose – finding meaning in larger impact of their work. Only such minds can be creative and persistent to solve the hardest problems to create outstanding product experiences. All it takes to destroy such a mindset is to tell them to shut-up, not to ask so many questions, and to do as they are told.
ath3nd 3y ago
We are talking about the people who: - were an instrumental part in creating Big Tobacco's strategy of "distract and create doubt, then delay, delay delay" - applied the same playbook with Big Oil - helped create the opioid epidemic - give advice to multiple oppressive regimes (e.g Saudi/Russia) Seems legit, let me take my engineering advice from these guys, they must know what they are talking about...
philipodonnell 3y ago
I used to do this kind of work, not with McKinsey. When you do it a lot you realize how hard it is and why. Everything you want to measure, someone will claim it doesn't capture this and that, or will definitely be gamed and destroy the company. A lot like this article and discussion really. Many times picking metrics are the easiest part compared to getting the data, calculating the time series, setting targets, managing under/out performance. It's all kinda inevitable... so my advice is always to not focus too much on the metrics and focus on managing instead. - Measure everything you your systems allow you to, maybe tweak some workflows, but don't add complexity or cost just for metrics. - Separate metrics into stuff that needs to stay the same (mostly operational efficiency metrics) and stuff that needs to change (strategic metrics) and spend more time on the latter. - Don't compensate or reward people based on them, just look at them a lot and if you see something that looks weird then talk to your managers about why, and if they can't answer or won't take action then that's all you need to know to reward them. - If you want to use metrics to create competition just publish a leaderboard and let peer pressure do the rest. People will work hard to be at the top of a public list even if there is no explicit reward for it. Just be a manager, manage the people, and use metrics that help you manage the people. You won't sell many consulting engagements that way tho.
richliss 3y ago
Having worked with McKinsey people, they will forever be Lyle Lanley for me... https://yewtu.be/watch?v=ZDOI0cq6GZM https://yewtu.be/watch?v=ZDOI0cq6GZM
deterministic 3y ago
Don’t measure productivity. Measure ROI (Return on Investment). You are running a business after all. Cashflow is king! Any productivity measure that isn’t derived from ROI is 100% guaranteed organic grass fed BS. Increasing “productivity” can actually reduce global ROI. I highly recommend looking into the Theory of Constraints.

81 points by RHSeeger 3y ago

>the McKinsey framework only measures effort or output, not outcomes and impact, which misses half of the software developer lifecycle. >“The McKinsey framework will most likely do far more harm than good to organizations – and to the engineering culture at companies. Such damage could take years to undo,” Orosz and Beck argue. I would go further and say it will likely damage user experience too. Cranking out features to game productivity scores and ignoring outcomes is a good way to get bloat, bugs, cluttered and overly complex UI, and an overall degraded user experience.

bane 3y ago
The incentives for software development are somewhat broken. In the "old" days, there was an infinite amount of basic software to write (Operating Systems, file editors, compilers, etc.) and very few developers working on extremely expensive equipment. They had to write software that would just work, features were added based on need, and the idea of a continuous, high-effort, software development activity for a piece of software wasn't the rule. Once the job was done, the developers simply got paid and moved on. Updating, patching, etc was hard to do. So the incentive was to deliver high-quality working software that did what it needed to do for decades without there being a continuous development effort to keep it "updated" because you only got paid by moving on to new jobs. Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". This translates into shipping broken, buggy, incomplete, software with the intention to keep the department occupied over the long-term with bug fixes, patches, feature updates and releases, and probably the occasional all-up rewrite. The industry says that the ideal form of this is to not only push releases every so often but to do it continuously in a never ending unbroken stream of work. But what happens when the software really is "done"? The answer is that we see it all the time. Often in various forms of enshittification (i.e. rent-seeking). Feature reductions, refactoring parts of a perfectly working system stack, changing languages. The incentive is to vertically integrate rent-seeking, companies are incentivized to seek new monetization sources (I want to say as a way to grow their business, but often it's to keep paying a crushing labor pool), down to developers who aren't incentivized anymore to ship-and-move-on. We also see other bizarre symptoms like taxi companies writing scalable message passing services and geospatial systems, or social networking companies building state of the art AI systems. So here's an idea, what if the way it should work is thus? - Developers are payed by the job, they pre-negotiate the price and the payment cadence (monthly, milestone, etc.) - Groups of developers could form an Agency if they want to centralize the negotiating and business bits. - Companies hire developers or Agencies for the job. A certain level of bug fixes are included in the contract. (x-number of months, so many bugs, certain number of hours, etc.) - Feature updates are new jobs. - Terms to include: "so long as we continue to use the software on our systems, the developers will get payed residuals." Modeled on how other Agency-based industries like acting or music continues to pay-out for use of the systems. - Good developers can end up on a big passive income stream, and could either continue working in the industry, or perhaps start spending part of or all of their time working on open-source projects that could provide reuse across projects within their industry. - The Best developers could go into a company, negotiate a nice contract, and the job could mostly be to yank the code out of a repo, compile, configure and run -- then collect passive income for the next few years as the company gets value out of that simple exercise. It's not the effort of the developer that bring value to the company, it's the value of the solution, so why doesn't the industry incentivize that?
- deleted 3y ago
  [deleted]
- drewcoo 3y ago
  > CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". CI is only about what happens before software is delivered. And I don't see what CD has to do with staff size. I think you're pointing out valid problems and misattributing their causes.
  - geodel 3y ago
    Well, looking into bookish definition of CI/CD will not help here. In real world I regularly CI/CD pipelines reflects to delivery/product managers how fast features are churned out by team to be presented to business. A 10K ft view of CI/CD is often used by group leads, executives to show whats being achieved even at company level.
    - UK-AL 3y ago
      CI/CD is making sure your code is always in a production ready state and validating with tests and other tools automatically.
      - geodel 3y ago
        Okay. So? JIRA is supposed to track work that is to be done. Now JIRA is used to generate work when none exist because if there are hundred JIRA ticket resolved this week there must have lot of work done.
  - bane 3y ago
    Making an example up that I don't know to be true, but please just go with it: Google likely has a dedicated team who do nothing but tweak the front page of www.google.com I bet there's a Kanban-like board somewhere within that team with tickets like "change the button for image search to new branding icon" and "move the "About" button to the left-most upper corner from the right-most upper corner." "Make the corners on the search box more round" or whatever. Looking at the page now, somebody definitely had to generate work, and some poor front-end developer definitely had to perform the work to put the "Our third decade of climate action: join us". Every couple of years the team will take on some kind of task like moving the front-page to a new internal framework, or connecting it to some new search/advertising API. Remember when google would show real-time search results as you typed? "Let's put a Pacman game as the logo!" Here's Google's front page from 10 years ago https://web.archive.org/web/20130101000532/http://www.google.com/ https://web.archive.org/web/20130101000532/http://www.google... Somebody is making those changes, they exist. The decision to CD that page keeps them around. However, there is effectively almost no perceptible difference in the program performance, features, capabilities, or really even the aesthetics of that page in that time period to the user. It should be on maintenance mode with checking in on it being a part-time job for a single person. I bet that there's more than a dozen people who's sole job it is to keep that page "fresh". That's how CD results in inflated team sizes -- it's the "C". CI/CD never makes it over the wall into CM (continuous maintenance) and as a result becomes it.
haolez 3y ago
I'm very much a hacker myself, but isn't this a little unfair? There is an entire column in the framework described as "Outcome focus" and the items seem to make sense on a first glance. I'm not saying that the framework is good, but this specific criticism to it seems wrong.

boxed 3y ago

Another article missing the more fundamental point: You can't measure any productivity that has any cognitive component. Devs think it's ok when sales productivity is measured like this, and then they don't understand that this is the reason sales are selling features that don't exist. We need to all stand against this madness. This goes for teachers, sales people, programmers, doctors, everything.

mandelbrotwurst 3y ago
> You can't measure any productivity that has any cognitive component. Are you able to elaborate on why this is true please?
- bane 3y ago
  How many units of thinking did you perform today? How do you charge or how are you payed per thinking unit?
  - RandomLensman 3y ago
    How much profit did that thinking create at the end of the year (or whatever the horizon is)?
    - Scarblac 3y ago
      I never understood how I'm supposed to know that. The company as a whole makes a profit, how do you know what it would have been if feature X wasn't implemented? And ten people had a role in deciding to implement it, four in implementing it. How can I possibly put a number on my contribution?
      - RandomLensman 3y ago
        You can at least start from the top: the overall thing you are working on, how much did that make? Are features you worked on a contributing reasons for a sale/how much extra did they bring? Are you directly linked to some sales because you provided something specific? If you are doing internal software, could be cost reductions associated with that or also additional business. Your number won't be exact, but it doesn't have to be and double counting among the other people isn't always bad.

mistrial9 3y ago

is there more from McKinsey than this post[0] ? (I did read a recent 40-page glossy PDF on effects of AI on job sectors. I thought it was slightly over-confident but done well enough) [0] https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity#/ https://www.mckinsey.com/industries/technology-media-and-tel...

neaden 3y ago

McKinsey's whole business model seems to be hiring smart inexperienced people to go consult with experienced people who know a lot more then they do so I'm not surprised that they yet again got something wrong.

pm90 3y ago
Reputation laundering
blamestross 3y ago
And it is worth pointing out there is _some_ value to that. It gives a chance for implicit assumptions about how things work to be exposed, and allows the conscious choice on if to keep them. Now whether McKinsey is actually delivering on that idea, or just exposing the implicit assumptions of "don't be an asshole and don't do things that are harmful to everybody else" and encouraging dropping them, is a problem.
fnordpiglet 3y ago
Their whole business model is taking smart, malignant, experienced people and convincing senior leadership to outsource responsibility for something crucial but obscure (from the leaderships perspective) to them, then installing a lot of smart well spoken but inexperienced people into the organization in a giant bait and switch with the authority to drive strategy but the inability to craft a useful strategy. Over time they work to pit leaders against each other to drive a wedge they can fill with more people. After enough of this they can create a permanent dependency on McKinsey consultants until the board gets sick of the ineffectual leadership that’s been divided and conquered by McKinsey and hires McKinsey to devise a turn around, recommend new leadership, etc, as slowly the once proud enterprise devolves into a McKinsey zombie driven by inane process garbage rather than a vision. Somewhere along the way a private equity gets brought in by McKinsey and the transformation is complete.
- marcosdumay 3y ago
  https://en.wikipedia.org/wiki/Ophiocordyceps_unilateralis https://en.wikipedia.org/wiki/Ophiocordyceps_unilateralis

mixedbit 3y ago

Found today on reddit: https://www.reddit.com/r/Jokes/comments/17ezr6c/a_shepherd_is_tending_his_flock_in_a_remote/ https://www.reddit.com/r/Jokes/comments/17ezr6c/a_shepherd_i...

nancyp 3y ago

John Oliver published an episode about them recently. https://www.youtube.com/watch?v=AiOUojVd6xQ https://www.youtube.com/watch?v=AiOUojVd6xQ

albertgoeswoof 3y ago

Here’s the link the article is referencing, if you want to read the source https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity#/ https://www.mckinsey.com/industries/technology-media-and-tel...

miked85 3y ago

I'm still mystified why companies hire a firm like McKinsey - they have no actual experience, but are telling people with experience what they should do.

staunton 3y ago
For example, they advise executives to do what they already want to do (layoffs and increased executive compensation) and thus justify that decision (blame outsourcing). A more generous take: when a business or project is stagnating due to bad management and communication, almost any advice that leads to change improves the situation. Especially when the situation is such due to some "principal actor" type issues, introducing more actors with different inscentives can rebalance things in the short term.
lo_zamoyski 3y ago
Probably because management can CYA by claiming to have done due diligence to their higher ups. "Well, we consulted McKinsey and took their advice, so if they got it wrong, then the industry is getting it wrong." (These are the same guys that tell countries with successful agricultural sectors to embrace corporate farming. Cui bono?)
- distortionfield 3y ago
  I had a manager once who reminded me that “no one ever got fired for following McKinsey’s advice”
RandomLensman 3y ago
For certain problems, it will be people having looked at the same problem many times/speaking to industry leaders frequently, the junior people drawing slides etc. are not why you'd hire them.
- philipodonnell 3y ago
  Don't forget "intel on if/how your competitors have solved them"

jhawk28 3y ago

Metrics are useful until you use them. If people know the metric, they will game them. Its better to track metrics to see symptoms of what is going on and then "walk the floor" to figure out why.

daveslash 3y ago
https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://web.archive.org/web/20040602185208/http://blogs.msdn.com/larryosterman/archive/2004/04/20/116998.aspx https://web.archive.org/web/20040602185208/http://blogs.msdn...

hkt 3y ago

Nobody should be surprised that management consultancies measure and manage the wrong things. That's the story of the last half a century. I've managed to avoid them for most of my career but if you ever want an inefficient, dehumanising work environment, go anywhere where the CTO listens to McKinsey and co.

deleted 3y ago
[deleted]

chiefalchemist 3y ago

> McKinsey argues that the objective of productivity measures is to incentivize developers to code more. This diminishes the idea that developers are creative workers. As for the last sentence, they buried the lede. And let's not forget, the incentive for McKinsey is to develop a product they can sell. How good that product is and it's "unintended consequences" are a distance second. McKinsey needs something billable, something upper management and leadership will buy into. Rarely is that the soft metrics. Many of us know what lack of appreciation for the soft metrics feels like as an employee. (Hint: it sucks.)

simonw 3y ago

I put together some notes on applications for Redis 13 years ago which are still surprisingly relevant today: https://static.simonwillison.net/static/2010/redis-tutorial/ https://static.simonwillison.net/static/2010/redis-tutorial/ I think that speaks to how extremely well designed Redis was from the very start - it's been remarkably stable over time, and those original ideas are still very much applicable 13 years later.

simonw 3y ago
Oops, this was meant to be a comment on another thread.

aranchelk 3y ago

> And, in a world where agile methods have long taught us that you can’t improve what you can’t measure. Edwards Deming, who in terms of process optimization, is (in my carefully considered opinion) head and shoulder above everyone I’ve ever encountered pushing related ideas in software development, challenges the idea of “you can’t manage what you can’t measure”. His belief was it’s far more important to understand the system in which a worker operates, after which you can absolutely make improvements affecting global output without a local measure.

rrr_oh_man 3y ago
Can you give a concrete example or elaborate a bit more?

Aurornis 3y ago

> the McKinsey framework only measures effort or output, not outcomes and impact Measuring outcome and impact gets messy when the developers aren’t the ones deciding what to work on. I had a VP of Engineering who was all about measuring impact and ignoring everything else. He was also adamant that product people decided what we work on, while engineers decided how it was implemented. This created an environment where your fate was determined almost entirely by what product team you got assigned to. If your product managers wanted you to implement a feature nobody wanted, it didn’t matter how well you did. You weren’t going to be able to show positive impact if nobody used it. Impact is only a good measure when you let people make their own decisions.

vinay_ys 3y ago
Ugh. A quintessential engineering mind is always curious, critiquing and questioning everything and will always want to know the why of the what and ask why not an alternate what. Such a mind be motivated by a higher purpose – finding meaning in larger impact of their work. Only such minds can be creative and persistent to solve the hardest problems to create outstanding product experiences. All it takes to destroy such a mindset is to tell them to shut-up, not to ask so many questions, and to do as they are told.

ath3nd 3y ago

We are talking about the people who: - were an instrumental part in creating Big Tobacco's strategy of "distract and create doubt, then delay, delay delay" - applied the same playbook with Big Oil - helped create the opioid epidemic - give advice to multiple oppressive regimes (e.g Saudi/Russia) Seems legit, let me take my engineering advice from these guys, they must know what they are talking about...

philipodonnell 3y ago

I used to do this kind of work, not with McKinsey. When you do it a lot you realize how hard it is and why. Everything you want to measure, someone will claim it doesn't capture this and that, or will definitely be gamed and destroy the company. A lot like this article and discussion really. Many times picking metrics are the easiest part compared to getting the data, calculating the time series, setting targets, managing under/out performance. It's all kinda inevitable... so my advice is always to not focus too much on the metrics and focus on managing instead. - Measure everything you your systems allow you to, maybe tweak some workflows, but don't add complexity or cost just for metrics. - Separate metrics into stuff that needs to stay the same (mostly operational efficiency metrics) and stuff that needs to change (strategic metrics) and spend more time on the latter. - Don't compensate or reward people based on them, just look at them a lot and if you see something that looks weird then talk to your managers about why, and if they can't answer or won't take action then that's all you need to know to reward them. - If you want to use metrics to create competition just publish a leaderboard and let peer pressure do the rest. People will work hard to be at the top of a public list even if there is no explicit reward for it. Just be a manager, manage the people, and use metrics that help you manage the people. You won't sell many consulting engagements that way tho.

richliss 3y ago

Having worked with McKinsey people, they will forever be Lyle Lanley for me... https://yewtu.be/watch?v=ZDOI0cq6GZM https://yewtu.be/watch?v=ZDOI0cq6GZM

deterministic 3y ago

Don’t measure productivity. Measure ROI (Return on Investment). You are running a business after all. Cashflow is king! Any productivity measure that isn’t derived from ROI is 100% guaranteed organic grass fed BS. Increasing “productivity” can actually reduce global ROI. I highly recommend looking into the Theory of Constraints.