Thank you for commenting this. I feel like I'm taking crazy pills reading some of the other comments on this post, e.g. "I think we need to get nontechnical people OUT of our process"
There are so many engineers out there that are basically coddled children who get paid handsomely to sit in a chair and write code, and have no concept of where their handsome pay comes from.
Thankfully, this era is coming to an end and companies will be/are already taking a hard look at who is driving business value and who is not.
You're perpetuating this assumption that engineers are incapable of providing business value without all these nontechnicals that I am complaining about.
When I started my career I was working directly with stakeholders and building them exactly what they wanted. I did design, I wrote the code, I handled the infra, I triaged the issues. I was happy, my stakeholders were happy, and my process was not all that different than what LEAN prescribes.
Amazingly, we didn't practice scrum or agile or any of that crap. I'd have a meeting with stakeholders at the beginning of the project, then I'd go to work on it, and they would keep in touch. If there were major issues, another meeting. But that was it. My manager would check in periodically for more detailed status updates, or to weigh in on technical decisions, and provide additional feedback from stakeholders and VIPs. But that was it, we all owned our given areas.
Next company, same thing. Outgoing CTO drops literally the entire codebase in my lap and my boss says, pretty much, "it's your baby now". I clean it up, refactoring and rearchitecting as needed, and now, something like 8 years later, it's still running. In fact, that company got bought by another company in Europe, they've fired all of their staff, and yet somehow my infra still runs and drives business value. (Granted, I am a little nervous that they don't seem to have anyone supervising it, but I quit them years ago and only know this because they are asking me to rewrite the documentation that they lost after I left.) Last I checked annual revenues were around $20mil, and I know this because my code is the scorekeeper.
None of this could have happened if I was on a team with code school alum and a product manager and a scrum manager and all that bullshit. Whatever we would have made would have likely been leaky and broken and required the ongoing commitment of an entire team of people to run what should be an afterthought for one SWE.
A competent, talented programmer with deep knowledge of the machine can be a force to be reckoned with. But the business cabal cripples us, just as they like to blow out the kneecaps of anything that threatens their jaundiced power base. There are numerous successful projects out there that nontechnicals view as run by anarchy, yet, these things live on. The Pirate Bay is my favorite example, but you could say the same for a lot of open-source that is both important and lacking in a foundation or supervisory organization.
Nobody can truly "own" the product any more, and all of software suffers. I think that it is vitally important that every project be understandable and implementable by one person, because when you throw a team of technical halfwits at it important details get forgotten. And the machinery that has been built to cover for this: endless ticket threads, neverending meetings, the Office Space-esque interactions between a manager and their reports... all of this just goes away when you replace it with a handful of smart, motivated, talented folks that can operate independently.
As much as the business world hates them, there are a variety of one-man shops out there driving real business value and making real products, but my bet is they aren't making much use of all the bullshit "modern" tech (serverless, a bajillion AWS services, etc) because of the very real cost of needing massive teams of people just to keep these clockwork code contraptions running.
Ownership, decision making ability, technical design, KISS, deeply understanding the system, direct communication with stakeholders, and personal responsibility. Good list! These are the qualities that consistently produce top-notch software. When given the opportunity, this is what good SWEs do by instinct.
What's notable that in each case, the modern ticket-factory approach ("all that bullshit") is explicitly designed to eliminate or dampen these instincts. Diffusion of responsibility, top-down control, eliminating direct connections, everything is decided by committee, treating professionals like replaceable cogs, stay in your lane and do tickets.
It's not just that engineers are very capable of delivering direct business value. It's that many of the "non-technicals" are actively involved in sabotaging the efforts of engineers to do so.
One day you're gone. Then what? I've seen man-years spent by multiple developers trying to understand the application of a lone-wolf developer, with the final decision to opt for a complete rewrite.
Companies optimize for planability and mediocrity, even if it comes at a small premium and hurts those of us who are living and breathing code..
There are so many engineers out there that are basically coddled children who get paid handsomely to sit in a chair and write code, and have no concept of where their handsome pay comes from.
Thankfully, this era is coming to an end and companies will be/are already taking a hard look at who is driving business value and who is not.