Becoming Engineering Manager

Tue 20 January 2026

From Lead Engineer to Engineering Manager: Two Years of Relearning Everything

When I look back on my two years as an Engineering Manager, the clearest realization I’ve had is that this role is not simply a promotion. It is a career change. While the transition from Lead Engineer to manager may appear natural on the surface, the day-to-day reality demands a fundamentally different mindset. Many of the habits that once defined my effectiveness as a developer slowly had to be unlearned and replaced with an entirely new set of priorities.

As a Lead Engineer, my sense of impact was immediate and tangible. I could point to code I wrote, designs I reviewed, and problems I personally solved. As an Engineering Manager, that clarity faded. My impact became indirect, often delayed, and sometimes invisible. Over these two years, I’ve had to sit with that discomfort and redefine what success and progress truly mean in this role.

Redefining What “Productive” Means

Earlier in my career as an Individual Contributor, productivity was easy to measure. I knew I had a good day if I completed my tasks and delivered quality code. My output depended almost entirely on my own effort and focus.

That definition no longer works for me. As an Engineering Manager, my productivity is tied far more closely to my team’s output than my own. My work now creates leverage rather than deliverables. Over time, I began to understand that enabling the team to operate effectively mattered more than my personal contribution to any single task.

For the last two years, I’ve been working towards a state where the team can function independently. My ideal outcome is not to be involved in every decision, but to help build an environment where decisions can be made without me. I haven’t fully reached that point, and I don’t expect the journey to be linear. What has become clear, though, is that progress in this direction requires consistent investment in coaching, mentorship, and clarity.

It has also required me to remain open to feedback, especially from cross-functional partners and other managers. Some of the most valuable insights have come from understanding how our processes appear from the outside. That external perspective has often challenged assumptions I didn’t realize I was making.

The Struggle and Balance of Delegation

Delegation was one of the first challenges I encountered in this role. I heard early on that delegating more was essential, but understanding what effective delegation actually looks like took much longer.

Delegating a task does not remove responsibility. Even when work is assigned to someone else, ownership of the outcome still rests with me. The difficulty lies in knowing how much involved I should be. Too much involvement quickly becomes micromanagement, while too little can feel like abandonment.

Over time, I’ve learned that there is no fixed answer. The right balance depends on the person, the context, and the importance of the task. Trust, in this sense, is not a static state but something that evolves through repeated interactions. I am still refining how I delegate, learning to stay accountable without hovering, and accepting that different approaches can still lead to good outcomes.

Communication as the Core of the Role

One of the biggest surprises in my transition was the sheer volume of communication involved. Early on, I struggled with this more than I expected. I underestimated how much clarity, repetition, and alignment were required to keep everyone moving in the same direction.

I now see communication as the core of my role. It extends beyond conversations with the team to written updates, documentation, and alignment discussions across the organization. It flows upward, downward, and sideways. Each direction provides a different perspective, and together they create the context needed for sound decision-making.

Transparency has become especially important. When the team understands the business context behind decisions, their work feels more meaningful and connected. Without that context, it’s easy for even important work to feel detached from the larger goals.

Owning the Missteps

These two years have been shaped as much by mistakes as by successes. I’ve missed opportunities to influence decisions when I could have contributed more actively. I’ve spent periods operating reactively, focused on day-to-day execution rather than longer-term progress.

At times, I listened to many perspectives without forming my own. Over time, I’ve learned that having a management role also means having a point of view. I’ve also had to become more comfortable asking difficult questions upward, especially when expectations were unclear.

There were moments when I took on too much individual contributor work, reducing my ability to focus on broader concerns. I’ve struggled to say no, only to later see how unchecked requests can overwhelm a team. Each of these moments has quietly reshaped how I approach the role.

Finding the North Star

Perhaps the most important lesson has been the need for a clear North Star. A team needs guiding principles and a shared sense of direction. I’ve spent a great deal of time reflecting on what that means for my team, the company, and myself.

Having a vision is not enough. It has to be communicated, aligned, and revisited regularly. Understanding whether we share the same values and principles has helped keep the team engaged and grounded. My role, more than anything else, has become one of maintaining that alignment and ensuring the team can see how their work fits into the bigger picture.

Conclusion

Two years in, I no longer see this role as a destination. It feels more like an ongoing process of learning, unlearning, and recalibrating. The work is quieter than writing code, but the impact, when it lands, feels deeper and longer-lasting.