I didn't go into management because I didn't think circumstances were stable enough. I did see four co-workers go up the ladder, with disastrous results. Two of them I tried to warn, the other two would have been a waste of time to warn. By the time I retired, two had been fired, one drank himself into a coma, then passed away. The fourth is still working, but became so hated, the company keeps moving him to different posts. All four of these cases were promoted by management personnel who were "people persons", but were terrible decision makers.
There's an old saying, "Ain't nothing to it, if you're born to it." I know it's too simplistic, but it's based on a lot of reality.
I experienced burnout before but dying because of work sounds very extreme.
Organizations where they get away with this are miserable to work for, and their influence ensures nothing merit-related ever happens again. Literally the source of the famous expression “A-people hire A-people, B-people hire C-people”.
Here is it straight from the source: https://guykawasaki.com/the_art_of_recr-2/
What’s your interpretation? What do you connect it to, if not management?
Both is fine, these are just different jobs. However, the problem is that the manager is 'above' the engineer in the generally accepted hierarchy. Consequently, engineers are pressured to become managers for the development. As long as this hierarchy exists, the problem will exist.
My experience has been that those who are too precious about the only role they've ever had (an "engineer") are difficult to manage precisely because of their inflexibility and lack of curiosity. It's ironic isn't it?
It's not as absolute as you make it sound. Also because managing a team shouldn't require you to make very technical decisions. You should obviously know what you are managing but if there is a decision to be made, the people who spent hours on that subject will be your best experts and their guidance is essential.
In soccer coaches usually handle the strategic side of things and they have dedicated coaches who handle more player-related things. I think this is how a good manager in a normal company should work too. Make sure the team works as a team and take strategic decisions but not handle the nitty-gritty technical stuff.
This is a point I came to make. Different jobs also different skillsets. A good solution taken on by some industries is decoupling promotion and salary rises by having separate engineering and management streams where both have similar opportunities for career progression but you can stick to the actually job that you yourself are best suited for. People who have the people/social/political/organization/high-level-view skills and like exercising them can go into management, and those with focus/deep technical expertise/creative problem solving skills, can stay in engineering. People do usually have bits of both of these, but you know if you are stronger in one or the other.
I would encourage you to try to setup a place where no hierarchy exists and see how it goes. In my experience people have wildly different opinions on multiple (even minor) things and without someone to "take a decision", things end up just going in circles.
Of course, if the person taking the decisions repeatedly takes decisions that have a negative longer term impact (much easier to asses on longer term than at the moment you have to take the decision), something should change, but that can include contributors looking for other companies ...
You put agreements/processes in place to make decisions in a flat hierarchy, and as last resort business (PM) makes the calls.
Senior engineers and above, they need to know all the engineering skills, but they are most of their time not being engineers, they're being a people person. They're talking to others, they're explaining to other developers what's going on, how to do their job. There is somewhat difference as the manager is thinking only about the organization structure and how good people are, whereas the senior engineer is thinking about how to use people to make the engineering parts better.
In others, it's about who you know.
But when it comes to internal promotions: it's a mix of both, and promoting people who are likely to boost your own career is an obvious choice.
When someone incompetent is promoted, people below them see their incompetence. However, the people above the promoter only see the promoter's incompetence.
I have no idea what this is saying. What does “being impostered” mean? As far as I know, “Imposter Syndrome” is all about personal insecurities. It’s not something imposed.
A year in I got the only negative review of my career, and knew I couldn't keep doing this. I was so stressed I developed trigeminal neuralgia. I had to leave. A friend was looking for developers and I jumped at the opportunity. It was technically a demotion but probably one of the best choices I've made in my life.
All these years later, I'd love to take a second crack at it. I am a lot more capable and mature and I think I could handle it better now. Combine that with not really enjoying the work now that everything is AI driven and it might be time to give it another shot.
For example, getting promoted to "senior developer" may mean higher expectations than just "developer". But you may also be expected to architect parts of systems, mentor more junior staff, provide guidance etc. Even more starkly, if you get promoted to something like "team lead" or a more managerial/executive level position, your need to be focus more on prioritization, managing people, etc. Very different skills than writing code.
Further down, the author wrote:
"The transformation into a syndrome shifted the experience of being impostered by a patriarchal, white supremacist society into a medicalized disorder, something for which the impostered person must be treated. That’s a neat trick: to shift the locus of treatment to the mistreated person, rather than the system that caused her harm."
At which point, I have to admit, I said "WTF?" in my head. One could just as easily say the transformation into "syndrome" is rooted in a society that has shifted from focusing on actions and accountability to one that focuses ever more on inner-feelings as what is important.
However, one thing to note is the senior level positions, the higher you go, the more you're a people person. A low-level developer can think about architecture all day long, but because they never talk to anyone about the ideas, discuss if it's really good or bad, understand the pros and cons of the ideas that others have, they're going to remain a low-level developer. This is why senior developers move in and out of management very often in a lot of companies. The jobs are not nearly as different as people would imagine. In both cases, you're more a people person than a technical person. It's just that as the senior developer, you still keep that developer hat on and write code, whereas as a manager, you're only a people person.
This doesn't contradict the Peter Principle, which doesn't imply you're increasing competence on a single axis.
In its most bare form, the principle states that people get promoted until they get stuck at a role in which they cannot adapt and do a bad job at. It never states it's a single dimension of competence or incremental over their last role.
The book mentions the case of the guy who "accidentally" parked his car in the big boss's spot once a month or so, to forestall promotion.
Only when I’ve reached a position that I can’t learn to do, I will stop being promoted
Competency is about you, but it's also about the competitiveness of the organization.
Not every business has the ability to promote to satisfy everyone's ambition.