Every engineering leader knows the feeling. A high-priority request comes in and your mind immediately begins to decompose the problem. You see the solution in functions and classes, the database queries, the elegant logic that will fix it all. This is the individual contributor's mindset: the direct, tangible, and deeply satisfying process of building a solution with your own two hands. It's what made us successful in the first place.
For years, I believed that leaning into that instinct was the most valuable thing I could do. I was the senior engineer, the leader; it was my job to solve the hardest problems. But that instinct, the very one that makes a great engineer, can become a leader's biggest liability.
I've since learned that my true value lies not in solving the problem myself, but in building a team that knows how, and giving them the space and support to do it. It required a fundamental shift in my thinking, from "How can I fix this?" to "How can I create an environment where this gets fixed?".
The High Cost of Disruption
Deep, focused work like software development and high-context, interrupt-driven work like leadership are fundamentally at odds. Anyone who codes knows the feeling of being "in the zone." It can take an hour to load a complex problem into your head, and a single, five-minute interruption can wipe it all away.
Now, imagine a day filled with budget meetings, one-on-ones, strategic planning sessions with other executives, and urgent escalations. The context-switching overhead is enormous. You end up writing mediocre code because your focus is fractured, and you provide mediocre leadership because your mind is still on a tricky debugging problem from that morning.
When a leader is buried in a feature, they develop blind spots. They miss the subtle signs of burnout in a key engineer. They are not fully present for a discussion about the product roadmap. They might overlook a critical security notice because they were just trying to finish one last function. My responsibility is the entire technology ecosystem-from our Kubernetes infrastructure to our data warehouse operations. I cannot effectively manage that risk or see the opportunities if my field of view is narrowed to a single file in a code editor.
The "Do As I Say, Not As I Do" Trap
There is another, more subtle danger when a leader actively writes code: becoming a hypocrite. As leaders, we spend the bulk of our time establishing best practices and guardrails for our teams, including code reviews, comprehensive testing, and clear deployment processes. We hold our engineers accountable to these standards because they ensure quality and stability. But when we put on our individual contributor hat, we may often bypass the very rules we created.
Let's not count how many times in my early days I pushed what I deemed an "urgent fix" directly to production without a proper code review. It is an easy trap to fall into, especially when you run a global team and there is no one immediately available to review your change. You tell yourself it is for the sake of speed, that you are saving the team from being blocked.
But the message this sends is corrosive. It tells your team that the process is optional when things get inconvenient. It undermines the engineering culture you are trying to build and erodes the trust your team has in your leadership. Your most important job is to be the champion and guardian of the team's process, not the exception to it.
Building the Factory that Builds the Machine
As a leader, my definition of "building" had to change. I no longer build features directly. Instead, I build the factory of machines that build the features. This means my attention shifted to optimizing our systems, our people, and our processes. My goal is to remove friction and become a force multiplier for my entire team.
For instance, before I rolled out a company-wide task management solution, I saw the symptoms of a broken system everywhere: duplicated work, confusion over priorities, and a general sense of frustration. No single feature I could have coded would have fixed that. By stepping back and solving the systemic problem, I unlocked more productivity across the organization than I ever could have with my hands on the keyboard.
Similarly, our migration to AWS EKS was not just a technical exercise. We were facing real business challenges with deployment bottlenecks and our ability to scale during peak traffic. Leading that initiative was an architectural and strategic challenge. It was about enabling the entire company to move faster and more reliably. That is the leverage point for a leader.
Delegation Creates Ownership and Growth
I learned this lesson the hard way in my early years as an engineering leader. My strategy for assigning tasks was simple: I matched the difficulty of the project to the experience of the engineer. The most complex, mission-critical projects? I kept those for myself.
It was not because I was excited to do them. It was a matter of perceived efficiency.
I knew that delegating a complex project meant it would take longer. It would require multiple review cycles, and I would have to set aside significant time for exhaustive code reviews to ensure our conventions and best practices were followed. This was before we had many of the automated processes that streamline development today. In my mind, doing it myself was the path of least resistance.
The result was predictable. We kept up with our deadlines, but I was burning myself out. Meanwhile, my engineers were bored. They were underutilized, unchallenged, and, even worse, not learning anything. I was so focused on the immediate goal of shipping a project that I failed to see the long-term cost. I was hitting my deadlines, but I was failing my team.
It was a critical mistake, but one that fundamentally reshaped my understanding of leadership. When I finally started handing off those complex projects, everything changed. I saw a mid-level engineer's confidence soar after they successfully architected and delivered a major feature. I felt my own stress decrease as I was able to focus on unblocking the team instead of being the bottleneck myself. My job was not just to deliver projects; it was to build the team that could deliver any project.
How to Stay Technical Without Writing Production Code
Stepping away from the keyboard does not mean becoming technically irrelevant. It is about evolving your technical contribution. It is no longer about being the best coder in the room; it is about having the architectural vision, understanding the trade-offs, and guiding the team to make smart, sustainable decisions.
Here is how I stay deeply engaged with the technology:
-
Lead Architectural Reviews: When we map out systems, I focus on asking the second and third-order questions. "How will this scale to 10x our current user base?", "What is our rollback strategy if this deployment fails?", "How does this decision impact our operational costs over the next two years?".
-
Review Pull Requests Strategically: I had to train myself to stop commenting on variable names. Now, I scan for architectural soundness, security vulnerabilities, and sufficient test coverage. My role is to protect the long-term health of the codebase, not to nitpick syntax.
-
Build Proofs-of-Concept: I maintain a "strategic sandbox." This is my space to experiment with new technologies, like our early machine learning initiatives. It allows me to have informed, credible discussions about new tech without parachuting into my team's production workflow and disrupting their roadmap.
-
Mentorship: My perspective on mentorship was fundamentally reshaped by my time as a lead instructor for a full-stack development bootcamp, guiding cohorts of career-switchers. My role wasn't to provide answers, but to teach them how to think like an engineer, a mindset I now bring to my team. My goal is to ask the right questions and create an environment where my engineers can have their own breakthrough moments, which is more satisfying than any feature I could ship myself.
This journey is about redefining your identity from an individual contributor to a team builder. True technical leadership is not about being the hero who ships the critical feature at the last minute. It is about building a team of heroes who can do it without you. The ultimate measure of your success is not your own output, but the combined, amplified output of your entire team.
