Ex-Finance developers mock McKinsey's monitoring metrics
efinancialcareers.com
efinancialcareers.com
> 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.
(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.
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 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.
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.
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.
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.
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.
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.
And maybe the corporate $$$ optimization means real technology company will avoid this.
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.
The irredeemable cynic might wonder if this is because they see themselves as the only ones who should be 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…”
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
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.
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.
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.
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.
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.
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.
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.
My notes on queueing theory for developers:
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.
Really weird way to introduce Kent Beck
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.
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.
“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.
Kinda like how the best programmers type lines of code the fastest
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.
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?
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”
https://blog.pragmaticengineer.com/author/gergely/
https://newsletter.pragmaticengineer.com/p/measuring-develop...
https://newsletter.pragmaticengineer.com/p/measuring-develop...
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.
Why the hell is this not mentioned in the article in favor of their former jobs?!
It's a low quality article.
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.