If you are an Engineering Manager who used to code every day, it is only natural to miss it. The clarity, the flow, and the satisfaction of shipping something with your own hands and seeing immediate results.

When you step into an Engineering Manager role, especially if you come from a software engineering background, this is often where the transition hits the hardest. You are used to writing code, getting it to work, and feeling a strong sense of gratification from the effort you put in. That feedback loop is short, visible, and deeply rewarding.

In management, that loop changes significantly. Your time is now spent in meetings, mentoring, coaching, strategic discussions, and decision making. The impact is still real, but it is delayed. You may not be able to point to something concrete that you built today or even this week. The dopamine hit you were used to is suddenly gone.

So how do you stay energized without becoming a bottleneck for your team?

That is what this post explores.

It Is Okay to Miss Coding

Missing coding does not mean you made the wrong move into management, particularly when the transition itself was complex or unplanned, as I describe in From IC to EM: A Practical Transition Guide. More often than not, it simply means you care deeply about the craft.

This feeling is extremely common, even though it is rarely talked about openly. Many Engineering Managers quietly question their decision because the work no longer feels tangible. Early on, I used to joke that if someone asked me what I did on a particular day, I might not have a clear answer. Not because I was not busy, but because the work I was doing had long term effects rather than immediate outcomes.

That can feel uncomfortable. You might feel like you are not accomplishing anything. You might even regret stepping into the role. Those feelings are natural, and they are not a reflection of whether you made the right or wrong decision. Management work compounds slowly, and its value often becomes visible only after months.

Later in this post, we will talk about how to intentionally decide whether this role is right for you in the long run. For now, it is important to understand that simply missing coding is not enough to conclude that you chose the wrong path.

Staying Close to Code Without Owning It

If you want to stay close to technology and code, there are ways to do it without taking ownership away from your team or slowing them down.

Some practical options include:

1. Fixing low risk bugs that are not time sensitive and do not block others
2. Contributing to internal tooling or cleanup efforts that improve developer experience
3. Building small prototypes or spikes to explore ideas before handing them off
4. Investing in personal side projects that keep you sharp without creating team dependencies
5. Reading and reviewing pull requests to stay familiar with the codebase and common patterns

For example, I recently built a small backend application to generate reports from data stored in DynamoDB. Since the data could not easily be plugged into a visualization tool, I transformed it into a relational structure and layered visualizations on top. It allowed me to write code, stay engaged technically, and solve a real problem without impacting team delivery.

Another example is this very blog. Instead of using an existing blogging platform, I built it from scratch. That decision gave me full control over how the blog works, kept me engaged by coding regularly, and aligned with longer term goals around introducing tooling into the platform.

Reading and reviewing pull requests is another powerful lever. It keeps you close to the codebase, helps you understand how your engineers think, and gives you insight into strengths and growth areas without you needing to own execution.

Understand the Tradeoffs

Just because you can do these things does not mean you should always do them.

Every technical task you take on comes with a tradeoff. The worst outcome is committing to work that you do not have the time or focus to finish. When that happens, the team waits, dependencies pile up, and momentum slows down.

Before you pick up any coding work, it is worth asking yourself a few questions:

1. Will someone be blocked if I do not finish this on time
2. Am I doing this to help the team or to satisfy my own urge to code
3. Can this be handed off cleanly if priorities shift

Your role as an Engineering Manager is to optimize for team flow and team success. If your involvement threatens that, even unintentionally, it is usually not worth it.

Being Technical Without Writing Code

Coding is only one way to be technical, and it is not always the highest leverage one.

You can stay deeply technical by being active in design documents and architectural reviews. Helping shape decisions early often has more impact than writing a single feature.

You can also host internal tech talks or learning sessions based on tools or concepts you have explored. Even spending a few hours learning something new on a weekend can pay off when you share that knowledge with the team.

Staying current with new technologies, frameworks, and tools is another important aspect. Being able to assess feasibility, tradeoffs, and risks when product proposes new ideas is a core part of technical leadership.

Being technical is about curiosity, context, and fluency across the system, not about clinging to implementation details, a distinction I explore more fully in Staying Technical as an Engineering Manager. It is not limited to committing code.

When Missing Coding Is a Bigger Signal

Sometimes missing coding is not just nostalgia. Sometimes it is a signal.

If you consistently find that you prefer being in the weeds, solving problems hands on, and avoiding people and process work, it may be worth reconsidering your path. Moving back to an individual contributor role is a valid and respected choice at many companies.

The key is to make that decision intentionally. Do not drift into it, and do not cling to coding in ways that hurt your team. Be honest with yourself about what you want your career to optimize for at this stage of your life.

Final Thoughts

Missing coding does not mean you made the wrong decision to become an Engineering Manager. It is a natural response to losing fast feedback and visible output.

What matters is how you respond to that feeling. Do not cling to code at the expense of your team. Your success as a leader is measured by team delivery and team growth, not by individual output.

At the same time, there are many ways to stay technical, with or without writing code. And if you decide that this role is not right for you, make that choice intentionally and strategically.

As a leader, the team comes first. When the team succeeds, you succeed.

---

What do you do when you miss the feeling of building? I would love to hear the strategies that have worked for you.