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 fire team 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 -- who curates problems, who says "not that, this" with conviction earned from a decade of getting it wrong first -- that person just became the most leveraged individual in the organization.

Leadership in a compressed org means three things: mentoring, taste, and problem curation. Mentoring is not the annual career conversation where you fill out a template together. It is the Tuesday afternoon where you sit with someone who is stuck, look at their approach, and in ten minutes reframe the problem so they see a path they could not see alone. It is the pattern-matching that only comes from having built and broken enough systems that you recognize the shape of a mistake before it fully forms.

Taste is harder to define but impossible to fake. It is the architectural instinct that saves the team a month of wrong turns. The sense that a proposed system boundary is in the wrong place, not because you ran the analysis, but because you have lived through the consequences of that exact boundary in a previous life. Taste is what tells you the elegant solution is not the right solution because the operational reality will eat it alive. You cannot teach it from a book. You earn it by shipping things that broke and understanding why.

Problem curation is the most undervalued skill in engineering leadership. Most organizations let problems arrive through the org chart -- product says jump, engineering asks how high. In a compressed org, the leader's job is to look at the full landscape of what could be built and select the problems whose solutions create disproportionate value. This requires understanding the business at a level most engineering leaders never bother to develop. You need to know which customer problem, if solved this week, changes the trajectory of the product. Not the roadmap. The trajectory.

Then there is technology unlocking. I have watched a single conversation -- thirty minutes, a leader showing a domain expert a tool they did not know existed -- change the output of an entire team for a quarter. The leader who sees that someone in compliance is manually reconciling data that could be automated, who sits down and shows them how to describe what they need to an AI pair, who unlocks that person's ability to build -- that is leadership. It does not show up on an org chart. It does not have a Jira ticket. It is the highest-leverage thing you can do.

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

This is uncomfortable if your identity is tied to the territory the old model gave you -- the headcount, the budget, the dotted lines on the org chart. Those were proxies for influence, not influence itself. Strip them away and some leaders discover they have nothing underneath. Others discover they were always the person whose judgment the team actually relied on, and the title was just a label the org needed for its own legibility.

The compressed org needs fewer leaders, but it needs them to be better. Not better managers. Better engineers who also lead. People who can drop into the code when the architecture decision requires hands-on context. Who can pair with the most junior person on the team and make them dangerous in a week. Who can look at a system design and feel, before the metrics confirm it, that the abstraction is wrong. That is leadership when building becomes cheap. It is harder than managing. It is also the only version that was ever real.