>The vast majority

I really don't think this is the case. I think there are a lot of less-experienced developers who will be very sidetracked, yes. But anyone even close to senior should have developed an intuition of when it is time to build carefully and when it is time to "just ship". (this isn't just "go slow at first and then haul ass to hit deadline", you can switch between these two mindsets several times even within a single PR.).

And at a higher level - I expect senior and staff-type engineers to have at least a decent amount of product sense. Their job may not be to do product management, but they should be able to reasonably-accurately judge what product work will be more business impact vs less.

Senior engineers are often good at turning boring problems into more interesting problems (to them) by doing unnecessary rewrites or introducing new technology.

These days the title "senior engineer" is handed out like candy. Anyone with three years experience is now "Senior" in title. In the US, doctors fresh out of med school have a minimum of three years ahead before they can even begin to practice independently. For programming, and pretty much any other profession, senior doesn't really begin until nearing 10 years of work experience.

At that point, that itch to turn boring problems into interesting problems takes on a different form: What becomes "interesting" is doing things within constraints, including the constraint of staying with existing technology, when it's solving the problem.

“No True Senior SWE” paradox?

10yrs is a very long time in Computer Science. All the engineers I’ve worked with from earlier eras are very influenced by what they started their career with. Heck I’m the same way as I approach my decade threshold.

Software engineering suffers from a lot of "1 year of experience repeated 10 times" folks.

Doctors and most professional engineers undergo heavy rotations within their overall practice, and do lots of CE.

I wish every SWE did the same.

Title inflation. I speculate based on no evidence other than my own observations that it's because companies aren't willing to pay entry or junior engineers well enough, so lots of them get hired at lowball rates with an implicit understanding that they'll get promoted to senior after 3 years and get the a corresponding pay raise. Either that, or they don't get promoted or a raise, change jobs, and get the senior title by default.

Promotion is absolutely my employer's main retention tool. Many of our senior engineers who leave don't end up with a senior title at their new employer, but they do get a bump in pay.

> "I tend to agree but there's a real danger in leaving engineers to their own devices."

Agree with this concern but that's a false dichotomy no? "Upper management is bad" isn't necessarily proposing that engineers be left to their own devices, it's to cycle out upper management with more competent replacements.

I tend to agree with your overall point: companies where the culture encourages individual front-line teams to self-organize and ship independently tend to end up with incoherent products (see: Google). There's a lot of product velocity but almost none of it matters. You have teams shipping features because they feel like it and personally like the features, not because they offer some business value or strategic advantage.

You really, really need high-competence upper management to wrangle this energy into something coherent.

> it's to cycle out upper management with more competent replacements

This is a wildly optimistic statement

> software engineers are the worst at planning their own work. The vast majority will just go off and do wtf ever they want

There are successful companies that have senior engineers managing/leading teams and still coding. This idea that software engineers need managers and that somehow being a software engineer means only coding (IC) is a pattern that early American tech companies went with. Originally I imagine it was to reward and empower engineers, these days I feel like more and more companies use it to control and manipulate engineers.

In the mid-2000's, I worked at a company where the engineering managers were actual engineers that coded. They often did double duty as PMs. You don't see that often today.

Yeah the progression feels like a textbook example of the iron law of bureaucracy [1]

[1]https://www.jerrypournelle.com/reports/jerryp/iron.html

>I tend to agree but there's a real danger in leaving engineers to their own devices. [...] The vast majority will just go off and do wtf ever they want.

I think in larger organizations this is true of pretty much everyone but in different ways. No-one's career success is very directly tied to the overall success of the company, so everyone is trying to get something for themselves out of any given project. For software engineers that might be pointless code/devops complexity or unnecessary use of esoteric and interesting technologies. But PMs, designers etc. are equally adept at coming up with pet projects that contribute little to the fundamental success of the business. There are lots of PM-driven dev teams 'urgently' working to complete features that are completely unnecessary or even counterproductive.

‘Developer Hegemony’ — which should be called ‘Information Worker Hegemony’ — makes the case for engineers being involved in planning and strategy. Most developers I’ve worked with were amazing self-starters that can get tons of stuff done by themselves. It’s the micro-managing and lack of vision that seems to have the greatest negative effect on their productivity.

As an engineer-turned-manager, I am fascinated by how poorly other departments handle planning (at our company). Devs are just amazing at getting things done when left alone, provided they know why feature X is important.

See: https://www.goodreads.com/book/show/35051753-developer-hegem...