The second is to change jobs where you are back in the driver seat

> * figuring out what motivate your juniors and trying to align that with what needs done This is true, but be careful about taking this too far. Young people arrive at the workforce with a wide range of expectations and motivations. Some of those are going to be unrealistic. You should always try to work with them to understand what drives them and help them find their fit. The most frequent misaligned expectation I've seen in juniors is the desire to lead greenfield projects in year 1 of their career. It can be very disappointing to arrive at your dream job and learn that you have to work on someone else's code, and that you have to build a reputation before they'll hand you the fun greenfield work.

> In your position, the expectation is that you are mostly a working through others and acting as a force multiplier of their work. OP said that his role is senior developer. Developer. Not a manager. Not a team lead. But someone who wants to write code, preferably together with other experienced developers, and by doing so, enjoy the process of learning and understanding technology at a deeper level. Why, then, would one expect his responsibility to be motivating juniors, giving them work, or raising them to be leaders? Also, if someone wants to write code, teamed up with other senior developers, where should one go?

I never worked at a FAANG. Do these teams not have managers? Most of those responsibilities seem like the job of a manager. In my career, this approach of one senior person on a team of juniors means the senior is responsible for a lot of the system design and other high level technical decisions, but they wouldn't be counted on for things like motivating other employees.

OP never said he was their manager. In fact, OP's manager probably doesn't want him to be mentoring all day long.

That seems like a fairly good example. For better, or worse, many tech companies, these days, seem to be obsessed with hiring large armies of inexperienced developers. I have always assumed that they rely on embedded process, to get these developers to work towards release-ready products, but they may also be relying on mentorship and training from senior developers (I like that, better). In my previous position, we did some fairly advanced and unique stuff (image processing pipeline stuff, in C++). It was almost impossible to hire engineers that already knew it. We had to look for people that "had potential," and hope to train them into a workflow. It also meant that each employee was a big investment in time, and encouraged us to keep them on board for many years. Training (I've done a lot) is a big fat pain, and not for everyone; but I feel that it is well worth it, to learn to do it.…

>And in general, there are two ways to go. The first is to accept the fact that many senior engineering and most staff engineering gigs are more about this kind of mentorship approach than actually doing work. And basically accept that the prime "getting shit done" years of your career are done and you will mostly be working in this new way now. 100% and this is far from being a FAANG thing (never mind that FAANG doesn't even exist anymore). My experience is mostly in startup and PE based companies and it's like that there as well. The majority of my managers have been non-technical, corporate continues to shrink the management layer to "save money" (line managers with 20+ engineers), support roles like project managers in many places have been eliminated, and managers seem to spend the majority of their day dealing with comms so organizing and managing the doing aspects of doing work ha…

I'd say this tracks my non faang experience. I used to find it frustrating to have a team full of greenhorns but changed my tune quickly. 1. They were eager as hell. It's refreshing to be surrounded by people like that. 2. You can get more done with them by training and helping mop up the occasional mistake than you can without them. In the end it was great but an entirely different role than what it said on the tin. > Startups and consulting gigs probably better align with wanting to be hands on Also tracks.

Those bullet points are spot on. Once you reach a certain level of experience, by years and/or breadth of experience, you are far more effective and valuable as a source of advice and education than as a code slinger.