4 min read

Engineering career ladders are made up, just like money and the government

There is no god of engineering career ladders, handing down tablets to chosen prophets.
Engineering career ladders are made up, just like money and the government

There are things that exist because people believe in them, and there are things that don't. Hurricanes don't stop existing if people stop believing in their authority. Governments do.

Things in the "requires believing in" category are still real. They still have power over the social and physical world. They don't stop existing just because one person stops believing in them. But they are animals of the imagination, and it's wise not to forget that.

This is especially true of the smaller imagination animals: Companies. Clubs. Individual families and friendships. And career ladders.

Career ladders – those pretty stacks of role descriptions, neatly laid out in sequence – can be useful. But they are created. They are objects of human artifice. They exist to accomplish goals. There is no god of engineering career ladders, handing down tablets to chosen prophets.

And for all their possible usefulness, they are also dangerous.

The Germans have a word, waldsterben, for "forest death." They discovered it after the initial failures of their rational, scientific, managed forests – simplified systems for producing and harvesting wood, that performed magnificently in the first generation, but tended to whither and die in the second.

From Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed

An exceptionally complex process involving soil building, nutrient uptake, and symbiotic relations among fungi, insects, mammals, and flora--which were, and still are, not entirely understood--was apparently disrupted, with serious consequences. Most of these consequences can be traced to the radical simplicity of the scientific forest.

How humans organize themselves socially is "an exceptionally complex process." Distributing resources within a corporation is "an exceptionally complex process."

The career ladder promises clarity. Simplicity. Fairness. A world where every engineer knows their place, and money, technical influence, and the respect of their peers award accordingly. There's something about humans, at least American professional class humans, that loves knowing our place a crisp, clear, numbered hierarchy. Even if we resent where we've been put on it, we like thinking we know.

The clarity that the career ladder promises is a fiction. It is a useful fiction, but humans have a habit of falling in love with useful fictions. Keep alert. Wear gloves.

The career ladder's linearity makes it a fertile home for other useful fictions. "Scope of impact." "Technical depth." Their upper limits – the most political, the most ad hoc – become littered with fancies. Patents! Conference talks! Industry influence!

Is an engineer who has multi-team impact, but using skills that can be had for far below the price of even a first-job engineer, truly a "staff" engineer? Is an engineer with multi-team impact always more valuable than an engineer who delivers deep, broad, consistent value to a single critical team? Is "team" a consistent size? Does being good at leading teams require being good at writing software individually? Does "company-wide" impact mean the same thing at Google as it does at a 100-person company? Does influencing the industry require being an excellent individual engineer? An excellent team lead?

At best, all of this falls away when it comes time for real managers to make real decisions. At worst, the company clings to its system and kills the forest.

Not that the individual judgement of individual managers is always superior to the written system– oh no. Managers make decisions all the time about who to promote, and who not, based on their individual feelings about individual engineers. Do they act the way the managers expect the engineers to act? Do they have the skills the managers expect an engineer to have? Do they make managers uncomfortable?

If you're an engineer, and you're looking to get promoted, the career ladder is a useful document. It is an excellent source of verbiage for your promotion packet. It is a good basis for conversations with your manager. But remember what it is. The career ladder will not, can not, make any decisions that matter to you. Humans will.  Give the written career ladder a measured, skeptical glance, not deep study. Note its inconsistencies, its ridiculousness, but don't waste energy railing against them. Spend the majority of your energy understanding those humans, and decisions they actually make.

Grumble about the unfairness of a system that requires your manager to be good at influencing a committee if you must, but remember that the process of evaluating individual performance in a complex, multi-dimensional system cannot be objective, simple, and clear. Promotion systems can be messy and filled with human judgement, or they can be dead. There is no alternative.

If you're a manager: Do your best to make a ladder that reflects the actual decisions that actual people are making. Ask why the criteria on it are the way they are. Ask whether you're retaining the people you intend to retain. Ask yourself, especially, whether you're promoting the people you need now, or the people you would have needed two years ago.

Use your ladder, but remember that you made it. Deviate from it when you need to. Improve it when you can. Don't worship it.


Hiring

Netlify is hiring a bunch of roles. Looks like a lot of infrastructure, release, PaaS, Go, product, and design/user research roles. Looks like a great spot for people who know and love Cloud Foundry Release Engineering, which I know describes at least a few folks reading this.

More places hiring engineers that I find interesting.

Reading

This essay on why we're so bad at making software and what to do about it is worth the 60(!) pages. It covers a lot of ground but my favorite point is that software developers really ought to take a page out of the film/creative industry's book and study other software.

Software development is a creative field. It has more similarities with filmmaking than it does with bridge-building. Develop a taste for interesting software and then talk to others about them. Discuss, disagree, find common ground and start again.
Software development manages somehow to be less reliable than both the creative industries and engineering while preserving many of the liabilities of both.

Honestly, if you put me in charge of software engineering education, I would take out about 80% of the math and replace it with creative writing, so this resonates. A lot of engineers are kind of naive about taste and aesthetics, and I think there's a straight line from that to our industry's clownish naïveté about design, requirements, and "best practices."