Doing things even when you aren't sure if they are your responsibility is precisely what makes you a responsible person. Encouraging everyone around you to do trivial things like bringing the shopping cart back is actually a big deal. And the most effective way to do this is to just do it. Park as far as you possibly can from the store and walk that thing for a solid 3 minutes both ways. Find one with a really noisy wheel. Make a whole production out of it. Leading by example is unbelievably effective if you lean into it just a little bit.

But this could be anything. If you see a customer waiting on a response and you know exactly what they need to be told, go tell them. Don't make them wait until next Thursday when their CSR gets back from vacation. If you aren't sure about the email, draft it, send it to your boss/peer/etc. for review. About 50% of the time they'll say "yep looks good please send" the other half they'll just take care of it right then and CC you on it. Either way you come out looking good.

The "not my job" crowd is simply not thinking ahead at all. You don't get paid more money the microsecond you go above and beyond. It takes persistent investment in this bucket before someone with actual power decides to help you out. There's not a progress bar or quest log you can review. It just happens. One day you get a phone call and that's that. There's no lead up or anticipation most of the time. You just have to be good all the time and expect that you are being observed. That's the only thing I've found that works over strategic timescales.

The first time I managed a team I designed a whole solution for the team to implement, and they were like "Are we just your typists?!! Why don't you let us do that?". They were right; I stepped back and shared goals and direction with them instead from that point. It's hard to step away from how you did things before and give trust to others to do a good job.

The other thing they highlighted also resonated - if you become a manager of people who were formally your team mates, it alters your relationships with them. I remember feeling quite depressed when people no longer joked around with me in the same way they used to, and I felt a bit isolated. Took me a while to understand the shift in dynamics and not take it personally.

The only problem is the manager level above you. If you're the guy who likes plain speaking and speaking the truth, being a manager is not for you. If you have sycophantic tendencies, you'll last a long time.

If you look at the IC track of the engineering ladder at a big tech company, the "Distinguished/Principal Engineer" is technically an IC role, but they have so much organization leadership responsibility that it feels wrong to say they aren't doing high level "management" as part of their role.

I have trouble wrapping my head around the exact distinction of manager vs IC the higher up the engineering ladder you go.

I imagine as a Principal Engineer you are essentially directing other tech leaders, even though you don't directly perform performance reviews on them? (that's for the SVP Eng?)

Take France with medium to large size companies: ICs (whatever the seniority) are usually paid less and have a hard time evolving so they are naturally encouraged to take on management roles by their hierarchy. In some other contexts, ICs may have more leverage thus not wanting to go the management route and that’s okay.

Anyway, in the next 5 to 10 years this all might change for better or worse so…

I've seen dozens of people start managing, stop managing, change roles (including myself), etc, and there are two extremes that stand out:

1. Management out of necessity. They became a manager because they wanted to solve a problem that is too big for them to solve alone, and no one else was willing to fund it. So they got headcount, hired a team, and set them to work on solving the hard problem. But the problem they're solving is the only focus. This manager tends to have an elite team of low-maintenance engineers who just get things done. They are very effective, but eventually when those reports start asking questions like, "how do I get promoted? What's the next step in my career?" their manager has to suddenly learn this new set of skills or risk losing their highest performers.

2. Management to be a mentor. They became a manager to help other people grow. Sure they are solving problems with the team, but this manager spends the time to help higher-maintenance engineers grow their own skills. This is time-consuming, this can be frustrating, progress is going to be slower, but eventually you can reach very high throughput, and also feel very accomplished knowing you helped someone else reach their potential. This, however, has to be balanced with not moving so slowly that you frustrate your top performers.

There's nothing wrong with either of these extremes so long as everyone in the manager-report relationship knows what to expect, and many managers will be between these two extremes.

The main tl;dr takeaway is: as a manager, you are not just responsible for people's tasks, you are responsible for their career. Managers need to take this seriously and address it head-on to build those skills before the first time a report asks, "so how do I get promoted?"

Often times narcissistic power grabbing (often technically incompetent) engineers become managers, like it was the case a previous team I've worked at and it was quite penalizing to the whole team.

I've realized that either i can be the one managing and try to do good, or be at the mercy of another manager; chose the first.

Ignoring the AI tells throughout the article for the moment, but I'm very surprised that someone who is a staff, staff+ level IC hasn't has to build this exact skill.

> When you’re an IC, unclear communication slows you down. When you’re a manager, unclear communication breaks your team. That difference in consequences makes you learn faster than you would any other way.

This is nonsense: unclear communication from me to my team absolutely breaks the team, despite being a staff+ and not an EM. Distinction without a difference.

Up to a point this worked, but when I didn't program I started to become part of the problem and when I did, I didn't have time for the management.

The politics are horrendous and just to survive you try to bend just enough with the prevailing wind not to get into trouble but then you find you're becoming "the man" to your team. If you're too nice they start thinking "what does he even do?" - well all the boring stuff that lets them off the hook so they can focus.

Then you realise that problems with arseholes that used to come from above and from the side can now come from below as well and, unless you're in some capitalist fantasyland, there are only slow painful and expensive solutions which damage you.

You also get to see that you're not allowed to do the things that would let your team achieve goals but you are definitely going to be blamed for all the ridiculous ideas your superiors try to force on you when they finally escape through promotion and you're left trying to explain why X and Y were done.

So in general I feel burned out about people after my experience. I completed projects on time in the face of lots of problems which I managed to navigate around effectively but the experience was horrible because people are often horrible and horribleness wasn't some thing you could admire - like "oh they're tough but effective." It was more like stupidity all the way through but made up for by arse kissing.

In every place there's stupidity all over the place. At one place people know all about how to use source control as if that was too unimportant to mention but have no testing system for all their macro-services so everything's always breaking .... but of course we can't delay those new features just because of the latest incident can we? At another I'm getting lectured on how to do everything by the git expert of 3 months while I convert their incredible SCCS system. At another, man,we have 100 commandline arguments and our customers just better learn them all to get an optimal result.

All of them screw up agile and bitch about why it isn't doing what they thought it would.

The new thing is checking up on your AI usage to make sure you're using it enough. Lets not fix our development and testing process ... no ... lets hope AI will magic our quality problems away!

Being a manager doesn't really let you fix this stuff.

Firstly you have to be able to articulate why things are going wrong and that's bloody hard. Then you hit the problem that if you have amazing insight that lets you see what to do, nobody else at that company has it and they're all off following their own ideas no matter how little they might have worked in the past.

Whatever is wrong is that way because the sort of social situation that came into existence formed it that way. You're not battling a lack of insight but something else - perhaps a set of incentives. Whatever it is, it's like trying to stop a hurricane by holding up your hands.

If you're too low the higher management force you to be sht and if you're higher I imagine that the pressures of the business force you down the road of being sht anyhow.

Accountants want software to depreciate - so it has to be "finished." So they hate you going back to fix things that are supposed to be "finished" and want you to work on new things.

..........ok, end of stream of consciousness. :-) I just feel a bit battered by it at the moment. Nothing in life is easy.

Personally I would love do the first, and the second one feels more like HR should do. Of course, HR doesn't have the specialization needed for that, but maybe they should expand into that? HRO - Human Resource Optimization.

There might be some people that need a nanny. I am not one of those people. My manager should be a proper valve between me and whatever layer he manages for and should not play stupid games when it comes to my career. That's it. He's a colleague. Not a mentor. I'm perfectly capable of finding mentors for myself, and if it happens to be them, well, kudos to them.