For what it's worth, I enjoy mentoring and explaining things, writing docs, and being involved in design of systems and influencing technical strategy. It's nice to be making technical choices. But when you're more familiar with a spreadsheet than an IDE, something has gone wrong.

One of the great dilemmas is that these things are always interwoven with the non-technical aspects of being a manager. There is some aspect in which it is essential - "how long will this work take" depends intimately on the technical complexity, exactly how skilled the available resources are in the necessary areas etc. Other aspects are completely non-essential - "responsibility for staff completing health and safety training lies with line management". I would really like to see a model where these are disentangled.

That's a good description. And the reality is that while, as you say, there are master engineers who can crank out great inventions largely autonomously, the vast bulk do so in large part by mentoring and guiding others. I know many distinguished engineers and SDEs who are ICs. But at least the ones I know spend most of their time communicating and working with others. Open source project maintainers often describe themselves as primarily editors.

Some are actually managers (which carry more formal administrative responsibilities) and some aren't. But almost none of them are largely working on their own because it's really hard (especially outside of a research context and even then) to have maximum impact that way.

My old boss said: "on the way to work in the morning, you should be whistling". I'm from The Netherlands, and I'm not sure if it translates well. But that's the point where I thought that I love engineering, stopped caring about what others may think, and put my management ambitions in the freezer.

Five years further, and I'm slowly coming back to that decision, but in a much more natural way. I started freelancing, took on an apprentice, and slowly I'm getting more responsibilities. But in a natural way, not an all-or-nothing choice.

So my advice is to set boundaries. If you don’t want to be sitting in meetings, then stand your ground or come to a compromise. If they don’t understand then quit! Find the path for you, life is too short to be unhappy and someone else’s pencil pusher.

But as always: ymmv

I don't know that you should use this criteria as the sole deal breaker. Managers should be shielding teams from unproductive meetings and pushing for productivity (action items) from the meetings that happen - holding their peers to a degree of standards.

Now, if you hate 1:1, org planning, and successful meetings, that's another thing.

I myself am a former-engineer and current-manager, and I also remember absolutely loathing meetings as a waste of time, explaining things to people who don't really care that much about what I have to say, and plus why should I contort myself to speak "their" language and why can't they be bothered to learn to speak "my" language as an engineer?

But over time, I think I've come to develop a taste for, the style of communication that happens in most typical business meetings. If you think about coding and entering a "flow" state, to me the core of that flow is being able to clearly and concisely conceptualize the software abstractions you have in your head, mapping them effectively from business concepts or technical requirements and into code, and being able to just churn out a beautiful representation of all those things into something tangible (an application, a service, etc.).

Believe it or not, in roundabout ways, meetings can achieve that kind of "flow" state as well, creating a shared understanding of a beautiful abstraction, and resulting in high-bandwidth exchange of ideas. Certainly it is much harder to achieve "flow" for meeting communication than for coding/engineering (IMHO at least) since it involves lots of other people with lots of different backgrounds and different levels of understanding, but I find that nonetheless it is something I can find enjoyment from the pursuit of that state. Not every meeting succeeds in reaching that "flow" state, but more and more I can perceive and introspect why/why-not it didn't, and come out with tangible lessons for myself for improving. So long as I have a flywheel for getting better, it doesn't feel so draining or so pointless anymore even when I "fail". And sometimes, I really do come out of the most productive meetings feeling very energized, and hearing from my peers how much clarity they gained or how much more confident they are about a decision that was previously questionable/uncertain, is truly a great feeling (at least as good for me, as producing a solid piece of beautiful code).

I found that I don't mind managing, but it's such a different type of work. As an IC I went home (before COVID anyway) mentally exhausted. As a manager I went home emotionally exhausted. Different people are better at recovering from either state of exhaustion.

That said, to get a title promotion, I've found that you have to do more of the organizing, planning, coordinating stuff to be noticed. Performance reviews are biased towards "the next step" in your career and companies are forever trying to get you to do more "meta-work" which I really dislike.

Weird question, I know. But I'm an advanced beginner of a programmer who knows that I'd make a better manager than a SWE. Almost would prefer to just leap-frog to management since, as it is, I'm already looking at a career change and know my strengths.

Maybe you would be a great manager, maybe you would be a bad one. But you would not be nearly as good as a person who is just like you but has also worked as a developer. You literally will not know what you are talking about, and the people you manage will see this, and that creates an unfixable problem between you and your developers.

I mean, the classic "couldn't you just ..." is bad enough from a manager who at least was on the receiving end of that suggestion, at some point in his or her career. But from someone who hasn't had that experience, it is so much worse. Maybe you would never use that phrase, but the dynamic is unavoidable. Much of what you do and say will be second-guessed and devalued.

There is, but probably not in a Software company, since they tend to prefer promoting experienced programmers to managers based on their tech skills (for better or worse)

Companies that work in logistics, banking, engineering etc. and have in-house software teams, but don't ship software as their primary business are far more open to hiring non-programmers as software team managers (for better or worse). If you have any domain knowledge about the area they're operating in that often weighs much higher.

And the best thing my manager can do for our team is political: each team/site competes for the more interesting features to develop..

It's about more than knowing how to program, but rather the ins and outs of development, architecture, technology.

Plenty of more typical Fortune 500 type companies and small, non VC funded companies let managers from non engineering backgrounds manage engineers.