When tech companies market engineering careers, they advertise two parallel tracks. One is for engineers, the other is for engineering managers. Here is an example from Square, but you'll find essentially the same language in most tech company handbooks:

Becoming a manager is not a promotion: As discussed in more detail below, we define a promotion as moving up a level. When an engineer first becomes a manager, they remain in the same level and move laterally to the engineering management track. Again, we don’t want to incentivize becoming a manager solely for career advancement.
- Square's Growth Framework

One choice is no better than the other, they’re just different. Engineers write code. Managers act in a servant leadership role supporting engineers in their jobs. The two roles have a symbiotic relationship that enables everyone to thrive.

That's the pitch. But humans are both cooperative and competitive animals, and in the case of engineers and managers there is an obvious power imbalance. Engineering managers know your compensation while you don't know theirs, they carry out your performance reviews while you have limited input into theirs, they are the gatekeepers to your advancement while you aren't on a critical path to theirs, and they are the ones who formally initiate your termination while you have no formal authority to initiate theirs. This looks important, but the competitive aspect of the two tracks is never mentioned. Why?

One way to think of technology companies is as giant, very complex printing presses capable of printing nearly infinite amounts of money, and of engineers as mechanics with the skills to maintain these machines. Without the engineers the presses jam and the money supply disappears. There is no way around this for now. That's why the engineers are hired, and that's their primary source of power.

They have other tailwind too. The machines are sophisticated. Knowing how to maintain them requires a high IQ and a psychological makeup conducive to abstract symbol manipulation for hours on end. These qualities are rare, so the labor supply is limited. On the other hand between FAANG, Microsoft, thousands of smaller firms, and large non-engineering firms that require engineering talent, the demand for the limited labor supply is enormous.

The primary limit to engineers's power is that firm owners learned to design the printing presses in a way that compartmentalizes and replicates the knowledge necessary to maintain them. As of 2018 the tech sector had the highest turnover rate at 13.2% out of every single business sector. This rate is likely higher specifically for engineers. For example, the turnover rate for embedded software engineers is 21.7% annually. These numbers are presented as evidence for power on the side of labor. But a different way to think about it is that technology companies can nuke 20% of their engineers (likely considerably more), and the machines will keep ticking. The firms traded money for redundancy. The recruiting operation is expensive, but that's fine because the firms have an infinite supply of money. What they get in return is leverage— it's impossible for engineers to stop the machines.

Another implication of compartmentalization is that it severely restricts salary variance between engineers of different skill levels. For example, Google engineer salaries range from $188k for a new grad to $1.35m for principal engineer, or a factor of ~7. That may seem like a lot, until you consider that the productivity range between the best and the worst engineer on a team can be a factor of 100x or more. Surely some hyper-productive engineers at Google make more than $1.35m. But overall, knowledge compartmentalization puts significant downward pressure on salary variance, which in turn acts as another limit on engineers's market power.

A natural incentive for engineers is to decrease compartmentalization in order to increase their own leverage. That's what they would do if they ran the firms. And since decreased compartmentalization is against the interests of firm owners, the owners can't put engineers in charge. This is why they hire engineering managers.

Unlike engineers, engineering managers have no natural source of power. In previous lives many of them ran the machines themselves, but there came a time when they've traded their role as craftsmen for the management track. Sometimes it's because they weren't good craftsmen in the first place and knew it limits their earning capacity. Sometimes they were good craftsmen who were seduced by the siren song of social status among the normies. Sometimes they genuinely wanted to support engineers in their work. But in every case, they can no longer fix the machines. Their power has to come from elsewhere.

Where does it come from? Since there is no natural source, firm owners must grant power to engineering managers by fiat. I already mentioned the substance of this grant— unilateral knowledge of your compensation and gatekeeping of your advancement via the performance review process, formal authority to initiate termination procedures, and formal authority to direct your work.

The power of engineering managers has limits. The engineers retained input into each other's performance reviews, can often choose their own work, and in many tech firms managers can't unilaterally fire them. From the firm's perspective, replacing an engineer is easy, but because of the tight labor market it's not that easy. And since engineering managers can't themselves fix the machines, they must relinquish some power in order to get engineers to keep the machines running.

Manager salaries are about the same as engineer salaries, which suggests power is balanced roughly evenly between the two groups. An even split is a lot! It means engineering managers have power equivalent to the people who keep infinite money generators alive. What could engineering managers be offering the firms that has such enormous value?

The official answer is servant leadership. Managers remove roadblocks so that engineers could do their jobs, act as information hubs so everyone is up to date on what they need to know, keep the bureaucracy in check so that engineers could focus, and do 1:1s to identify issues early.

If we grant these tasks are important, the evidence still doesn't fit. Why not let the engineers do this work? Why bundle control over someone's salary and advancement with removing roadblocks and handling communication? And why unbundle both from writing code? Is it really the most natural way to carve nature at its joints?

Neil Postman pointed out that technology and culture tend to become what he called mythic:

I have on occasion asked my students if they know when the alphabet was invented. The question astonishes them. It is as if I asked them when clouds and trees were invented. The alphabet, they believe, was not something that was invented. It just is. It is this way with many products of human culture but with none more consistently than technology. Cars, planes, TV, movies, newspapers—they have achieved mythic status because they are perceived as gifts of nature, not as artifacts produced in a specific political and historical context.
When a technology becomes mythic, it is always dangerous because it is then accepted as it is, and is therefore not easily susceptible to modification or control. If you should propose to the average American that television broadcasting should not begin until 5 PM and should cease at 11 PM, or propose that there should be no television commercials, he will think the idea ridiculous. But not because he disagrees with your cultural agenda. He will think it ridiculous because he assumes you are proposing that something in nature be changed; as if you are suggesting that the sun should rise at 10 AM instead of at 6.

This observation is true about management culture too. Bundling control over salary and advancement with directing work and handling communication is not a natural law. It was invented. For example, IBM experimented with a Chief programmer team structure, modeled after a surgical team. Under this management technology the designated administrator of a team handled people and money (among other things) and reported to the team's chief programmer, not the other way around.

Once you allow yourself to think of engineering management structure as a problem to be solved rather than a natural law to be heeded, you can imagine endless possibilities. You could have the dreaded architects / implementers model, where one person designs the architecture, his underlings implement it, and he evaluates their performance. You could model it after university departments, and pick a random engineer for a quarter or two to do the unpleasant administrative tasks; then have them go back to coding. You could allow every team to organize itself however it desires. You could do what Larry Page once did: fire all the managers, and have every engineer in the company report to one person. You could try different ways of management on isolated projects, and expand them if they prove to work. There is no end to what you could do.

Why then, did every major software company settle on parallel tracks? What advantage does this management structure have over every other possibility? This is especially puzzling given the reality of working under such a system— in practice, parallel tracks always evolve into two overlapping status hierarchies.

The first is an informal prestige hierarchy. In a company of 1,000 engineers, there are ~50 engineers who can fix any bug, resolve any incident, implement any feature. They know how to evolve the codebase to support any necessary change. They aren’t just technical leads— they understand the business of software, and they can tell a good engineer from a bad one in a blink of an eye. Everyone knows who they are, and everyone goes to them for guidance, not because anyone ordered it, but because human tribes naturally form prestige hierarchies based on competence.

The overlapping hierarchy is one of dominance and consists of engineering managers appointed by fiat. They make you use Jira, invite you to slightly awkward weekly 1:1s and inform you about the missing qualities that stand between you and more money. Sometimes they help get resources and resolve various personnel conflicts. Otherwise they disappear into meetings with people who have nothing to do with your product or team, presumably for very important reasons.

Like the church and state in medieval Europe, the two hierarchies govern the same polity from somewhat different angles. Initially the relationship oscillates between symbiotic and adversarial. Over time the rough edges get filed off, the gears get lubricated, and mostly the two hierarchies learn to stay out of each other’s way.

This relationship is the most important property of the parallel tracks system. On its face, everything looks no different than any other function in any other business. Engineers report to engineering managers, who report to more managers, and eventually somebody reports to the CEO. But if you squint at it, in every way that matters engineers and engineering managers work in different orgs. They have different goals and different philosophies. They follow different incentives, admire different people, emulate different role models, use different language, play different political games. And since humans develop loyalty toward their in-group, from the firm’s perspective the one big advantage is that under this system engineering managers don’t develop any loyalty toward engineers whatsoever.

You can see this if you examine what engineering managers do. Becoming an L5 manager in a big company is supposed to be a considerable challenge. But unless you're an idiot, it will be the easiest job you ever have. All you have to do is plug yourself into the calendar and set your brain on autopilot. Go to the meetings you're supposed to go to, say the acronyms you're supposed to say, update the spreadsheets you're supposed to update, and don't do anything that may compromise the system. Do that, and you will be promoted. Do anything else, and your performance will permanently need improvement, until you give up and go back to programming. You have only one job as a new manager— pass the company's compliance test.

After that, things become more interesting and you get introduced to progressively more sophisticated political games. Whatever loyalty to engineers you may have left gets incentivized out of you, and if the incentives don't work it's back to permanent "needs improvement" until you self-select out. You continue saying the right things and pretending to care about what the engineers think. You give them what the labor market requires so they keep the machines running. You make sure their work is compartmentalized to prevent them from acquiring too much power. And you guard the pores of the managerial org to ensure no one with loyalty to engineers seeps through.

That's the equilibrium. The engineers get to write code and believe they run things. Engineering managers get very cushy jobs and believe they’re doing productive work. The machines keep running. Nobody is especially happy, but everyone is making a lot of money in exchange for doing little work, so there isn’t anything to complain about.

Or is there? Major cultural change in software companies seems to be governed by punctuated equilibria. Microsoft’s culture was very different from IBM. A quarter century later, Google’s culture was very different from Microsoft. It has been almost a quarter century again. Perhaps it’s time for another change.

Zero Credibility

Parallel tracks