[afavour]

> The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users.

It’s not surprising that this sentiment is popular on a message board filled with engineers but I’m not so convinced by it. Nor do I think the current state of tech companies is acceptable, to be clear. But there needs to be some level of management outside of the engineers themselves. A lot of talented lead engineers I know are terrible people managers, or ineffective project managers. And that’s fine, because there are other people to do those tasks.

If your utopia is a bunch of engineers given freedom to do whatever they want, however they want to do it… I suspect the dream and the reality will not match up. In the scenario you’ve outlined I strongly suspect you’ll have infrastructure on its third rewrite, full of power user features and tweaks… and near-zero adoption from newcomers. Product fit is a thing that needs to be managed!

[Dead3]

The OP is right most production code is full of errors, and suffers from code bloat and feature creep that impacts UX.

Is this really the best we can do? It strikes me as unacceptable to ship errors to production, yet it's commonplace.

Code quality matters, and being in touch with users/dogfooding matters. But that can only address the underlying problem by eliminating the low-talent developers who win by numbers.

How to solve the relevant problems is not something hiring and recruiting teams can assess. So, hiring process uses proxy metrics like having a HS and CS degree, years of experience, brand name companies, list of tools, "best practices", trends, etc.

Teams of self-congratulating code monkeys using all the latest 'industry standard' libraries and tools, don't accept responsibility for their errant code. Instead, they blame (the user, his browser, the library), make excuses, minimize "all software has bugs". They can't fix the bugs they've created for themselves, but it can't be their fault, after all, they're doing what everyone else is doing.

The answer is to send them packing. Hire by talent, not by proxy of a hiring team (who don't know how to think/use the aforementioned proxy metrics to gauge talent).

Intelligence cannot be taught, but it can and is discriminated against. That is another problem with these faux 'team-player' follower types. Anyone on the team pointing out the code is a disaster and an attitude to fix it is not going to last. He'll be fed pushback of the same crap excuses for why things must be done the way they're done.

When a talented developer does deep dive analysis to identify root causes, most on the team don't get it. The scary bugbear of coherence is too hard and threat to the team's shared narrative.

Again, the only way to solve that problem is to send them packing.

[slopinthebag]

Yeah I hate that you’re right. Blender is an example of OSS software which is actually a joy to use and they have product designers. But I think there is a massive gap between good and bad product people. No product person would be better than bad ones, but for truly great software you probably want some good ones.

That being said lots of good OSS exists purely built by engineers so I think it’s really the case that good product people help a lot and bad ones hurt a ton.

[Silhouette]

Some developers also take an active interest in the design and feature set of the product they're developing. IME those developers can often produce good results once a general direction is set if they have access to real users to collect feedback. But it's important to recognise that these are essentially two completely distinct skill sets and mindsets and it just happens that some people have both.

It's not really any different to the old arguments when continuing a career beyond senior dev level meant moving into management but there was no guarantee that just because someone had been a competent developer they would also be any good at managing anything. Some were and produced great results - in some cases informed by their understanding as former developers about what would be possible and what it would realistically cost - but in other cases the Peter Principle hit early.

[stymaar]

I'm not totally convinced by OP's whole point, but I want to point out an issue with this argument of yours:

> lot of talented lead engineers I know are terrible people managers, or ineffective project managers.

A lot of people who can read are also terrible manager, but that's not an argument to put illiterate people in charge. Not every engineer has what it takes to be a good manager, and that's fine since you don't need this many manager anyway, but I'd argue that for a management jobs, understanding the craft of the people you're managing is as important as literacy, because the most important role of a manager is make decisions and you cannot make good decisions about things you don't understand.

That being said, engineering is only half the takes in software, the other half being Design and you cannot have a manager that is merely an engineer without design skills (otherwise your product is going to have the user-friendliness of Arch Linux).

[harimau777]

The problem, as I've experienced it, is that companies don't try to determine what engineers also have managment aptitude. They simply promote whatever engineers are good at writing code.

[ragall]

And furthermore, in the last decades engineers have become infantilized to such a degree that most don't want to learn to be a good manager and prefer to stay Peter Pans for ever. I believe it's an outcome of the 80's and 90's "nerd" culture because, if you ask the elders, it didn't use to be like that in the US, and it's much less prevalent in Europe (but alas that's far from being the center of the software industry).

[afavour]

I’d say that describes me but I don’t see it as a Peter Pan thing… I’m very technically skilled and I want to keep using those skills. I know the role I want, it’s what I often see advertised as an Architect role. But companies have an order of magnitude fewer of those roles than people management roles. I don’t know that it has to be that way, a lot of projects suffer from a lack of top level technical direction more architects could provide.

[ragall]

In an organisation made of mature people, some of the highly skilled people would recognise the need for them to become people managers (not Architects), and so the organisation would benefit from managers who were actually competent, having done the work themselves before.

I see complaints about companies not promoting from within their ranks, and choosing MBAs for managers, but the grim reality is that the engineers themselves don't want to step up and grow up.

[afavour]

You’re really stuck on the maturity thing here and I’ve got to be honest, I don’t get it. Becoming a people manager is not “growing up”, it’s simply a different job.

My skills are not in people management. My skills are technical. The organisation would not benefit from me being a people manager because I’m not good at it. I don’t understand why I should opt to do a job I am neither good at nor enjoy just for the supposed benefit of my employer. Part of “growing up” is realising that employers are replaceable and sacrificing yourself at the altar of any given employer is a fool’s errand.

[bluebic]

> A lot of talented lead engineers I know are terrible people managers, or ineffective project managers

Ok but non-technical “managers” are way worse.

Has more to do with role focus and hours in the day. I would rather have a dev dedicated to PM than a “manager” larping as one cringily trying to keep up with us totally ineffective to lead a technical team.

Tech companies are anything but technical anymore since they got rid of all the talent.