The Leadership Pipeline

What changed when I moved from writing code to building a team that could make decisions without me.

Feb 28, 2025

I used to catch myself reviewing code late at night after becoming a manager. The work was familiar, but it was no longer the highest-leverage place for me to spend time. My role had changed from producing an answer to helping the team produce and evaluate answers.

This is the leadership pipeline as I have experienced it: a sequence of changes in where judgment, context, and responsibility sit. The stages overlap, but the following situations made the changes concrete.

1. Letting someone else solve the problem

As a developer-turned-tech lead, I once saw a junior engineer struggling with an application performance issue. My first instinct was to take the keyboard and fix it. Instead, I sat with the engineer, asked questions about the slow path, and let them drive the debugging.

It took longer than doing it myself. The engineer fixed the issue, learned how to investigate it, and was more confident the next time. I learned that coaching is not a softer version of implementation; it is a different kind of work. The test is whether the person can handle a similar problem without me.

2. Trusting the team under pressure

I learned the same lesson during a Friday production incident. I was in transit with only my phone, so I could not join the debugging directly. The team isolated the problem, shipped a patch, and documented the root cause without me in the room.

That incident changed how I delegate. I still ask about failure modes, user impact, and rollback plans, but I try not to prescribe the implementation. A useful boundary is: the engineer owns the solution; the lead owns the context, the risk, and the support needed to make the decision safely.

3. Influencing people who do not report to me

During a product launch, a backend component owned by another team became a likely bottleneck. I could not reprioritize that team's work, so I brought the two teams together around a shared outcome: protect the launch and reduce reliability work for the service owners.

We agreed on a fix and shared the implementation rather than treating the dependency as someone else's problem. Since then, I have found that cross-functional influence works best when the conversation starts with user impact and constraints, not with a request for a favor. Product, design, infrastructure, and engineering may use different language, but they can still work from the same risk and outcome.

4. Making a decision people may dislike

In one release, we found a performance issue shortly before launch. Marketing had already announced the date, and some people argued that we could patch the problem later. After speaking with tech leads, Product, and Support, I delayed the release by a week.

The decision was not based on a belief that every issue deserves a delay. It was based on a simpler rule: we knew the issue would hurt the user experience, and we did not yet understand the failure boundary well enough to ship it. The extra week gave the team time to fix the problem and test the upgrade properly.

Leadership decisions rarely come with complete information. I try to make the reasoning explicit, ask the people closest to the work for input, and own the result when the decision is mine.

5. Creating capacity beyond the current roadmap

At one point, a face-recognition system was growing faster than its backend could handle. The team was spending too much time reacting to scaling issues, so I made the case for an architectural project that could support roughly 10x the current load.

The work was not on the feature roadmap. I connected the investment to downtime, customer risk, and engineering time, then broke it into phases that could run alongside product work. Within three quarters, the platform was handling loads that would previously have overwhelmed it.

Strategic leadership is often this unglamorous: noticing a repeating constraint, naming its business cost, and creating room to address it before it becomes an emergency. It also means preparing people for the next version of the team. I look for engineers who can own a larger decision, give them context and a real opportunity to lead, and stay available without taking the work back.

The move into leadership is not a promotion from “doing” to “not doing.” It is a move from solving one problem to improving how a group solves problems: through coaching, clearer boundaries, better decisions, and enough long-term capacity that the team does not need one person in every room.