I don't think its possible to just take it away and see what happens, because organizations build the concept of EMs into their entire culture.
As an example: I worked in a Big Tech org where the only way to get anything from another team was an org hierarchy jump. ICs could reach out directly; ignored. Some teams didn't even have a way to reach out to them. You had to go EM, then maybe a Director, then it filters down, and maybe a day, maybe a week later, you'd get an email introduction. It doesn't have to be like this, no one even decided it should be like this, but because they had the hierarchy that's how the culture evolved.
The better comparison is to look at companies who don't have that role, or define that role significantly differently from the traditional Big Tech definition. There are many; of course, not as many as the latter. And just like companies who do have the role traditionally defined, there are success stories and there are failure stories. To me, the more I've read up on those stories, the more I've realized how pointless the role is.
Or, maybe more accurately; how much of the role's responsibility is really to be a crutch for bad culture, bad upper management, bad hiring practices, bad interviewing, etc. That ain't totally pointless, but if you're also flipping a coin on the quality of each EM you hire, and moreover the coin is rigged because we don't even have an industry standard definition for what defines success in the EM role in the best cases; there are better ways of reaching the same destination.
But, you know, most of the time those better ways require an ounce of Trust from senior leadership, and that's like pulling water from desert sand.
There's not a ton of consistency across even relatively similar-looking tech companies in my experience, so you really should expect your mileage to vary. My N=3 large tech companies in my career is not so much better than your N=1 example, but it does allow me to say that these things are not consistent at all, with some notable exceptions, usually constrained by employment law.
Devs: "Overworked? Too many disparate responsibilities? Not being able to write enough code? No team cohesion? This is a systemic failure of leadership, start interviewing for other positions."
Devs: "We, as software developers, are underappreciated! People only pay attention to us when things go wrong!"
I like this caricature but remember that, since this is not a regulated industry, there are many different personalities, and those who think this way don’t succeed for long.
What happens is that an otherwise productive engineer has to step up and perform the role, but without any recognition of the extra responsibilities or any reduction in expectations of their individual contributions.
So then they find a job somewhere else and another otherwise productive engineer has to step up.....
Meanwhile the other engineers continue on blissfully unaware, patting themselves on their backs for how they don't need to be managed.
I've seen this happen in smaller teams; it can work well! Productive teams and skilled engineers can manage their own workload. Not all of them want to do that, so that needs to be taken into account, but it can work spectacularly.
I've also seen it work poorly. We've already established that there are good and bad EMs; there's good and bad in everything. That doesn't justify the role of the EM!
I've also seen PMs do this. This is the far more common situation, and it works! Workload planning ends up being a collaborative effort on the team, with the senior engineers holding domain knowledge over operations, maintenance, architecture, implementation, while PMs/Designers/etc hold domain knowledge over the business, customers, etc. Work once in an environment like this; well, at least a good one; and it will make anyone and everyone question why EMs exist at all. There's no room for them. They wouldn't contribute anything even if they were added to the mix.
And no extra agency and no extra authority. I've been in that spot, had the best 4 months of my life (lack of authority was painful). Then 2 clueless managers were hired above me.
I've been at my current job for 12 years. For my first three years, I had no manager [1]. I then did an internal transfer to development, and had a 'meh' manager [2]. He burned out after a few years. The next manager I had was great. Technically, he shouldn't have been our manager as he was a director at the company, but due to financial politics, the company couldn't hire a manager for us. He just told us what we needed to do and otherwise, let us developers alone to do the voodoo that we do. He was eventually let go and one of the other developers on our team was promoted to manager. He too, was great, just telling us what to do, and trusting us to do the voodoo that we do. He retired. My current manager (from the company that bought us out) is bad. Enterprise development being shoved down our throats, not only telling us what to do, but how to do it.
So, in my mind, a good manager will tell the team what to do, listen to them, and let them do the how. Next up is no management---in my experience, I knew what needed to be done, and got it done. It was great, but I realize that was a bizarre case that normally doesn't apply everywhere, but because of the nature of the work I did, only a few other people actually knew the work involved. The 'meh' manager didn't hurt, but really didn't help. And bad management, well ... let's just say a bad manager can really damage a company.
Until bad management showed up, our team always delivered on time, had smooth deployments, very few bugs in production, and otherwise, was not a source of issues for anyone. Now, we've missed multiple deadlines, horrible deployments, bugs in production and our customer, The Oligarchic Cell Phone Company, is very pissed. And it's not the sole fault of my current manager, but of upper management in general.
[1] I was initially hired in QA to test the call processing side of our product (the bit that happens when a call is placed). The existing QA manager only knew how to QA the cell phone handsets, not the call processing server side. I knew next to nothing about the cell phone handsets. It was clear the QA manager was not a good fit for me.
[2] He wasn't great. I don't think he was as bad as some other employees said he was. He was a developer who was forced into a management role.
I've worked in a place without eng managers, product managers, scrum masters, various MBA people, you know... all those employees that a certain segment of HN thinks are useless. It was just Sales and Software Engineering, and the CEO, to whom everyone reported. It was the worst job I've ever had.
Developers just developing, without interference from evil managers and clueless PMs! Amazing! The ideal work environment for the genius bootstrappy engineer! Sounds like heaven, right? It was not. It was total chaos.
1. Nobody knew what they should be doing and what were priorities. Someone from sales would run downstairs and say "I just sold Foo to a giant customer! You need to build Foo now!!" and everyone would go off and start building Foo. Then the CEO would fly in and ask "Why are you not building Bar? I'm personally interested in Bar, please show some results! Oh, and any product changes need to be personally approved by me now. Byeeeeee (gets on his plane again)". So developers kept developing but had no idea what to develop.
2. Joel Test[1] was 0 out of 12. Since it was just developers developing, nobody had time to write a spec, or set up source control, or design a build/release process. Those were icky tasks that stupid PMs and managers did. Developers want to develop. So the software engineering process was a clown show. Releases to customers were always late, and when they happened they were built directly from an engineer's workstation (they would just find a tree that actually built without errors, and that was the release).
3. If the software failed in the field for a customer, and this happened constantly, there were no useless support staff to talk with that customer, do basic tier 1 and 2 support, diagnose, and so on. Customers simply got angry, and since it was just developers developing, they had nobody to call and rage at, so they'd call the CEO. Then CEO mad. CEO would make a developer fly out to the customer's site with a laptop and debugger to pacify the customer. Now, that particular developer wasn't developing and was sad.
4. Things like career growth, mentorship, training, learning new best practices, none of that existed. It was just developers developing, so there really was no knowledge transfer or any distinction between junior, senior, staff, and so on. Nobody's job was to set these things up, so it never happened. There were no levels so no concept of promotion. If you wanted a raise, you'd go to the CEO who would just say no. That was basically your career development.
So yea, go find a place without managers and MBAs and let me know how it goes.
Sorry, but then you and your colleges were not senior enough to handle an environment like this. This is not a question of missing management, but also missing (technical) leadership.
While I do not know if it would have solved all your problems, you can make this environment better, without adding a management layer in between.
I can't speak for everyone, but I would not argue against PMs or Senior Leadership.
There are two critical differentiators in the role of an EM: power over those managed, and the bias toward management over productive output. The people who predominately fill those roles are those who are good at management, not those who are good at production (and, by the way, the "good EMs" which DO exist are generally people with a history as an IC, and treat the role more as a PM).
Now wait, how do developers develop without source control?
As an individual contributor, I consider a number of things in that paragraph good practice. Specs, say. But source control? That's just so fundamentally basic that I lack vocabulary to express how essentially important I consider it to be. How does a team get anything done without one?
Can you design an organisation in which has managers, which would fall apart entirely if you took them away? Yes absolutely.
I'm not sure this really demonstrates that they added value so much as they just prevented value from getting subtracted by other dysfunctional parts of the organisation.
Conversely, I had to attend more meetings when I didn't have a manager, because they were no longer there to act as a filter/shield for the chaff around the corn of what I needed to know.
Mind if I ask where you’re from? Even in highly unionized Scandinavia I’ve never seen software devs (specifically) join unions to any larger extent, let alone negotiate salary through them.
As an example: I worked in a Big Tech org where the only way to get anything from another team was an org hierarchy jump. ICs could reach out directly; ignored. Some teams didn't even have a way to reach out to them. You had to go EM, then maybe a Director, then it filters down, and maybe a day, maybe a week later, you'd get an email introduction. It doesn't have to be like this, no one even decided it should be like this, but because they had the hierarchy that's how the culture evolved.
The better comparison is to look at companies who don't have that role, or define that role significantly differently from the traditional Big Tech definition. There are many; of course, not as many as the latter. And just like companies who do have the role traditionally defined, there are success stories and there are failure stories. To me, the more I've read up on those stories, the more I've realized how pointless the role is.
Or, maybe more accurately; how much of the role's responsibility is really to be a crutch for bad culture, bad upper management, bad hiring practices, bad interviewing, etc. That ain't totally pointless, but if you're also flipping a coin on the quality of each EM you hire, and moreover the coin is rigged because we don't even have an industry standard definition for what defines success in the EM role in the best cases; there are better ways of reaching the same destination.
But, you know, most of the time those better ways require an ounce of Trust from senior leadership, and that's like pulling water from desert sand.