I truly hope your impression isn’t reality but all i can say is in certain settings it’s worked great, in others it’s been meh. I’m subject to the same issues we all experience here.
I'm curious what you mean -- worked great for what aspect? Short-term bottom-line targets for the company at the expense of workers, or long-term culture-supported productivity ones that benefit both company and worker?
I suppose if you have a team of people who treat work as "doing homework for the rest of your life" (and quite a few SWEs never grow out of this mindset) then you can help them stunt their growth and extract whatever you want out of them for the company's sake. It's been my experience that typically the real movers and shakers need more than that to thrive, and they need to feel like they're thriving to stick around. I worked too long in a dessicated environment because the people who were insightful and good at their jobs were told to shut up and grind. They left for places where they could have more agency and feel like part of a team that values their input.
Most of my career has been with early stage tech but I’ve also been in companies of thousands. I think I’m best cast in teams of 5-20 and I’ve found I’ve done well building good culture around working within the limits of what the business needs (realistic costing, time estimates, alignment to product vision) while finding ways to intertwine the quality developers want to see in their own work with the objectives of product and the leadership team.
I think to try put it in simpler terms, the best people want an environment where they can do their best work. The question i encourage people to ask themselves is if they actually know what that environment looks like? Often they have an idea of what’s worked best so far, but not what is optimal. I like having discussions around that as you can go from there to a) learn from their perspective and see if you can include part of that in the environment you’re presently operating under and b) determine if that’s a good near team goal or long term goal for the current environment and set realistic expectations with that individual as to not “bait and switch” them. I really see little point wasting someone’s time with promises of utopia when you’ve got a team that just isn’t working…that’ll end predictably.
I’ve said before my best skill has been building small teams of very bright people, retaining them and out performing larger teams. It’s pretty trivial to out perform larger teams if you can retain people, but to retain them they need to like what they’re doing and how they’re doing it.
Now I work as an IC again at a more top-down place where I work fully remote and only 4 days a week. It's honestly quite nice to not have to talk to anyone and just wake up at 6am, have my task assigned, get it done and then go focus on my hobby projects/go hiking/exercise/spend time with my girlfriend. I don't have to be online 24/7 and I have maybe 2-3 meetings a week. The org sets the direction and we decide how to implement it. It works for me because in many ways I drive the requirements by telling the org what I need to execute properly. I can also still drive infrastructure improvements, and the org. is mature enough to prioritize them. I still grow, just in a different direction than I did as a manager. I get the chance to really focus on the technical parts of a solution.
This is key.
"Good" managers can manage the expectations of the org to enforce this kind of relationship if the org wants to be pushy or micromanage-y. They insulate their team to create a real sense of agency and ownership. It's nice that your org makes your manager's job easy in this regard.
"Bad" managers are the opposite, they just dump the poorly-defined, poorly-justified demands onto their ICs. When they can't figure out why things aren't going well, they call for many hours of meetings with their ICs to hash out in detail how the implementation should proceed, which typically ends up being nothing more than the manager trying different ways of convincing their ICs to do it the way they already imagine it should go.