Why Good Developers Are Promoted into Unhappiness (2007)

This is also true of my own employer (a fellow FAANG) - the technical track is incredibly hard to advance in past senior, it seems to incentivize devs moving into management, along with the pay differential where even in the same tier, management makes a little more in general by a couple of $10k.

I very much enjoy being a dev and am a top performing one in my VP’s org, but the structure incentivizes me to switch over to the management track, which I’d be happy to do (I have prior experience as one), but it seems like a crappy way to depress salaries of ICs that they are forced to switch companies to move up to where they should be.

Nowhere it says - we cannot program when we become a manager. What if managers continue to make 0s & 1s dance - half of the time if not full time? Wouldn't that be productive & fun? I would say world is changing towards this side. I have heard stories where VPs & SVPs in big enterprises write code & lead their teams by example.

I think it has a lot to do with wanting to have your cake and eat it too.

Supposing you literally “just write code,” there’s a ceiling to how much impact you can have. One person can only hold so large of a program (or so many small programs) in their head, and if you are on a project that reaches a certain size you have to start working with other humans to maintain it, and thus the need for technical leadership and/or people management begins.

One of the basic ideas of good management is that a good manager is a multiplier. Suppose you have a team of ten, and individually they can each ship 8 “points” of work in a week. If you turn one of those people into a great manager you lose 8 points of direct work, but everyone else now ships 12 points per week, and you’ve gone from 80 to 108 points in a week. You could now say the manager is responsible for the 28 point gain.

Similarly with a technical leadership role, doing the architecture and teaching work can multiply the effectiveness of many other people, leading to greater impact than any one individual could have.

When you look at it like this, it’s obvious why these higher impact “multiplier” roles get more prestige and pay than the best individual coders.

And I think that’s the dilemma. The real question - for many of us, anyway - is do you gain more satisfaction from the higher impact role and the perks that come with it, or from the sheer joy of the hands-on work that got you into this field in the first place.

Its really difficult.

I saw some other posters talking about rotating the responsibilities around - ie. leading sometimes and working in the trenches sometimes, and I really understand the appeal of that. That said, I’m not sure if it’s practical beyond the first “rung of the leadership ladder” or so, because leadership is itself a very challenging craft that takes a lot of focus and effort to master.

What appeals to me more, but I haven’t seen yet in practice, is for orgs to let their technical leadership (both on the architect and people management sides) take periodic “coding sabbaticals,” or something along those lines. The main idea being that periodic returns to the hands-on work will help keep you sharp, up-to-date, and effective as a technical leader. The biggest problem with that is that it’s not always easy to just plug a “substitute leader” into the org chart while you’re on sabbatical.

I think this is a question of scale and hours in the day. In my experience when the team grows past 5 it gets difficult to do all the leadership things that “clear the road” for the team and also have enough focused time for effective programming. But at the same time, once you’re at that point, if you stop coding you can now handle another 5-10 direct reports. So you have to chose between keeping independent teams quite small with team leads who code, or with allowing bigger teams with a dedicated manager.

The scaling characteristics of those two patterns are different, because inter-team collaboration is pretty much always worse than intra-team, so the small teams are more effective if they are as independent as possible. If not you end up needing an extra manager to coordinate amongst the small teams... and now you have managers who don’t code.

Thank you for saying that, this was exactly my conclusion when reviewing my own goals and notes on how other companies build products. If your company doesn't have this special-projects track in place, then your only option at some point is to quit and start your own thing I'm afraid.