The Leadership Pipeline

Have I ever found myself reviewing my code at 11 PM, only to realize that I am now the manager and should not be doing all the coding? I certainly have. Transitioning from a hands-on engineer to a leadership role is a journey—a journey that many of us in tech lovingly (and sometimes frustratingly) call the “leadership pipeline.” It is the path I followed as I evolved from an individual contributor into a team leader, then a leader of leaders, and beyond. Each step brought new responsibilities and required a significant mindset shift. In this post, I share what worked for me while navigating my day-to-day life as an Engineering Manager. My approach has been inspired by leadership philosophies such as servant leadership and transformational leadership.

1. Mentoring and Letting Go

One of the first challenges in the leadership pipeline is transitioning from doing the work to leading the work. I learned this lesson the hard way. Years ago, as a developer-turned-tech lead, I was still diving into code head-first. I recall a sprint when a junior engineer on my team struggled with optimizing our app’s load time. My initial instinct was to step in and fix it myself. But that night, as I stared at a pile of code I had written for someone else, it hit me: this approach was not scalable. I was solving the problem of the moment rather than building the team for tomorrow.

The next day, I switched gears. I sat down with the engineer, and we debugged the module together. I asked probing questions, provided hints, and let the engineer drive the solution. Although it took longer than if I had done it alone, the payoff was huge. Not only was the bug fixed, but the engineer also learned how to resolve the issue and gained confidence. In turn, I practiced the art of letting go. Instead of trying to be the hero who does everything, I became the guide who develops others to achieve great work. I now offer this advice to every new tech lead: “Resist the urge to grab the keyboard; coach your teammates to victory instead.”

Making this shift is not easy. I often felt impatient or worried about the quality of the output. However, as a leader, my contribution is no longer measured solely by the code I produce—it is the combined output of my entire team. By mentoring junior engineers and delegating responsibilities, I extend my impact and begin building the next generation of leaders. After all, the junior engineer I coach today might become a tech lead tomorrow. Embracing the role of teacher and coach is a key milestone in my leadership journey—it’s about unlocking an individual’s potential and creating a multiplier effect within the team.

2. Empowering Autonomy: Trusting My Team (and Myself)

As I grew into management, another lesson became clear: I cannot be everywhere and make every decision myself—and nor should I. A strong engineering manager learns to empower team autonomy by trusting the people and giving them the space to solve problems in their own way, even if their approach differs from mine.

I recall an incident a couple of years ago when my team faced a critical production issue on a Friday evening. In the past, I would have jumped in, war-room style, to micromanage every fix. However, that day I was stuck in transit with only my phone. All I could do was communicate via chat and trust my team to handle the situation. To my relief, they resolved the incident, rolled out a patch, and documented the root cause—all without my direct intervention. Although I felt anxious (it is hard to sit back sometimes), I was immensely proud. This experience reinforced that when I empower talented people with ownership, they step up.

Empowering autonomy isn’t reserved solely for crises. On a day-to-day basis, it means allowing my team to make technical decisions and standing behind them. I encourage the engineers to take charge of their service or module by designing solutions and letting me know when they need support. I still ask questions like “Have all the edge cases been considered?” or “What might be the impact on our users?” to nudge them in the right direction—but I avoid dictating the exact solution. This approach not only prevents me from becoming a bottleneck, it also demonstrates my trust in their expertise. In my experience, when people feel trusted, they bring their best ideas forward.

For a new manager, relinquishing control can be uncomfortable. I often worried, “What if they fail?” yet I learned that leadership means creating a safe space for smart failures—minor missteps that ultimately lead to significant learning opportunities. I remind myself and my fellow leads that our job is to build an environment where the team can operate independently, allowing me to focus on higher-level priorities. In the leadership pipeline, shifting from controlling every detail to enabling others is crucial for scaling my impact beyond what I could achieve alone.

3. Influencing Beyond My Team: Cross-Functional Leadership

As I progressed further up the pipeline, I discovered that leadership is no longer confined to my direct team. As an Engineering Manager, I spend a significant portion of my time collaborating with product managers, designers, and other engineering teams. Influencing without authority became an indispensable skill—leading through influence and relationships rather than relying on an organizational chart.

I recall preparing for a new business launch last year when I realized that a backend component owned by another team was a potential bottleneck. Although I could not order that team to prioritize the fix (I was not their manager), I still needed to make progress. I reached out to the other team’s lead and set up a meeting. Rather than making demands, I framed the situation as a shared goal: our product’s success would benefit everyone, improving his team’s service reliability by reducing support calls and enhancing user satisfaction. We brainstormed and eventually agreed to collaborate on the fix, with my team lending support to theirs. This experience not only removed the blocker but also strengthened our inter-team relationship.

Effective cross-functional influence hinges on communication and empathy. With product managers, I focus on user impact and business value rather than merely technical details; with designers, I emphasize user experience; and with other engineering teams, I acknowledge their priorities and constraints while striving for win–win solutions. On a daily basis, I might negotiate timeline trade-offs with a project manager, persuade QA of a new automation approach (in my current organization, we do not have dedicated QAs), or rally support from the infrastructure team for a needed tooling initiative. I use persuasion, data, and personal credibility to lead colleagues who do not report directly to me. This shift—from direct control to collaborative influence—amplifies my team’s impact across the organization and prepares me for even larger leadership roles in the future.

4. Making Tough Calls: Decision-Making as a Leader

One of the less glamorous aspects of leadership is making the tough calls. As I advanced in the leadership pipeline, the decisions I faced grew more complex and far-reaching. It was no longer a matter of which bug I should fix first, but rather whether to prioritize one project over another or how to balance an urgent client demand against our long-term product vision. These decisions often have no perfect answer, and as a leader, I must navigate them and own the outcomes.

I faced one such dilemma when my engineering organization had to decide whether to delay a major release after discovering a last-minute performance issue. My technical instincts urged me to halt the release and fix the problem, while others argued that new features were more important to customers and that performance could be patched later. As the senior manager in the discussion, I felt the weight of the decision on my shoulders. After consulting with my tech leads and gathering input from Support and Product, I ultimately chose to delay the launch by a week. It was a nerve-wracking call, as I knew I would have to justify to senior leadership why we were holding back something that marketing had already hyped.

In moments like these, I realized that leadership can be lonely—but it is also when my principles and experience guide me. I leaned on a core value: “We do not ship anything we know will hurt the user experience.” The extra week allowed us to fix the performance issue and run thorough tests, resulting in a stable product and, a month later, positive feedback about the smooth upgrade. Equally important was my team’s reaction; they saw that I was willing to make a tough decision to protect both them and our users.

Tough calls come in many forms. Whether it involves restructuring team responsibilities, choosing between competing technical architectures, or making personnel decisions, the process is never easy. I often compare my team to a sports team: even legendary players like Sachin Tendulkar or Lionel Messi might not play every match, but that does not diminish their greatness. By gathering input from those closest to the issue—even the insights of a new engineer—and weighing short-term versus long-term impacts, I strive to be fair and transparent in my decision-making. Not everyone will agree with every decision, but if I remain honest and balanced, respect will follow.

5. Thinking Beyond the Sprint: Embracing Strategic Vision

When I am knee-deep in pull requests and daily stand-ups, it is easy to lose sight of the bigger picture. However, as I climbed the leadership ladder, I recognized that part of my role was to lift my gaze to the horizon. An engineering manager is not solely concerned with this week or even this quarter—I think about the next quarter or two, if not the entire year. Strategic thinking is a defining trait of higher leadership in the pipeline. It involves anticipating challenges, aligning engineering efforts with business goals, and ensuring my team is ready for what comes next.

In practice, strategic thinking takes many forms. For me, it often means critically reviewing technical roadmaps: Am I building the right foundation for where the product is headed? For example, there was a time when my face recognition system’s user base was growing faster than our backend could handle. My engineers were constantly firefighting scaling issues, and I realized that we were trapped in reactive mode. I set aside time with my team to brainstorm a proactive plan—an architectural overhaul to support 10× growth. Although this was not on the official roadmap, I had to convince leadership to invest in infrastructure work over new features. I gathered data on downtime and potential customer churn, and demonstrated how a scalable revamp would enable future business growth while ultimately saving costs and engineering hours. By connecting technical improvements to business outcomes, I became a champion of a vision rather than just an executor of tasks.

Eventually, I received the green light to pursue the scaling project. We broke it into phases, scheduled it alongside feature development, and within three quarters, our platform was handling loads that would have previously overwhelmed us. This forward-thinking approach positioned my engineering team as proactive partners to the business rather than mere coders waiting for requirements.

I often ask myself, “What skills will my team need six months or a year from now, and how can I start planting those seeds today?” Sometimes that means encouraging an engineer to learn a new technology I foresee as important; other times it involves succession planning—grooming a senior developer to become a tech lead so that when a new team is spun up or I move into another role, a capable leader is ready. Even in the midst of sprint planning and bug triage, I must consciously make time for these strategic priorities. Climbing the leadership pipeline means widening my perspective: shifting from the question “How do we succeed this sprint?” to “Where do we need to be in a year, and how do we get there?” This transformation from reactive to proactive, visionary leadership is not a solo effort—I involve my team in strategic thinking and am consistently surprised by the great ideas that emerge from informal architecture sessions or hack week projects.

Traveling through the leadership pipeline is an ongoing journey, and I consider myself a work in progress—learning new lessons at every twist and turn. The key is to remain adaptable and keep growing. Every stage of this pipeline—from mentoring my first direct report to setting strategy for multiple teams—requires evolution. I have shed old habits (goodbye, obsessing over every line of code) and developed new ones (hello, one-on-ones and roadmap presentations). It can be challenging, but it is incredibly rewarding to see both my teams and the products I work on flourish as a result.

As I grow, I am also responsible for grooming those who follow me—paying it forward. The junior engineer I mentored, the tech lead I empowered to make decisions, the peer I influenced through a tough project—each represents a building block in developing future leadership. It is like a relay race where I eventually hand off the baton, confident that the next runner is prepared to carry on, and knowing when to step back. After all, one cannot run a marathon alone if one is not fit.

I hope these stories and insights resonate with fellow tech leads and managers who know that many of these challenges are shared. I remain committed to being approachable, listening, and learning—embracing the fact that sometimes I am the learner and other times the leader. The leadership pipeline is not a straight line but a winding path with surprises along the way. With each step, I am growing not just my own career, but also the people and the culture around me.

I would love to hear your thoughts—what has worked for you?