My Response To The Nonsense McKinsey Article On Developer Productivity • Dave Farley • GOTO 2025

[@GOTO-]

Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: kzbin.info/door/s_tLP3AiwYKwdUHpltJPuAjoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇

[@tomtech1537]

A few criticism of the video; - DORA doesn't measure change or task complexity which productivity does attempt to capture so this is a bit misleading (you kinda identify this problem when looking at the matrix when discussing cake vs fcs) - Your position on having right engineering talent is binary, which is silly. Yes the things you've highlight are important but if you don't have the right talent they are meaningless (yes you could lump this under dependability/excellence, but you explicitly called that focussing on the talent doesn't matter) - You have to recognise that it is important to measure individuals which is for everyone's benefit (assuming you take active steps in your org to actually develop people), the metrics to get here are difficult but I don't think it's a bad idea in principle -- even if they are subjective this can be useful (I think we agree on the general idea here, but you seem to be shying away from searching for metrics) - Creating metrics for sales *is* much easier, you even identified the solution to the issue of selling crap for bonuses, which is widely implemented today (measuring the backend/profit not the frontend/rev. of the sale). Additionally large orgs even have clawback of bonuses if they sell something similar to what you've described. Yes it's a problem that still occurs, yes sales people are generally overcompensated, but no it's not hard to create individual performance metrics for purely sales (presales technical mixed roles is a lot harder, but not what is being discussed), yes it can create a toxic knifey culture where sales people fight over clients, so like with all metrics you need to think about what behaviour you are driving (on the flipside good luck getting a competent sales person without comms attached). - I somewhat disagree on satisfaction and retention being irrelevant, these are lagging indicators that you can use as a proxy for some of the other issues (eg: 'A' personality types will be riotess if they aren't being productive, if you see them unhappy you can figure out what's going on and work to unblock that)

[@ToddBurgess]

McKinsey doesn't have to implement any of their ideas or articles. They get paid lots of money to write business plans for companies they don't get to implement.

[@clownbaby420]

@@ToddBurgess that's not always true -- McKinsey had to implement that illegal bread price fixing scheme in Canada that time (Loblaw's)

[@centerfield6339]

@@ToddBurgess "a lot" is a massive underestimate.

[@darkehartplays]

The second paragraph of the report cites that ChatGPT can make developers "complete tasks twice as quickly." I immediately facepalmed. This is just marketing BS to MBAs who lack technical understanding but get profit-boners every time somebody mentions "AI." >.

[@logiciananimal]

"Complete" should be used as a success word, in which case this would be a brazen falsehood. Remember the joke about release cycles and being 190% done? :)

[@davidmartensson273]

AI can be helpful yes, to reduce time for boilerplace code for common structures and for junior developers that have a hard time formulating good questions to google, but AI cannot solve new problems and usually do not take into account local context requirements. Sure they are getting better by factoring in your existing code base, but that is only good if the current codebase already is good :) So to assume it will generally double the work done is just a pipe dream. And even the gains you can get require the devs to learn to use the tools in a good way and to understand where they fall short, or you will just be faster att adding bugs.

[@monocledmanatee6355]

Well, I certainly found myself with roughly twice amount of code with the AI "assistant" than without one. Only problem was, I had to repeatedly sift through it and delete everything that AI bastard generated. And oh boy, was it a busy little thing! One push of the spacebar would unleash a whole screen's worth of more or less syntactically correct code which will look at a glance almost identical to the code in our project. The problem was... it never ever generated anything that would actually be useful, just happily plopped code turds all over the place. But yeah, if we only count the number of lines of code produced (but not deletions!) that would be about twice as much. Useful code? Oh, maybe one third of the amount before the AI.

[@saiuan4562]

I want to emphasize that they wrote "can". They are technically not lying. Alot of things "can" happen. Is it likely? Probably not.

[@theman47145]

But it's true. You can complete tasks far faster with Chat GPT. If it works, that's just a nice little bonus.

[@donaldjohnson-y6n]

Measuring software development productivity is great if software developers are only tasked with software development, but I haven't found a place yet where that is truly their job.

[@NickKeighley]

What is their job then?

[@donaldjohnson-y6n]

@@NickKeighley internal user support

[@NickKeighley]

@@donaldjohnson-y6n where I worked the users were external. And it was embedded stuff. Not much support on a day to day basis

[@theman47145]

Measuring productivity is easy. Which people do you chose to fix the hard stuff? Which people does nobody want to work with. Done.

[@skitvandarken]

McKinsey is know for legitimizing any idea of business executives. Example: They help tobacco companies to grow their profits at the same time they help public health services to improve public healt.

[@centerfield6339]

This is probably the only bad argument against McKinsey. Companies can have multiple customers.

[@yewknight]

I can write a lot of bad code quickly and make all of the metrics about my productivity look fantastic. Writing code is almost measurable, but 90 percent of being a software engineer is not writing code. Investing more time in requirements and design is the mark of a mature engineer and those are difficult to impossible to capture in a metric.

[@LeeHawkinsPhoto]

Yes…asking better questions, getting better answers, and using that to inform design and testing and training…basically doing the things that take time from people doing their normal jobs to build software and make it successful is what companies and managers always fight against…and it’s the very thing that actually works.

[@belava82]

Every workplace where people are firmly financially forced to play games against the system's measurements will degrade, and eventually, you will see a number of conflicts between teams and individuals that are desperately trying to push financially non-beneficial work onto each other.

[@nreed7718]

You get more of what you incentivize.

[@PaulMcCannWebBuilder]

Goodhart's Law - Any incentive that turns into a target ceases to be a good incentive.

[@theman47145]

It's beneficial to the consultants as it sets them up for a lifetime of work.

[@henryvaneyk3769]

Never ever allow a management consultancy company tell you how to measure your productivity. They are not invested in the success of your company. As soon as they get their consultancy fee, your company are dead to them.

[@iAPX432]

I am also experienced since more than 4 decades, and I appreciate how all that is described. DORA is a great approach, imperfect but everything we all do is, we just try to not be too much imperfect! Note that the goal of McKinsey is *NOT* to improve productivity or value-per-dollar but to give tools to fire people, and they are really awesome on this task... Note also that a keystone doesn't support anything, so technically you'd better not add it to make economies.

[@LukePuplett]

Taylorist - he said it. Taylorism is anathema to software development. UK and Europe's relative stagnation since the web, then the iPhone, has been because we've needed new, non-Taylorist organisations to emerge and rise - and that has not happened, because: "The essence of American capitalism is to allow the rapid emergence of new companies, the essence of European capitalism is to do everything so that old companies do not die."-Jean Monnet

[@LeeHawkinsPhoto]

@@LukePuplett I would say that America has adopted the European model based on how big the monopolies have become and how nothing is done to foster competition.

[@ehjapsyar]

I work in academia and we have pretty much the same problem. Measuring productivity and evaluating workers based on objective metrics is a modern illness that just doesn't work for many domains. In software engineering it can be measuring performance by counting lines of codes or hours worked. In research, it's research papers written each year. A researcher writing 10 bad or useless papers per annum is much more harmful than a researcher producing 1 good paper every couple years, yet the former will be rated as being way better. Just like how a programmer writing heaps of bad code is actually harmful to a project. It most probably comes from trying to apply management concepts to contexts in which they are irrelevant, because management/counseling firms aim at increasing their revenue by conquering new markets. In other words, corporate greed. It is even more absurd with academia, since these are concepts brought by managers from the private sector who believe that public services are also supposed to make money (they are not). I am pretty sure that converting these managers to actual engineers, working without management, would be a much more efficient use of working hours overall than the current paradigm. But that would require trust and competency.

[@username7763]

I love your story about the negative consequences of how sales people are measured. It too is something I've often seen throughout my career. Sales people are put under enormous pressure to make sales. They respond to those incentives by making some absolutely terrible sales for the company. I've been on quite a number of projects where the sale was a massive loss for the company. I've also been grumpy but how much unpaid overtime I was pressured to put in to make up for it.

[@craigiedema1707]

I work as a consultant doing software delivery. My favourite joke is "Sales are the deliverers of promises, Consultants the deliverers of dissapointments". Dave, as always, is excellent at getting to important things in software development.

[@br3nto]

You’re possibly preaching to the choir. I realised a while back that the software development methodologies developed by software engineers, are not learned and therefore utilised by most managers because most managers come from a different educational stream which did not include software engineering, therefore, the style of management they apply is different. The answer is threefold: software engineers should manage software engineers; there should be a software engineering executive officer; and modern software engineer development philosophy/science needs to be widely taught/marketed to outcompete the traditional management style.

[@centerfield6339]

Then you'll still get people who use McKinsey being software engineering executives. Sounds like software engineers shouldn't structure companies.

[@gammalgris2497]

If I go "submarine mode" and work on something without telling my boss and I can show something useful later then no one is asking about hours spent or productivity...

[@username7763]

Measuring software engineer productivity is like measuring electrical engineering productivity by number of circuit board traces. Is the design good? Does it make appropriate tradeoffs with constraints? These are qualitative things.

[@monocledmanatee6355]

See, to understand it you need somebody who understands how those things - be it software development or manufacturing of LED lights - actually work. Instead you have either salespeople if you're lucky - those are ignorant, but usually things could be explained to them in small words and a lot of pictures. Showing them how it affects sales also helps tremendously - they won't become experts, but they'll learn enough to ask you for advice before implementing things, which really cuts down on the amount of misunderstandings, goof-ups and interdepartmental bad blood. With these, you have a decent chance to create some useful metrics that'll allow you to stay on track without dedicating most of your time to collecting the data for those metrics. Something simple, but useful. And then there are MBAs, who only know Business Administration. Those will be actively ignorant (that is, they'll actually unlearn things faster than you can explain it to them), won't understand anything except that The Curve Has To Go Up or The Numbers Must Be Increasing From Quarter To The Next Quarter. Implementing any sort of useful metrics with those is, in my experience, impossible. You either are in position where they can't get rid of you or you'd better look for a new job. Expect metrics about metrics about metrics and a lot of angry messaging about not updating The Spreadsheet Of Doom because of something laughable (like urgent last-moment shipment or ten).

[@nalle475]

As someone who spend 50+ years in management I must say “fantastic video”. I strongly believe and recommend measuring things the way you describe it. As a business owner or partner I needed that information to lead my organization to better results using facts not horoscopes. The role of any manager is that of a personal trainer not a beancounter. The one point I disagree on is the value of Customer satisfaction.

[@monocledmanatee6355]

Ah, but didn't he say that it IS a useful metric, but ONLY in context? And the customer's always wrong - we just won't ell it to them, as we used to say (meaning that our job was working with the customer to find out their actual needs and help them, not just catering to every whim), so instead of nebulous "satisfaction" something more narrow (and measurable!) should be used.

[@nalle475]

Customer satisfaction is really important and easy to measure. Basically we need to agree on the best solution and then deliver 100% what and when we promised. What ever a customer feels is what he is communicating to his peers, so best to get it right if you want to be in the business for a long time.

[@volkers-hamburg2390]

Love that T shirt 👍. Had to get the same and I’m wearing it proudly in office.

[@AbAb-th5qe]

Why should anyone care about a report made by a group unrelated to the field they're reporting on who have an incentive to make baseless assertions? Has anyone measured the effectiveness of these management consultant's recommendations when they are implemented? Or do they just go around killing companies with idiotic ones without any oversight or retrospectives?

[@jamesmorgan3623]

Unfortunately I think you are underestimating the influence McKinsey have.

[@LeeHawkinsPhoto]

They go around sucking the souls out of workers so that the bosses can abscond with them when the company dies.

[@1over137]

Developer satisfaction and retention are actually extremely important... when they manifest. I am in a team which is collapsing, there is no "software" knowledge in management which is a MSP / Conslutancy. They really don't know what they are doing and it's just getting worse and worse. Satisfaction and retention. Unsatisified developers are "down". They are not pro-active and engaging. They basically "quiet quit" until people start giving them work that can be done and is ready to be done. If developers leave then they leave with knowledge the team needs. If a critical mass of developers leave and the project does not have 100% complete documentation... then basically everyone has to re-learn everything all over again.

[@nreed7718]

Let me guess, number of commits and lines of code. 😅 IMO these kinds of metrics are useful for providing a pretense for PIP's and layoffs.

[@benjaminsimon915]

I'm not the first one to mention this, but I'll phrase my thoughts nonetheless: This is just marketing on McKinsey's part. The industry is not in the best place right now. Companies are downsizing left and right. Managers are people, they don't like being responsible for someone losing their livelihood, so there is demand for "objective" and preferably simple tools to base their decisions upon. I mean it's not a new thing, but I imagine demand has sky-rocketed for these "measurement frameworks", so it makes sense that these BS ideas are jumping up more frequently. Consultancy firms are just eager to meet the demand.

[@RomanGaleev]

I'd rather start by defining developer productivity first.

[@RomanGaleev]

@gppsoftware yeah, and they will continue trying, as there is a noticeable difference in outcome, they just fail to capture it.

[@netssrmrz]

@@RomanGaleev agreed. I wonder if an easier starting point might be attempting to determine the productivity of particular tools (given a similar set of devs).

[@RomanGaleev]

@@netssrmrz well, that's easier, developers are way more productive with IDE (compared to, say, WordPad). The difference between IDEs is not that obvious, though.

[@netssrmrz]

@@RomanGaleev I'd love to see results for frontend frameworks, ORMs, databases, CSS frameworks, etc.

[@monocledmanatee6355]

I'd rather start by defining the _beancounters'_ productivity first. Or productivity of those people creating these reports.

[@cgintrallying]

Thank you for this comprehensive and IMOVIE management friendly summarization of the topic

[@rudygasson2836]

The sound is really bad in this video. Please check your mic setup and record room reverb.

[@Tony-dp1rl]

I don't always agree with Dave Farley and some of the CI selling points, but in this case, I think he is exactly correct.

[@vectorhacker-r2]

@@Tony-dp1rl Hes always correct

[@robertluong3024]

​@@vectorhacker-r2he most definitely is not and I doubt he'd even say that

[@vectorhacker-r2]

@@robertluong3024 he is an infalible god!

[@HellZtar]

I worked in management for a relatively small company ( 30 - 60 devs). I tried to figure out the value the developers contributed to sales, customer success and marketing. My goal was to figure the right measure for the team and individuals. This was a journey into me figuring out that the company business model was not viable. If your codeing, devops or platform efforts do not affect others in either a positive or negative way. Pivot or get out

[@username7763]

My feeling is that if find you need to do this, there is no way to not fail. Whatever you come up with be horribly flawed. And then you'll have a flawed measurement system that your employees will be judged by or try to follow. You start out with a mistaken goal, that employee's contributions are measurable in knowledge work and just make it worse. Can you measure your management contributions? How many sales were made because someone came up with a gantt chart?

[@HellZtar]

@@username7763 i do not agree entirely. Understanding individual and team motivation in result-oriented work environments requires recognizing the three fundamental axes of Why, What, and How. Team members are typically driven by different aspects: some find their motivation in understanding the deeper purpose behind their tasks (the Why), others are energized by the specific objectives they need to accomplish (the What), while certain individuals thrive on the technical execution and problem-solving aspects (the How). As a leader, identifying and aligning these motivational drivers within your team becomes crucial for success. This understanding must then be connected to business outcomes, such as how addressing technical debt or fixing bugs directly impacts customer churn rates or net revenue retention (NRR). This alignment between team motivation and business metrics is essential because without clear connections between technical work and business value, the fundamental purpose of development tasks, maintenance work, or feature implementation becomes questionable. If these relationships are difficult to establish or appear illogical, it might indicate deeper structural issues within the business model itself (hence pivot or get out), suggesting a need to reevaluate the organization’s core assumptions and strategies.

[@HellZtar]

@@username7763 i do not agree entirely. "Can you measure your management contributions?"... yes.,. you can. If you are able to connect the real purpose of the team you are managing. If it is not, you could rather paint pictures/make gantt charts every day at work.

[@username7763]

@@HellZtar That's measuring how well your team does their work. How do you measure how well you do your work? How well do you resolve employee conflict, communicate priorities, coach, discipline, coordinate and so on. It doesn't get measured -- for good reason. It gets assessed but not measured. Most of engineering work also is like this.

[@camgere]

Now that you have knocked off measuring the productivity of software engineers, you can measure the productivity of university professors.

[@tttm99]

8:34 😂 I think I know that salesman. I think we all think we know that salesman... Or a salesperson like him. For me it was someone selling a particular kind of contract time - ongoing - for a 100 percent loss because they forgot a variable, didn't ask, and didn't care. Suddenly sales metrics weren't so popular anymore. It turned out executives did care about profitability...

[@svnblm]

McKinsey is looking for Luigi to give them "United Healthcare" special !! 😁

[@piotrd.4850]

Like McKinsey is authority on the subject. Or any other, for that matter. I happen to work for company that does work for company consulted by McKinsey. The mess we have to contend with....

[@monocledmanatee6355]

They're an authority on the subject of excuses for firing people, I guess. So instead of "I don't like your face!" a better excuse ("Blah-blah-blah productivity blah blah synergy blah blah derpity derp metrics!") could be used.

[@BenjaminScherrey]

Yeah is this is an amazingly irresponsible report from the ultimate consulting group. Clearly they're reacting to the long held desire of bad managers (the kind who hire McKinsey for CYA value) who have always wanted to be able to measure individuals and can't manage people if they don't see them at their desk at assigned times. (I'm 100% for onsite work btw but for different reasons.) Good to see this called out so well.

[@brownhorsesoftware3605]

The work of writing software is not coding, it is making the code (that you or someone else wrote) work.

[@sciencedaemon]

Half a dozen of one, six of the other. You are sort of creating a strawman argument. To code is to make it work, eventually. Just making code work is not necessarily WRITING software.

[@brownhorsesoftware3605]

@@sciencedaemon Tell that to the people promoting AI.

[@brownhorsesoftware3605]

When you are writing code, the work is in getting it to work, not typing it in. That is my point. Also, when you are writing code you need to make it work with code written by other people.

[@brownhorsesoftware3605]

@@sciencedaemon Also, I get my code working right away. Not eventually.

[@sciencedaemon]

@@brownhorsesoftware3605 stawman argument to escape facts. As if every piece of code you ever wrote is made to work immediately. So after 1 second, 1 millisecond, your code is working. You are just telling me you are a liar.

[@ZapOKill]

The MBA is the natural enemy of the software engineer.

[@Q966aZxEWzmKLc8zBfMB]

The MBA is the enemy of everybody. It's a parasite who exists to extract rent without contributing actual value, but vague promises of covering one's ass.

[@karlgustav9960]

You can argue that success does not depend on the right people. I also think that Brooks has a point, and I cite from the Mythical Man Month almost every day (Brooks’s Law, Conway’s Law and most of all “No silver Bullet”) but I think the right “Talent” is important. 9 Women can not produce 1 baby in one month, but 9 man can’t pull it off either. But one man and 9 women can perhaps produce 9 baby’s in 9 months? ;-) 😂 no seriously, if you hire a team of junior software developers to build a scalable ERP system, it’s not gonna happen, they will need to learn software development for years and that will cost the bulk of the projects funding without any useful output.

[@andyevans2000]

I disagree that a rockstar developer is a myth. On every software project 10% of the developers do 75% of the work and 90% of the difficult work. Normally it's 1 or 2 developers carrying the whole team.

[@FaustBusserl]

@@andyevans2000 I think the point of the video is that all these projects would fare better if they distributed or organized the work better. Nobody said that good developers do not contribute to the project.

[@nigelmagnay1453]

I think it's less so much the existence, and more the recognition that it alone is not the only factor driving success. Overall team structure, done well, allows the brilliant to get on with _being_ brilliant. Consider that great artists had assistants. Much of the Sistine Chapel's backgrounds were done by Michaelangelo's assisntants. Damian Hirst employs over 100.

[@schoolstuff5235]

On all the projects I’ve worked on, the developers with the most experience were responsible for making sure the project succeeded. They wound up developing most of the prototype before presenting it to the team. As soon as the ‘business’ found out that a working solution existed, it became the solution. Why spend more time on something that’s basically done - that was the mentality. New grad’s, or employees be damned. My point is that your statement leaves a lot to be desired.

[@andyevans2000]

The point is that Damian Hirst or Michaelangelo could still do what they do /did on their own, it would just take longer. If they weren't there it would not have happened at all. Yes you can reorganise dev teams and a common result is that your top devs spend most of their time helping other people, either through peer reviews, pair programming or documenting every task in minute detail so a junior can do it. In short, variations on the theme of a small group of people carrying a team but giving the appearance that the weaker members are contributing or are 'skilling up'.

[@schoolstuff5235]

@@andyevans2000 I get your point, but not your reasoning. Isn’t the point to create more competent developers? This only happens when the more experienced developers guide the inexperienced. What am I missing? Top developers are paid more because they have more knowledge and experience. Technology is the only industry I’ve ever worked in where the top people aren’t required to build others to their level. I did what I could because it felt right, not because it was mandated. This selfish attitude doesn’t exist in hospitality, nor in construction, and certainly not the military. The ‘rockstar’ crap is narrative driven and mostly inaccurate. Sorry, I know better. Also, who has the ability to do anything without some instruction? No one is an island unto themselves, absolutely no one. Everyone learns from someone or something, even Michelangelo.

[@yohananromem3178]

Lead time is unmeasurable like “developer capacity” or whatever… Usually lead time is measured from start of development to deployment but as unit of work is not measurable, it becomes useless, like comparing m/s and f/s And when we try to approximate the work size by something something like story points it will degrade very fast to the time it takes i.e. gaming the system I’m not sure, as engineers, that we try to measure the right thing, we should measure the quality of the software and not the team/org

[@Q966aZxEWzmKLc8zBfMB]

Are we chefs or are we burger flippers? Are we artisans or assembly line workers? Are artists or just a pair of hands to paint by numbers? It's something for engineers to think as well. So many practices in the last decade have pushed us more towards the latter in all of these examples. When we presume our fellow devs to be so stupid that they can't use for-loops, that they are not even smart enough to place linebreaks at the right location, then _we_ proclaim ourselves as assembly line workers bound by a script and devoid of agency or creativity. Bring back the "art" in engineering arts or get replaced by stochastic parrots.

[@gregsimoes8645]

If businesses want to measure developers like factory workers then ALL project assessment and definition work should be on project managers and then you can measure developers purely on production. (terrible idea btw) If developers have CLEAR and accurate "build X unit of work" directions then you can assess their work on how many X they built. But most developer work is "solve Y problem" and Y may be incredibly vague and subject to multiple changes before the work is done. Figuring out what Y is, IS the bulk of developer work. If managers want to improve developer efficiency, they should START with "how clear are the requirements given to developers". If developers need to get and refine the requirements themselves, then you need to figure out areas of excellence. One developer might be a slower/worse coder, but incredible at interpreting customer needs. Another might be a rockstar at coding, but awful at reading what the customer wants. Both of these might be equal if you just look at output, but your business would likely be MUCH better served if each was focusing what they are good at.

[@tomtech1537]

I can confidently assert that management consultants have absolutely no idea about productivity (take a pretty dim view of them in general). But I will trot out a recent example of multiple McKinsey alumni attempting to use tools like Flow to measure lines of code (LOC) as a productivity output (org size 3000+engineers). I would go further and say that I'm *extremely* dubious on anyone that can claim they know what productivity is when it comes to delivering software. LOC is the lowest quality smooth brained idea that everyone thinks of when they first start thinking about productivity, but anyone that is *remotely* seasoned knows how much of a terrible metric this is and what poor behaviour this drives. I don't think I could have come up with a more destructive policy and metric than what these absolute midwits came up with (who invariably claim success of millions of dollars saved before the idea is even implemented). One of the few good things that I think generative AI will produce is that it vastly democratises access to synthesized hot air telling executives that their ideas are great, which is going to drive management consultancies into the ground and the world will be better for it.

[@marcotroster8247]

Why would you measure productivity though? It's pointless when you trust your workforce.

[@marcotroster8247]

@gppsoftware When the market research is properly done, that market usually returns 10-100x of the development costs. So if the product is successful, it'll make a lot more money than it costs anyways. There's no information gain in measuring how much it actually costs. Why do software managers always measure the wrong things? There's very clear research on what determines a product's success. The most important factors are whether the product ships at all and whether it finds an active userbase. Those are the important things to focus on.

[@marcotroster8247]

@@gppsoftware Projects are per definition a one-time endeavor with very specific goals and conditions. If projects aren't different, you're writing the same software over and over again which is in fact... a production line... Well... 😅😂 I mean you can't fix such companies unless the culture massively changes. Jez Humble did a couple of very interesting speeches on agile product management and agile budgeting. Maybe you'll enjoy.

[@monocledmanatee6355]

So that you can decimate the workforce, obviously. Fire 10% with the lowest scores on some arbitrary scale quarterly, increase Shareholder Value and get fat bonuses for Effectiveness. Has nothing to do with the actual product or anything. May help with scaring people into unpaid overtime, accepting crappy workplace conditions. Also weed out the troublemakers. Trusting employees requires that they trust the company, too. Building trust requires effort. Trust doesn't send the share price up. And trusting any company right now farther than you can throw them is plain stupid, IMO.

[@monocledmanatee6355]

@@gppsoftware I worked in manufacturing. The matrix they propose won't work for the assembly line either - there's a ton of variables involved.

[@marcotroster8247]

@monocledmanatee6355 In Europe you can't fire someone at all unless you close the entire department for serious economic reasons or the person did something severely wrong like stealing or refusing to work or not appearing at work without giving a reason. And there are courts that enforce the worker rights such that companies wouldn't even try anything like *hire and fire". Maybe you need to come to Europe.

[@gmirsky1962]

Again McKinsey totally misses the mark. The root cause is the lack of ROI measures of the business area asks not developer productivity. I speak from 40+ years in IT. Look at any software system and you'll find plenty of niche or vanity features requested by the business that return little of no value. Those features used by one person at one important client (who probably isn't there anymore) or by someone in the business to justify their existence in the org chart. (I implemented this feature.., blah, blah, blah!) Even Google who created DORA is a poster child for this with having a web site like Killed by Google that documents how dubious software was developed or acquired only to be cut because their ROI was minimal at best or just a plain resource suck. These dead products were developed or acquired without a proper ROI review by the same business areas who think software is salvation. (Let's not go down the rabbit hole that some of these products were acquired in a package deal and then cut loose.) I'm sure many will disagree but I speak from experience as an employee and consultant for dozens of companies.

[@OneFanHere]

Goto audio quality is constantly shit.

[@JohnHall]

Bring in McKinsey to determine why.

[@RowanGontier]

I feel that the line of thinking of McKinsey, while it may have kinks, is more likely to fit the future of organisational metrics, than no metrics at all. We know that capitalism is better than communism, but it has flaws. I have worked on teams where there are no other measures than team velocity, and wow there were some slack contributors who only had to rock up and attend ceremonies. I feel that 30 years ago, the argument could be made that you shouldn't measure rugby players individually, because it is a team sport. Well, look at American football and how they rely on player metrics, and how it offers objective evidence of player outputs. It seems that there is no turning back. Are software developers so special that they cannot possibly be measured, at a team or individual level? What I see for example is that teams simply adapt to the current velocity, and because there is no relative benchmark, they can merrily continue doing what they are doing- even if the codebase is shoddy and really ought to be revamped. I don't believe in any single measure, but I do believe in transparency on multiple measures. If on multiple measures, there is total lack of outputs, that might tell you something over and above the pleasantries in standups. Wrong explicit measures are not the only "dangerous" thing. If you don't provide any measures, people use their own measures tacitly, which can be dangerous also. Even if there are few JIRA ways to measure productivity, I'd be happy with 360 qualitative feedback, asking reviewers questions like "does software dev A use quality processes, demonstrate commitment, have good knowledge of their domain" etc.

[@username7763]

Everyone has different development experiences but I've seen far more harm from bad metrics than no metrics at all. The most important things in life are qualitative and not quantitative. This is why we hire senior engineers and managers. Because they can make judgement calls from their career experience. If managing people and projects could just be measured and just pick the higher number, we could have high-schoolers doing the managing instead. No, it takes a lifetime of learning. I don't think the sports analogy makes sense. Software development is a design activity. What we do is the opposite of mechanical and rule-based. If a software developer was tasked with rugby, he'd design a conveyor belt for increasing ball movement throughput. It is unreliable to depend on a player to move it. Very different kinds of tasks, often require different management techniques.

[@RowanGontier]

@@username7763 remember when Elon Musk came to twitter and through interviews, he sussed out who the poor contributors were, and terminated them? These interviews gave a kind of measure. And there are many other kinds of measures that can offer actionable insights. The age of gut feel is passing. Your assertion that a rugby player would design for ball movement throughout is arrogant. The current CEO of a major listed company in Australia was an Olympic rower, and it is wildly successful, and he does not think in timed straight line sprints.

[@NickKeighley]

I wrote a terrible review of the book. It lacks practical advice. Very little engineering. I gave it 1 *

[@vanlepthien6768]

I'm sure "thinking" is a non-productive activity.

[@askholia]

The article smells of lonely, mid-level management. McKinsey is vibe based, not quantifiable metrics.

[@alexander_herold]

Isn't this just the same video as on Dave Farley's channel just with worse audio?

[@MichaelAuerswald]

A little constructive criticism: having moving backgrounds throughout the video will negatively impact video size and quality since much if not most of the bitrate will be used to compress those moving frames rather than what's important. It's also somewhat distracting, tbh...

[@hobster07]

What a grifter

[@TheRealisticNihilist]

The mic quality makes this unwatchable

[@priapushk996]

For a guy who hates McKinsey, he sure knows how to give a content-free McKinsey presentation.

[@TomaszRykala]

The 9 woman analogy is terrible because there is a bottleneck of 1 womb, whereas you can scale your engineers' tooling, depending on what it is.

[@MohamedSamyAlRabbani]

I don't think the article is harmful and neither is the rockstar developer a myth. In fact there are people who are a hundred times more productive and useful than others. All team sports have individual metrics for players, and you can measure an individual's contribution and it is useful. I have seen people who contribute significantly to projects and others who are basically dead weights and everything in between. The idea that you vcan contribute n hidden ways, so it is not measurable is ridiculous and there is no harm in measurement. I suspect the idea of not measuring individuals comes from a social marxism ideology rather than true facts. Think of Agile, where are the measurements of SCRUM, it all becomes subjective, but in reality most projects are still late and over budget. Story points are another invention that leads to a lot of confusion because they aren't really a measure of anything, just subjective numbers.

[@wizaaeed]

Why are you comparing normal working engineers with "dead weights", if somebody cannot do his job, he's simply not fit for it, but thats in every industry. Here we're speaking about trying to constantly compare the performance of normal working Engineers, which is total bollocks, this is development, research & invention, not a manufacturing pipeline. You cannot constantly throw Agile & Scrum words at people thinking you'll fix anything, meanwhile it's completely workin ok. This is like the smart watch problem, where if you have your heartbeat measuremed in real time, you're constantly looking & stressing over it....

[@mikkurogue]

I think the article isnt necessarily harmful, nor is it harmless. It will allow for dimwitted middle management to seek metrics to track so they can look good. Rockstar developers, in my eyes, are just talented developers. In the current day and age, developers no longer learn programming, but they learn a framework. Look at the frontend side of things, its all become so extremely complex due to frameworks and meta frameworks built on top of that, people argue about "best practices" but have never learn to write and understand just pure vanilla javascript. They learn Nextjs, or Angular, or React because thats the complexity spiral the industry has fallen into. Even the backend is area is starting to suffer in the same way, especially for startups that just make basic CRUD apps (which is like a vast majority of them) where they use javascript on the server running express or Nest.js (another meta framework ontop of express) but have no clue about the intrinsic use of the language they decided to use. the industry nowadays is just an amalgamation of terrible hacks that somehow have no become "best practices" and non technical middle management thinking they can contribute in a meaningful way to the technical aspect of things, especially with the use of "AI" nowadays.

[@MohamedSamyAlRabbani]

@@mikkurogue The dimwitts are always doing what dimwitts do, what upsets me is this attempt to bring more psuedo science like psychology and sociology and politics into computer science and make things fuzzy where they are not. Harmful is subjective word, lets think like engineer and measure and use Physics units not story points.

[@br3nto]

@@MohamedSamyAlRabbani what’s the measure? It’s definitely not lines of code, or even number of features. There are people who write tonnes and tonnes of code and features, and sure it might work, but it’s an unmaintainable ball of mud that no one else likes to touch because it’s brittle and breaks for unrelated changes.

[@MohamedSamyAlRabbani]

@@br3nto not lines of code, or number of featurs because you can't measure code and features by objective metrics, but certainly there are huge gaps between developers in skills and work ethic. Not all developers were created equal or even work and provide the same value. SCRUM and Agile are turning it into a high school popularity contest and team sport like basketball when it isn't, you need to collaborate then you need to work alone to be productive, but you can't be communicating and coding anything of value at the same time. They have to happen seperately. Also, developers who are good at automation are way more productive than those who spend entire sprints copying and pasting.