Ex-Finance developers mock McKinsey's monitoring metrics(efinancialcareers.com)
efinancialcareers.com
Ex-Finance developers mock McKinsey's monitoring metrics
https://www.efinancialcareers.com/news/2023/09/mckinsey-how-to-measure-software-developer-productivity
81 comments
> It's a sort of clueless MBA thinking that believes software engineers should be furiously typing all the time
(Your point is good, but the dig against MBAs is unnecessary and I wish it was less acceptable here on HN. It wouldn't be ok to make fun of people with Sociology degrees or History degrees here, but jokes about MBAs get a pass. We really should be better than that, but I realize I'm swimming against the current on this one.)
That aside, I have found a lot of clueless folks in tech leadership have that "furiously typing" misconception, as if developers are only productive when their fingertips are pounding keys. I once worked with a CEO who refused to set aside time in the schedule for things like setting up source control and a bug tracker, because he believed that developers should be furiously typing code in at all times.
(Your point is good, but the dig against MBAs is unnecessary and I wish it was less acceptable here on HN. It wouldn't be ok to make fun of people with Sociology degrees or History degrees here, but jokes about MBAs get a pass. We really should be better than that, but I realize I'm swimming against the current on this one.)
That aside, I have found a lot of clueless folks in tech leadership have that "furiously typing" misconception, as if developers are only productive when their fingertips are pounding keys. I once worked with a CEO who refused to set aside time in the schedule for things like setting up source control and a bug tracker, because he believed that developers should be furiously typing code in at all times.
What is the problem with criticism "mba thinking"? It's a legit complaint against the kind of naive "efficiency" analyses and measures that happen, and is completely justified. I have an MBA, I certainly don't find it offensive, I think the criticism is apt.
The usual art student tropes are more offensive because they are about people in a chosen degree being dumb (incidentally, when I did engineering all the hardcore "haha artsies are so dumb" engineers failed out after first year). That's not the same as criticizing a specific flaw in their education. If there's some big blind spot the average sociology degree leaves, that should be fair game.
The usual art student tropes are more offensive because they are about people in a chosen degree being dumb (incidentally, when I did engineering all the hardcore "haha artsies are so dumb" engineers failed out after first year). That's not the same as criticizing a specific flaw in their education. If there's some big blind spot the average sociology degree leaves, that should be fair game.
I'm a software dev with an MBA, and yes, my classmates were very much "our job as managers is to make the minions work harder" [0] so I'm equally OK with the MBA slur.
I struggle trying to educate people that the best way of measuring developer productivity is measuring outcomes, and that a developer going for a walk in the park is a great thing for them to do.
[0] In Australia, where management is generally still locked into 1950's-style authoritarianism. YMMV.
I struggle trying to educate people that the best way of measuring developer productivity is measuring outcomes, and that a developer going for a walk in the park is a great thing for them to do.
[0] In Australia, where management is generally still locked into 1950's-style authoritarianism. YMMV.
It’s such a hilarious misdirection, that mentality. Finding ways for every employee to work less is the definition of efficiency and profit.
MBA programs have (generally) moved past Taylorism. Apparently McKinsey not so much.
How is that being better? There’s a pattern of management coming out of business schools that’s clearly not working because at the end of the day, you have managers trying to micro not macro manage highly skilled workers working in areas they don’t understand well. The result is hilarious. We’re supposed to suppress that? To be better? Is laughing bad now?
> the dig against MBAs is unnecessary
You're right. Ironically, I've seriously considered getting an MBA myself.
I changed it to "management-consultant thinking," which feels much more fair, given we are ripping on a McKinsey article in the first place. :) Thanks for the note.
You're right. Ironically, I've seriously considered getting an MBA myself.
I changed it to "management-consultant thinking," which feels much more fair, given we are ripping on a McKinsey article in the first place. :) Thanks for the note.
History and sociology are respectable academic disciplines.
My respect in fields is directly proportional to relevant maths used.
How do physics and math stack against each other?
Lately physics has been providing seed ideas for mathematicians to explore them rigorously. e.g. mirror symmetry and amplituhedron.
I’ll join the current with you. I have an MBA. I write code. It’s an unfair trope. I understand the stereotype I guess I just haven’t experienced it so yeah..but I understand the vitriol against McKinsey in particular.
I'd agree with that. I mean (usually?) most people are referring to the person straight from high school to college to MBA to management/executive/consultant without having worked a day in their life, but still.
Does grate on me, though I might be biased, having worked 20 years in IT progressing upwards, and now looking at an MBA to round out my formal business education for further advancement.
Does grate on me, though I might be biased, having worked 20 years in IT progressing upwards, and now looking at an MBA to round out my formal business education for further advancement.
Seems like criticism to "clueless MBA thinking" in the software engineering context.
99% of MBA's are certainly clueless about SWE because they never did SWE professionally.
It didn't seem to me like a criticism of MBA's fundamentally speaking.
99% of MBA's are certainly clueless about SWE because they never did SWE professionally.
It didn't seem to me like a criticism of MBA's fundamentally speaking.
> 99% of MBA's are certainly clueless about SWE because they never did SWE professionally
Anecdotally, most of the MBAs I know are former coders. The last decade of Silicon Valley thinking it can reinvent commerce from first principles has massively increased the value and leverage of former coders with MBAs.
Anecdotally, most of the MBAs I know are former coders. The last decade of Silicon Valley thinking it can reinvent commerce from first principles has massively increased the value and leverage of former coders with MBAs.
Anecdotally, I worked with several brilliant engineers who have MBAs. Folks who are extremely technical and can go deep in their fields of expertise, yet they see the bigger picture in terms of business outcomes, and have tools in their toolbox to navigate ambiguity, mitigate escalating complexity, influence senior stakeholders (technical or not), etc.
Of course an MBA is not the only way of acquiring those skills, but it is certainly an effective way. It can be incredibly powerful to someone with already strong technical skills. So I'd agree with OP that this trope is unwarranted and out of touch with reality.
edit: I like OP's edit, replacing "MBA" with "management-consulting thinking". Lots of old school consulting companies come up with recommendations for areas that they have no domain expertise. While it may look good on paper, it's a recipe for disaster, like the original article describes.
Of course an MBA is not the only way of acquiring those skills, but it is certainly an effective way. It can be incredibly powerful to someone with already strong technical skills. So I'd agree with OP that this trope is unwarranted and out of touch with reality.
edit: I like OP's edit, replacing "MBA" with "management-consulting thinking". Lots of old school consulting companies come up with recommendations for areas that they have no domain expertise. While it may look good on paper, it's a recipe for disaster, like the original article describes.
If sociology or history degrees doled out management positions the way MBAs somehow do I guarantee you they would be met with derision. It’s like making fun of politicians, it happens because they are often inappropriately given power.
entirely fails to understand that actual software engineering is about solving business problems
The irredeemable cynic might wonder if this is because they see themselves as the only ones who should be solving business problems.
The irredeemable cynic might wonder if this is because they see themselves as the only ones who should be solving business problems.
Which is funny, because they aren’t very good at it.
> In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.
Interestingly this is my distaste when I read pro remote-work posts about undisturbed focused time to do "the work".
I'm not saying it is intended or correct, but it is the implication I take from it, and I feel it undersells what engineers do
Interestingly this is my distaste when I read pro remote-work posts about undisturbed focused time to do "the work".
I'm not saying it is intended or correct, but it is the implication I take from it, and I feel it undersells what engineers do
There is a time and a place for every purpose. Unfortunately, on site work conditions usually add a lot of friction to getting focused work done. Being potentially more optimal for collaboration work does not make up for this.
So, yes, you may hear about the sudden ability of people to get work done at a level they could not do when on site, and so they are happy about this aspect of remote.
It's been a couple of years since we went remote with our teams, and it has been a very positive experience for both collaboration and focus. We found that collaboration worked a lot better when it was actually intentional. It made the result of the collaboration more high value and strategic.
If you are depending on people accidentally bumping into one another for collaboration to occur, then you are being very poorly led.
So, yes, you may hear about the sudden ability of people to get work done at a level they could not do when on site, and so they are happy about this aspect of remote.
It's been a couple of years since we went remote with our teams, and it has been a very positive experience for both collaboration and focus. We found that collaboration worked a lot better when it was actually intentional. It made the result of the collaboration more high value and strategic.
If you are depending on people accidentally bumping into one another for collaboration to occur, then you are being very poorly led.
[deleted]
[deleted]
Relatedly I have always pondered the value of most consultancy work from the big firms. Maybe this is an unfair attack but it always felt like lots of PowerPoints and not much substance. I can see bringing a consultant in that specializes in maybe a specific manufacturing process or some other type of physical process but have always had trouble seeing the value in the other type of process change consultancy.
[deleted]
> it entirely fails to understand that actual software engineering is about solving business problems
So do most HN discussions about this. Look at how many people will say, “I’d rather be coding than in this meeting…”
So do most HN discussions about this. Look at how many people will say, “I’d rather be coding than in this meeting…”
I wonder if McKinsey just skipped over the part where they hired/assigned specific people for design, inter-team coordination and code monkeying or if they actually decided that "design sessions or managing interdependencies across teams" should not be done.
And maybe the corporate $$$ optimization means real technology company will avoid this.
And maybe the corporate $$$ optimization means real technology company will avoid this.
Charitably, I guess they might've meant something different with that quote (say, they were referring to people who were only good at coding, and the roles for design and cross-team coordination were covered better by different people).
But they keep coming across poorly on that metrics project.
I'm imagining their clients optimizing their operations, by bringing in management consultants, to tell them that the earlier management consultants need to be enabled to do what they do best: stay the heck away from sabotaging software development organizations.
But they keep coming across poorly on that metrics project.
I'm imagining their clients optimizing their operations, by bringing in management consultants, to tell them that the earlier management consultants need to be enabled to do what they do best: stay the heck away from sabotaging software development organizations.
Anytime I manage I refuse to track dev productivity individually. Its all about how much functionality (complexity points) gets net accepted in prod per unit of time from the whole team.
If you measure at the team level you get collaboration and much better solutions. It's a friendlier and more rewarding way to work with little turnover. It encourages product, dev and QA to work together and solve user problems in economical ways, not just throw solutions over the fence to the next stage.
And yeah sure I know if there's someone not performing up to their pay rate, you don't need numbers for that, you need to be involved and looking at their code.
If you measure at the team level you get collaboration and much better solutions. It's a friendlier and more rewarding way to work with little turnover. It encourages product, dev and QA to work together and solve user problems in economical ways, not just throw solutions over the fence to the next stage.
And yeah sure I know if there's someone not performing up to their pay rate, you don't need numbers for that, you need to be involved and looking at their code.
This is the best way I've found to manage a high performing engineering team.
You do need to be extremely attuned to the development process, and like you said, read everyone's code. But it is absolutely worth the effort.
You do need to be extremely attuned to the development process, and like you said, read everyone's code. But it is absolutely worth the effort.
> looking at their code.
I can't imagine many development managers do that. And even if they did, I'm not convinced that many would make a good assessment that way.
Most of the managers I've had over my career have been poor coders. I'd hate to have them judging me by their conception of what good code is.
EDIT: I guess many people have had better managers than I've had. So my "most" and "many" may be off base.
I can't imagine many development managers do that. And even if they did, I'm not convinced that many would make a good assessment that way.
Most of the managers I've had over my career have been poor coders. I'd hate to have them judging me by their conception of what good code is.
EDIT: I guess many people have had better managers than I've had. So my "most" and "many" may be off base.
> I can't imagine many development managers do that.
Wow, just a reminder that everyone's experience is unique and can't always be generalized. My first thought was "I can't imagine a development manager not doing that."
Seriously, I feel for you. Essentially all of the engineering managers I've had at one point or another have been coders. Some were well, well out of practice by the time they were my manager, and as I moved up in my career my managers were less interested in the details of my code, but I could always talk with them about highly technical concepts. I really feel bad for folks who think their engineering managers can't judge good code. And as someone who's also been an eng manager, I can't imagine managing devs without having an understanding of good code.
Wow, just a reminder that everyone's experience is unique and can't always be generalized. My first thought was "I can't imagine a development manager not doing that."
Seriously, I feel for you. Essentially all of the engineering managers I've had at one point or another have been coders. Some were well, well out of practice by the time they were my manager, and as I moved up in my career my managers were less interested in the details of my code, but I could always talk with them about highly technical concepts. I really feel bad for folks who think their engineering managers can't judge good code. And as someone who's also been an eng manager, I can't imagine managing devs without having an understanding of good code.
I admit it; my experience is my own and I'm happy to find out that other people have had better management than I have.
And you're right that it's absurd to try to judge developers without an understanding of good code. I just figured the world is absurd.
And you're right that it's absurd to try to judge developers without an understanding of good code. I just figured the world is absurd.
Counting myself as fortunate that I can git-blame and find my managers' (admittedly often old commit) name in the code base :-).
Fair point!
Well do you think someone managing development shouldn't know how to code? How would they hire? I've never worked on teams where dev is larger than six and I've always coded though. Bigger than six is automatically create another team in my books.
Sadly, it's very common. They typically ask one of the more senior engineers to assist with hiring. Earlier in my career, the managers knew how to code. Last 10 years... not so much.
When I'm managing a dev team, I enjoy reviewing my team's code at least 3/5 of days every week. Otherwise how can I give them sincere feedback and ensure we aren't doing weird stuff?
How many managers have you had? Seems like an odd generalization.
IMO, you can take the dev word out, many productivity metrics are of dubious value, because corporate people love applying structures and systems to problems, only due to the fact that it is a structure rather than any inherent benefit.
Person A might need a completely different style of management/metrics than Person B, and Person A after a year might need yet another style of management/metrics. Its all messy and ad-hoc, because such are humans.
(Not a perfect analogy) If you replace humans with processors, and work with code, its the same efficiency paradox that devs know all too well. You apply an abstraction to solve a design problem, even if you already are aware that the Good™ solution is a hardware specific optimization or a new API design just to solve that one problem. Abstractions are seen as seemingly scalable, give you flexibility and leverage in other ways so they are Better™.
Performance focused devs are the complete opposite they give you maximum efficiency, by have a near-perfect match with the code>compiler>hardware. But at the significant cost of increased dev timelines, code complexity, stress, etc. The manager equivalent here would be the same where they are able to match their own style to the specific person they're managing. But these styles are impossible to create a universal system around.
Person A might need a completely different style of management/metrics than Person B, and Person A after a year might need yet another style of management/metrics. Its all messy and ad-hoc, because such are humans.
(Not a perfect analogy) If you replace humans with processors, and work with code, its the same efficiency paradox that devs know all too well. You apply an abstraction to solve a design problem, even if you already are aware that the Good™ solution is a hardware specific optimization or a new API design just to solve that one problem. Abstractions are seen as seemingly scalable, give you flexibility and leverage in other ways so they are Better™.
Performance focused devs are the complete opposite they give you maximum efficiency, by have a near-perfect match with the code>compiler>hardware. But at the significant cost of increased dev timelines, code complexity, stress, etc. The manager equivalent here would be the same where they are able to match their own style to the specific person they're managing. But these styles are impossible to create a universal system around.
> Kent Beck, ex-fellow at payroll infrastructure fintech Gusto ...
Really weird way to introduce Kent Beck
Really weird way to introduce Kent Beck
"set a goal to merge a pull request every day."
This is just another version of making sure your developers are typing.
The most valuable feature I've seen implemented in a real commercial product took months to research and design. Merging a pull request everyday would have been a time consuming distraction.
This is just another version of making sure your developers are typing.
The most valuable feature I've seen implemented in a real commercial product took months to research and design. Merging a pull request everyday would have been a time consuming distraction.
I've been at companies that hired McKinsey to tell them what to do.
In each case it was a spectacular failure.
But also in each case, the executives and leadership who chose to hire and listen to McKinsey went onward and upward in their careers after those spectacular failures.
As others are saying here, they really aren't in the advice business. They're in the scapegoat business.
In each case it was a spectacular failure.
But also in each case, the executives and leadership who chose to hire and listen to McKinsey went onward and upward in their careers after those spectacular failures.
As others are saying here, they really aren't in the advice business. They're in the scapegoat business.
Counter intuitive, but sometimes dev productivity revolves around actively not shipping things or making sure you drive initiatives that are purely a product of “banana measuring contests” to the ground.
“Hey let’s ship this AI chat bot I heard about at a conference”. How about we save those hundreds of thousands of dollars that we’ll spend on training a sub par chatbot that will result in frustrated users who will leave with whatever limited revenue we get from them.
“Hey let’s ship this AI chat bot I heard about at a conference”. How about we save those hundreds of thousands of dollars that we’ll spend on training a sub par chatbot that will result in frustrated users who will leave with whatever limited revenue we get from them.
I wonder how they retain senior talent with such bs? Pay must be exceptional i guess.
Developers snark about MBAs! News at 11!
Wow. I see almost nothing controversial in the McKinsey article. In a nutshell it addresses hard metrics (DORA) gathered via the repo tooling (commits, MRs, etc) which is enhanced with some outcome metrics, and they combine with soft metrics (SPACE) which are inevitably fluffy on the numbers combined with some other measurements to fill out arguable gaps. But overall, it didn't read like a manifesto.
As far as the criticism from the "ex-finance developers" - yeah, some of whom have done a lot of other noteworthy things outside of "fintech". I don't think it was overly harsh. In fact, maybe just focusing in on certain things that inevitably leave a bad taste - such as assigning numbers to human being's activities or otherwise trying to distill human activity down to hard numbers can lead to abuse - no kidding - almost a tautological argument.
That said, happy people with a shared vision and supportive management delivering a product/idea that is contributing to the team's concept of "the greater good" will always be the sweet spot for productivity.
I would lean more towards the SPACE metrics as the best way to measure, but allow that hard metrics such as DORA can be helpful as alarm bells.
As far as the criticism from the "ex-finance developers" - yeah, some of whom have done a lot of other noteworthy things outside of "fintech". I don't think it was overly harsh. In fact, maybe just focusing in on certain things that inevitably leave a bad taste - such as assigning numbers to human being's activities or otherwise trying to distill human activity down to hard numbers can lead to abuse - no kidding - almost a tautological argument.
That said, happy people with a shared vision and supportive management delivering a product/idea that is contributing to the team's concept of "the greater good" will always be the sweet spot for productivity.
I would lean more towards the SPACE metrics as the best way to measure, but allow that hard metrics such as DORA can be helpful as alarm bells.
What is this article?
Why is it citing three seemingly non noteworthy people’s opinions and crediting them with their former roles as a headline takeaway? Are we to take away that they are currently unemployed?
Why is it citing three seemingly non noteworthy people’s opinions and crediting them with their former roles as a headline takeaway? Are we to take away that they are currently unemployed?
Dave Farley, Kent Beck and Gergely Orosz are hardly non-noteworthy people. Farley is best known as being a significant contributor to Continuous Delivery. Kent Beck was an initial signatory to the agile manifesto. Gergely Orosz has four books to his credit and has a significant following.
Farley didn't mock them - he had open contempt. Beck and Orosz wrote a great critique, but had no mocking involved.
But calling them ex-fintech is kind of like saying Marjorie Taylor Greene is an ex-CrossFit gym owner. While technically true, it's not the relevant accomplishment in most conversations.
Farley didn't mock them - he had open contempt. Beck and Orosz wrote a great critique, but had no mocking involved.
But calling them ex-fintech is kind of like saying Marjorie Taylor Greene is an ex-CrossFit gym owner. While technically true, it's not the relevant accomplishment in most conversations.
Ok! So that makes sense. These are people with some credibility and authority.
Why the hell is this not mentioned in the article in favor of their former jobs?!
Why the hell is this not mentioned in the article in favor of their former jobs?!
It's an article written by someone outside the community with low context, and likely for $20 or something similar.
It's a low quality article.
It's a low quality article.
Because the content of an argument should trump the last title someone held?
That may apply to logical debate, but it does not apply to persuasive writing nor interesting reporting.
Writing about a person and providing background information about their former job but not about the facts that make them pertinent to the subject matter is dumb.
Writing about a person and providing background information about their former job but not about the facts that make them pertinent to the subject matter is dumb.
Doing the rounds just about everywhere: “Yes, you can measure software developer productivity” https://www.mckinsey.com/industries/technology-media-and-tel...
Their former roles and industry experience is why they are noteworthy and being quoted. I have no idea why your takeaway is that, if I said "I used to live in san francisco" would your takeaway be that I now live homeless outside of any city? And if the subject was about measuring crime in san francisco, would former SFPD cops being quotes seem abnormal to you?
I do think it would be very strange to write an article with the headline “Ex-Cops mock a new office policy”
It’s a very pointless article and it’s strange to focus on a few random people’s opinions on something that does not have obvious importance. Especially when hundreds of thousands of workers who are active.
One of these people seem to be a former entry level worker. Why? This is less valid than “some people on Twitter said”
It’s a very pointless article and it’s strange to focus on a few random people’s opinions on something that does not have obvious importance. Especially when hundreds of thousands of workers who are active.
One of these people seem to be a former entry level worker. Why? This is less valid than “some people on Twitter said”
Gergely Orosz has a very popular blog/newsletter and has posted on the McKinsey report.
https://blog.pragmaticengineer.com/author/gergely/
https://newsletter.pragmaticengineer.com/p/measuring-develop...
https://newsletter.pragmaticengineer.com/p/measuring-develop...
https://blog.pragmaticengineer.com/author/gergely/
https://newsletter.pragmaticengineer.com/p/measuring-develop...
https://newsletter.pragmaticengineer.com/p/measuring-develop...
I don't think any leadership team has hired McKinsey because they think McKinsey does a world class job at leading software projects.
McKinsey is in the business of reputation laundering. They start the process by building up reputation. They hire from prestigious schools, have prestigious customers, make themselves a household name for the people that matter.
Then when you need someone to make an unpopular decision for you, or take the blame for a project failure, they swoop in and take you money in exchange for taking the reputation hit. It's fine, they know how to grow more reputation when necessary, and everyone at your org or in the media if the situation calls for it, points to them and says "what a bad/stupid/down right evil decision McKinsey made!" while remain the responsible person who tried their best by hiring what you and your peers thought was the best.
McKinsey is in the business of reputation laundering. They start the process by building up reputation. They hire from prestigious schools, have prestigious customers, make themselves a household name for the people that matter.
Then when you need someone to make an unpopular decision for you, or take the blame for a project failure, they swoop in and take you money in exchange for taking the reputation hit. It's fine, they know how to grow more reputation when necessary, and everyone at your org or in the media if the situation calls for it, points to them and says "what a bad/stupid/down right evil decision McKinsey made!" while remain the responsible person who tried their best by hiring what you and your peers thought was the best.
McKinsey is normalized industrial espionage. You pay them to validate what you're doing against your competitors. They'll tell you if you're ahead or behind. McKinsey is in business because McKinsey is in businesses.
That would be way better than why they actually are. It's a bunch of pretentious sycophantic kids who target empty "leadership" types with advice that sounds smart if you don't think to hard but has extremely good production values. There's a reason they exist but it has absolutely nothing to do with bringing anything of value other than reputation and knowing their audience. Actually bringing outside info from competitors would be cool but way too tangible for them.
This and it’s very well known, but don’t discount their talent. There are plenty of smart and effective people at McKinsey, even if they make mistakes like the rest of humanity.
Wow, powerful stutff. It really shows that capitalism commodotizes all. Even being spied on is given appropriate value. What an insane system we have.
McKinsey sells the "idea" that they're experts that know what they're doing, rather than actually doing a good job.
I’ve met consulting analysts whose entire job concerns e.g. a single chemical plant in Baton Rouge. Of course, they would never work for an Louisianan industrial company. But stick McKinsey on the resume, let them fly in and out of a big city, and cut the compensation in half or a third and you have a winning proposition for many status-nervous young people. (Private equity does the same thing.)
You'd be surprised. I could very easily see former McKinsey alumni sprinkled through the industry slurping this stuff up.
Tell that to my former manager.
[deleted]
A deep dive on developer productivity metrics tends to lead to queueing theory. This is an area some developers know because of DORA and metrics such as MTTR or shorthands such as "do one merge per day". It turns out that knowing some queueing theory can be very helpful when talking about productivity metrics, kanban, ticket servicing, and more.
My notes on queueing theory for developers:
https://github.com/joelparkerhenderson/queueing-theory
My notes on queueing theory for developers:
https://github.com/joelparkerhenderson/queueing-theory
Anyone's productivity can be measured, or at least what's left of that productivity after measuring. You may know nothing about how musicians make music, but you can measure superficial traits, such as the number of distinct notes used per minute of music, the feedback score from a committee you hired, the lead time to deliver a musical unit, and so on.
These people want to optimize making money. If you compare technical musical ability against musician income, I suspect you'll find a surprisingly weak relationship.
So by that measure, the most productive guitarists are strumming staccato as fast as possible
Kinda like how the best programmers type lines of code the fastest
Kinda like how the best programmers type lines of code the fastest
John Cage might not fit into your simple models, I'm afraid:
https://en.m.wikipedia.org/wiki/4′33″
https://en.m.wikipedia.org/wiki/4′33″
> For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.
The rest of the article is equally hare-brained. It's a sort of clueless management-consultant thinking that believes software engineers should be furiously typing all the time, and it entirely fails to understand that actual software engineering is about solving business problems.
Stuff like this really makes me wish I'd optimized for $$$ earlier in my career, and I only hope I can retire before this kind of absurd thinking spreads into real technology companies.
[1]: https://www.mckinsey.com/industries/technology-media-and-tel...
EDIT: Changed "MBA thinking" to "management-consultant thinking," in response to fair feedback below.