Dev managers of r/ExperiencedDevs: if you tend to tell your reports that they're in charge of their own promo consider an alternate strategy.

At my current career stage, I'm gearing up for a transition into a Sr Dev role at a FAANG, and I've butted up against a philosophy that seems at once encouraging and also deflective. Lately, I've also come to the conclusion that this way of thinking is harmful to company, org, and team goals. This way of thinking about promotions, i.e. that the person being promoted should take full ownership of the process, seems to me to only serve as a filter for developers who are comfortable in their current position and therefore won't end up pursuing a promotion, regardless of whether they are already operating at that level. This saves their manager time, and saves their company money, as they'll languish at a lower-paying level while doing higher-level work.

The idea that developers are captains of their own promo ship is at least mildly disohonest. For any process that I could be considered a reasonable owner of, I have visibility into the stakeholders, the inputs, the mechanisms, and the outputs. From my observations and discussions with colleagues, both at my FAANG and other companies, most promotion processes are actually opaque at best, and black boxes at worst. The mechanisms for gauging the wind, charting a course, and steering the ship sometimes simply don't exist.

As a process, promotions into senior roles are justifiably hard. There's documentation to review, peer interviews to conduct, work artifacts to be examined, entire panels to schedule and conduct. It's a huge time drain, and it absolutely does distract from other objectives. In fact it's such an arduous process that it's easy to see why it may entice dev managers to pass it off: it may seem like delegation. Less work to do.

But there's a positive side to the idea, too. In certain contexts, it can be encouraging to hear that you can take charge of your own promotion; that you own what artifcats get presented; that you have influence over what work you can plan out for the coming months that you will get you into some next-level criteria. Unfortunately this very often conflicts with the truth.

As dev managers, it's in your purvue to find next-level projects for your devs. It's on you to identify who's ready, who needs coaching, how the process works, how to navigate it, who the stakeholders are, etc. Be their greatest advocate and their most effective facilitator. Don't tell them that the buck has passed to them, and that not only do they have to deliver on their work but they also have to navigate an opaque and possibly byzantine bureaucratic process. That's your job.

You can choose not to do that, and instead insist that your developer take the helm. If you want to grow a team and be effective at delivering longitudinal goals, you're setting yourself up for a hard time. Motivated, effective developers won't tolerate having to build the gallows that they'll be hung on. Instead of spending months examining and executing on arbitrary bureaucracy, they'll opt to interview externally.

In short, if you tell your developers to own their promotion, they will. It just might not look like what you intended.