A Plan to Turn Engineers into Managers

Very true. Engineering is the hard way up, because there's so much less of the title and grade and salary inflation on the management track. Take Google. If you're a manager and don't make Director in 5 years, you fucked something up. On the other hand, the Director-equivalent Principal Engineer rank is 3 jumps (all of them non-trivial to make) above Senior. When I was at Google (and this is probably no longer true) the number of Principal+ Engineers at Google NYC was... zero.

The cynic in me suspects that dual-track organizations actually serve management's goals by making it look rank-per-rank superior, just as the lopsided college admissions climate convinces middle-class public school kids that prep kids who get into Harvard are somehow impressive (because it is very hard to get into an Ivy from a middle-class background, but really easy for rich legacy kids). If you make it astronomically difficult to become a VP-equivalent engineer, then the VPs (who had a much easier climb) look more impressive. Far from providing a genuine alternative path to success, this process cements the tribal superiority of management.

Most telling is that when Google really wants someone and is competing with finance or Facebook and gives them a High-Compensation Plan (HCP), the person is put on the management ladder, even if that person intends and expects to be a full-time programmer. It's really hard to justify a $500,000 salary for an engineer but much easier if you give that person a managerial title. I'd imagine that Google isn't alone in this. It's probably a standard big-company thing.

Engineers (and, in finance, also quants and strats) also share some of the blame for the relative grade deflation, because we beat each other up relative to businessmen. They give each other consistently high marks and talk each other up. We're far too honest. And this "honesty" is something I've come to view negatively because what it really is, is ratting someone out to management, often cheaply or for free. My inclination, if they aren't hurting me or a project that I care about, is to protect underperformers, not because I like it when people underperform, but because information is power and I'm not going to share honest performance information on other people unless there is a legitimate reason to do so. (I care if someone is fucking up my project, or an existential threat to the company or my career. I don't care if he's costing someone else's company a salary while doing nothing; that's not an existential threat, so who cares?) But engineers have a storied history of being willing to tear each other down for cheap or even for free, and technology management has been exploiting our lack of tribal cohesion, in order to turn us against each other, for decades.

The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business". Hence, all that Agile/Scrum bullshit in which engineers just churn tickets, rather than making meaningful technical decisions and building projects of increasing scope. No one who has any leverage and talent wants to work in that way. This becomes self-perpetuating, because even though there are good people who stick around (usually, with kids in expensive private schools, or uninsured sick relatives) the assumption becomes that good engineers leave after a certain point and, thus, that anyone left isn't any good.

For me, I only enjoy coding if it's part of a bigger whole, and if I am proving something in doing so. If I'm stuck in a ticket shop and can't leave for 2 years for some reason, I'm going to manage (preferably officially; unofficially via aggressive delegation if necessary) because I was done with that junior-level business-story coding several years ago. I graduated out of it long ago, and I won't be put back there like Billy Madison.

I interviewed somewhere that specifically mentioned #1 in the job description. I applied in part because it was the only job ad I had seen to that point specifically mentioning it.

It was brought up again in the interview as a perk of the job, by the person who would be my boss, without my prompting. In the very next sentence he made a generalization about being confused as to why developers would not willingly work 45-50 hours a week as a rule and how "40-hour clock watchers" never lasted long at the company.

The cognitive dissonance was staggering.