Losing Touch With the Code: The Quiet Fade of the Hands-On Manager

Steve Jobs had a knack for hitting the nail on the head. He once said:

You know what's interesting? You know who the best managers are? They're the great individual contributors who never, ever want to be a manager but decide they have to be a manager because no one else is going to be able to do as good a job as them.

I don’t know about you, but that quote resonates deeply. For many of us, moving from writing code to managing people can feel like stepping away from what we love most. There’s something uniquely satisfying about solving a tough bug or shipping a feature that works seamlessly. The fear of losing that connection is what makes so many engineers hesitate to take on management roles.

In my case, I’ve found a middle ground. I’ve led projects, stayed hands-on, and guided technical direction across teams. I haven’t been the “classic” manager who schedules one-on-ones or spends days deep in spreadsheets, and honestly? I like it that way. It’s rewarding to lead at a technical level and still feel the thrill of shaping the work that ships.

But let’s be real—it’s not easy. The gravitational pull of meetings, planning, and “management stuff” is strong, and it takes deliberate effort to stay close to the work that drew us in to begin with.

The Tension Between ICs and Managers

Here’s the crux of the issue: when you’re an Individual Contributor (IC), your work has a tangible impact. You write the code, solve the problems, and can point to something concrete at the end of the day.

But as a manager? Your job is to enable your team to shine. You become a multiplier, guiding others to deliver results greater than the sum of their parts. The work is impactful, sure, but it’s indirect. And for someone who thrives on technical problem-solving, that shift can feel, well… a little empty.

This is the “slow death of the hands-on engineering manager” that Zaid Essanton talks about in his article. As responsibilities pile up, staying technical becomes harder and harder. Before you know it, you’re so far removed from the code that you can’t even remember how the build system works.

How I’ve Stayed Technical

For me, staying connected to the work has meant carving out a role that aligns with my strengths. I focus on project ownership—leading the technical direction, mentoring the team, and keeping my hands in the code where it makes sense. Here’s how I balance it:

1. Own a Project, Not Every Detail:
   Taking responsibility for a project’s technical direction gives you a way to guide the work without micromanaging. It’s about helping the team see the big picture and solve the right problems, while still jumping in when your expertise can unblock progress.

2. Pick Your Battles:
   There’s no way to be hands-on with everything, so I focus on areas where I can make the biggest impact. For me, that’s architecture, mentoring, and key technical decisions. I might not write the code for every feature, but I’m there when it matters.

3. Build Context for the Team:
   One of the best parts of leadership is helping the team understand the “why” behind the work. When everyone’s on the same page, it’s easier to step back and let the team execute—without losing touch with what’s going on.

4. Keep Your Tools Sharp:
   Even if you’re not writing code every day, stay curious. Dig into new technologies, review PRs, or experiment with side projects. The goal isn’t to be the “10x coder” but to keep your technical edge.

Bridging the IC-Manager Gap

For ICs who want to take on more responsibility without leaving the code behind, project ownership is a great middle ground. It’s a chance to build leadership skills—managing implementation, mentoring teammates, and driving outcomes—while staying close to the work that makes engineering so rewarding.

And for those of us already in leadership? It’s about being intentional. Don’t let the meetings take over. Fight for time to do the work you love, and build a culture where technical contributions from managers are valued.

A Call for Change

Essanton makes a great point in his article: companies need to do more to support hands-on managers. That means redefining roles, rewarding technical contributions, and creating space for leaders who don’t fit the cookie-cutter “manager” mold.

If we don’t? We risk losing some of the best technical minds to burnout—or worse, turning them into managers who can’t remember what it’s like to actually build something.

Final Thoughts

Leadership doesn’t have to mean stepping away from the keyboard. By redefining what it means to lead, we can stay connected to the work that inspires us while empowering our teams to thrive.

So if you’re feeling stuck between writing code and leading people, take heart. There’s room for both. And if you’re struggling to find that balance, I’ve been there. It’s tricky, but it’s worth it.

Want more thoughts on how to build a career you love while staying true to what you’re passionate about? Check out Essanton’s article for more inspiration—and let’s keep this conversation going.