Who

The hardest of the four lines is the one we put first.

People over code is easy to nod at. It’s harder to actually do — because doing it means looking at how you hire, how you organise, and how you promote, and noticing that all three were designed for the kind of team that’s going away.

The org chart was a description of the crew’s overhead. The job description was a recipe for a crew member. The career ladder was a way of climbing out of the crew while still belonging to it. None of them were neutral. They were the bookkeeping of the building site. The site is changing.

So the question for this one: when the team is two and AI does most of the typing, who do you hire, who runs them, and what does it look like to get good at this for fifteen years?

---

The hire¶

The old job description was a recipe for a crew member. Five years of React, three of Node, exposure to Kubernetes, a list of frameworks like a cocktail menu. Senior, staff, principal — defined by years, by depth in a stack, by the ability to guide a team of juniors who would do the typing.

That recipe still works for crew engineering. It’s the wrong recipe for substrate engineering. AI knows the frameworks. Years in a stack matter less when stacks are portable. The team is too small to need a “senior who guides juniors”. The juniors aren’t there.

What’s left, when you take the framework checklist away, is harder to test for and more important to find.

Curiosity. The substrate engineer reads tickets but doesn’t believe them. They want to talk to the customer, watch the customer use the thing, ask the third dumb question after the first two answered nothing. That instinct doesn’t come from a coding test.

Recognition. The verification load is real. The substrate engineer can look at a screen full of AI output and say “good”, “wrong”, or “not yet” in a few minutes — because they’ve been around enough good and bad that the patterns are in their hands. This is unteachable in the abstract and inseparable from time spent looking at real code.

Range. Frontend, backend, ops, data — the lines are softer now and the substrate team works across all of them. The engineer who can only do one is a specialist for a job that’s contracting.

Self-direction. Nobody’s filling your queue. The team picks the work, verifies the work, faces the customer. The engineer who waits to be told what to do has no role in the team that doesn’t tell anyone what to do.

None of these are soft skills. They’re the substantive skills of substrate engineering, which is what engineering is becoming. The hiring loop most companies still run — leetcode, framework trivia, system design with a whiteboard, behavioural questions for “leadership potential” — selects against several of these and for none.

The companies hiring well right now aren’t running better leetcode. They’re putting candidates in front of real problems with real customers and watching them think.

The boss¶

The manager role was crew coordination. Sprint planning, calendar tetris, performance reviews of seven people, status updates up, status updates down, Jira hygiene, escalations, the careful negotiation of who is a 7 and who is an 8 on the impact scale this half.¹ Most of the manager’s day was the cost of having a crew.

When the crew is two, most of that cost vanishes. A pair doesn’t need sprint planning — they need a conversation. A pair has one performance review at a time. The status update is the work being visible. The escalation path is talking to each other.

So what’s the manager for?

Three things, more or less.

The first is the cross-team view. Substrate teams are pioneers — each one out at the edge with a customer, making calls. The director or VP who used to coordinate a department now coordinates across teams. Spots where patterns are emerging. Notices when one team’s solution would travel to another. Sees when two teams are about to walk into the same problem. This is real coordination work. It just isn’t a standup.

The second is player-coaching. The lead engineer who’s still in the work, sitting in the customer’s office, pairing with the less senior engineer they’re growing. This is the role most engineering managers either grew out of or were promoted out of. It’s also the role that survives. The senior person who can’t show how to do the work has nothing to lead.

The third is hiring. The criteria changed and someone has to hold the standard. Most orgs delegate hiring to recruiters who haven’t realised what changed — the substrate org puts it in the hands of the senior engineers who know what good looks like, because there’s nobody else who can tell.

What dies, in this picture, is middle management as a place to live. The pure-coordinator role. The “I’m a people person now, I don’t code” trajectory. The career path that was a way of paying technical people without making them stay technical.

This is uncomfortable. There are real people doing those jobs and some of them are excellent at them. The honest answer is that the role they’re excellent at is contracting — not because they did anything wrong, but because the work it was overhead for is contracting.

The kind move is to be honest about it early. The unkind move is to keep promoting people into a job that’s disappearing.

The ladder¶

The career ladder is the bit most companies haven’t begun to redesign.

The old ladder: junior → mid → senior → staff → principal → distinguished, with a management track branching off somewhere around senior. Each rung defined by depth, plus scope, plus “people you influence”. The upper rungs almost always required distance — owning bigger systems, managing more managers, having “org-level impact”. You climbed by getting further from the work.

The substrate ladder doesn’t go up by getting further from the work. It goes up by getting better at it — where the work now includes verification, problem-finding, customer relationship, and judgement under uncertainty. A staff engineer in the substrate world isn’t running three teams. They’re sitting in three customers’ offices, holding the verification standard for the work happening in each, and making the calls about what to build next.

Years still matter. Pattern recognition is real. The engineer who’s seen ten releases knows the shape of bad before junior does, reads a customer ask in two seconds, has the trust loop with the customer already half-built. But the path stops requiring distance from the code, or from the customer, or from the day.

The promotion question changes. It used to be “is this person ready for more scope, more reports, more meetings”. It becomes: can this person hold the standard alone? Verify the team’s work. Find the right problems. Be trusted by a customer. Make calls without checking up. The senior level isn’t where you stop doing engineering. It’s where you become responsible for the engineering being right.

A substrate-shaped progression isn’t “you used to do, now you direct others to do”. It’s “you used to do work that needed supervision, now you do work that requires judgement”. The doing doesn’t stop. The work itself gets harder.

This is fine for engineers who like the work. It’s a problem for the ones who took the management ladder because they wanted out of the IDE. There’s a cohort of people who picked engineering management not because they wanted to coach but because they wanted promotion, and the substrate org has nowhere obvious to send them.

It’s also a problem for orgs that used the ladder as a retention tool. “If you stay we’ll make you a manager” doesn’t work the same way when management is a smaller, more specific role. The retention tool has to be the work itself — the customer access, the judgement we trust you with, the things we don’t make you do. The org that can’t articulate that loses its most senior engineers to ones that can.

What it asks of the org¶

None of this is small.

The hiring loop is owned by recruiters who learnt their craft for the crew era. The management ladder is owned by HR systems and a thousand performance plans. The career framework was probably built five years ago by a cross-functional committee with a deck.

All three are due for a rewrite. All three are politically expensive to rewrite. The substrate engineer who’s been arguing for two years that the leetcode loop is selecting against the people they actually want is correct. They’re also still losing the argument inside most companies, because the recruiters can show numbers — applications, conversion, time-to-hire — and the substrate engineer can only show that the people they’re hiring don’t quite fit.

The orgs that get this right do something the machinery resists: they put the engineers who do the work in charge of who else gets to do it. Of how those people are organised. Of how they’re promoted. Not because engineers are better at HR than HR. Because the work changed and the people doing it are the ones who can see what good now looks like.

That’s a culture move, not a process one. The substrate runs on it.

---

The substrate is people. Always was.

The org chart, the job description, the management line, the career ladder — all four are the org’s shadow on the work. Most of them were drawn for the crew. The crew is going. The shadows haven’t caught up.

Hire for the work the work has become. Manage the cross-cutting bits and stop pretending the rest is a job. Promote on the work itself, not on the distance from it.

Pay the engineer, not the rung.

Footnotes¶

1. Performance calibration grids. Most engineering orgs run them; few engineers think they measure what they’re supposed to. Defending one is half a manager’s quarter. ↩