Engineering Leadership

When the cost of building drops by an order of magnitude, the value of deciding what to build rises by the same factor.

This is not a metaphor. It is arithmetic. If a pair can ship in a day what used to take a sprint, the constraint is no longer velocity. It is direction. The person who sets direction just became the most leveraged individual in the org, and the job they hold is not what the old hierarchy meant by "engineering leadership."

Define what engineering leadership used to mean.

It was a blended role. Part people-manager (headcount, performance reviews, calibration), part program-manager (status reporting, cross-team alignment, executive translation), part technical-advisor (design reviews, architecture calls, mentorship). The blend made sense when building was expensive and coordinating the building required substantial overhead. The best engineering managers could do all three reasonably well and absorb the rest of the coordination load so their engineers could focus on shipping.

Most of that job was coordination. Meetings with other leaders to sync roadmaps. Calibration conversations to rank reports. Skip-levels. Status updates. Quarterly planning rituals. The design reviews and the one-on-one mentorship were the high-leverage parts, and they often got crowded out by the coordination work, which always felt urgent because it had the loudest deadlines.

When building gets cheap, the blend inverts. The coordination work is the first thing the compressed org kills, because the exhaust record, the stream briefs, and the telemetry do most of what the coordination layer used to do. What remains is the part of the old job that was always the hardest and the most undervalued. Taste. Mentorship. Problem curation. Technology unlocking. Not as a list the leader checks off, but as the whole shape of the work that is left once the ceremony is gone.

Each of those words hides a concrete behavior. Without the concrete, they are slogans.

Taste, rendered as a decision.

A pair proposes a service boundary between order intake and fulfillment. The architecture doc is clean. The sequence diagrams check out. The leader, reading it, says no. Put it between pricing and order intake instead. One sentence of reasoning: the fulfillment team in my last company made this exact split and every billing change for the next three years required touching both services. The team saves a month. The leader could not have derived that from the doc. It came from having lived through the consequence. That is taste. A specific recall, triggered by a pattern in a diagram, surfaced at the right moment.

Mentorship, rendered as thirty minutes.

A compliance officer has been filing tickets for two quarters to get a vendor-document reconciliation tool built. The leader, walking past her desk on Tuesday afternoon, stops and asks what the manual workflow looks like. The officer explains: she opens a CSV, copies cells into a vendor portal one at a time, names each file by hand, uploads, marks the row complete, moves on. The leader pulls up a chat tab. They describe the pattern together, paste a sample row, watch the officer refine the prompt twice, leave a bookmarked session. By minute eight the officer has a working script against a local copy of the file. By the end of the afternoon she has closed out the quarter's reconciliations that had been blocking her team for weeks. The leader did not touch the keyboard after minute eight. That is mentorship. Not a scheduled career conversation. Unlocking one person in the place where they were stuck.

Problem curation, rendered as a Tuesday routing move.

The leader's calendar shows a half-hour block on Monday morning. They open three things: the open stream briefs from last week, a spreadsheet of unclaimed work in the queue, and the roster of available pairs. They do not open a planning tool. They know which pair just shipped the adjacent surface area, which pair has been on compliance for three weeks and needs a harder problem, which pair is stale and needs a break from the stream they have been in. They route. The decision takes forty seconds per pair. It replaces the intake triage, capacity planning, and weekly status round-trip a traditional org uses to move people between teams.

Technology unlocking, rendered at scale.

The compliance moment from above generalizes. A leader in the compressed org is constantly asking a version of "what could this person build if they had the right tool and knew it existed?" They do not build the tool themselves. They identify the gap, surface the tool, and get out of the way. Multiply that by fifty pairs across a quarter and the leverage is larger than anything the old hierarchy measured.

There is a cost to working this way. An honest argument for the model names it.

The first cost is legibility. A leader whose primary output is decisions not made, services not built, and thirty-minute conversations that changed someone's quarter does not show up well in a performance review built for the old model. The metrics that made a traditional engineering manager promotable (headcount, scope, budget owned) are the metrics the compressed org intentionally stripped away. The leader has to be evaluated differently, or the best leaders will leave for an org that does.

The second cost is burnout of a specific kind. The old job had bad days and boring days. The compressed version has high-leverage days and empty days. When the pairs are routing themselves, the telemetry is reading itself, and nothing interesting is on the queue, the leader's calendar is empty. That is not failure. It is what success looks like in the compressed org, and leaders used to feeling busy can mistake empty calendar for irrelevance and manufacture work to feel useful. Manufactured work is the first layer of new bureaucracy growing back.

The third cost is relationships. A leader who stops running calibrations, stops doing status translation, stops mediating cross-team conflicts, loses the professional network those activities built. Some of that network was genuine. Some was ceremonial. The compressed org keeps the first and drops the second, which is right, but the transition is socially expensive for the leader going through it.

The balance is that the compressed leader is higher-leverage and lower-bandwidth than the traditional manager. They affect more, in a day, than a traditional manager affects in a week. They do it in short, concentrated bursts. They have time between the bursts, which the org should use for actual mentorship and technical work, not for manufactured coordination.

Status translation. Calendar management. The weekly ritual of aggregating updates from people who could have just shipped. Approval chains that existed to distribute blame. Headcount planning theater where the real game was empire-building. None of that is leadership. If your job title says "leader" and your calendar is full of meetings where you neither learn nor decide, you are not leading. You are administrating. Those are different jobs, and one of them is about to get very cheap.

The compressed org needs fewer leaders, and it needs them to be better. Better engineers who also lead. People who can pull a service boundary out of memory mid-conversation, unlock a tool for someone who did not know it existed, and route a pair to the work where their judgment multiplies. That is the job.

It is harder than managing. It is also the only version that was ever real.

Or just chat with the founder of SCI.