Trading Commits for 1:1s: What I’ve Learned So Far Since Becoming an Engineering Manager

One Year In: The Transition from IC to EM

Around a year ago, I made the shift from the individual contributor track to engineering management here at Lendable. For nearly 15 years, I worked as a backend engineer in various roles - developer, tech lead, staff engineer. Candidly, this move into management wasn’t a deliberate career pivot. In fact, years earlier, I had actively avoided this path by leaving a role that was nudging me toward EM responsibilities. I even started contracting to remain in the IC space. So, what changed?

In hindsight, many responsibilities typically associated with engineering managers had already crept into my IC roles over time. What changed recently is that these responsibilities became my full-time focus. The role of an EM itself has evolved too. Where it once seemed confined to delivery management and people ops - far removed from technical decision-making, it now encompasses technical leadership.

At Lendable, technical leadership is one of the four core pillars of our engineering management philosophy. Having formal accountability here has given me the space to stay close to engineering, influence direction, and support the team. It allows me to ask thoughtful questions, challenge assumptions, and understand why we build things the way we do.

Redefining What "Impact" Means

One of the biggest personal shifts has been redefining how I measure my impact. Previously, it was tangible: features shipped, code reviewed, bugs fixed. In management, it’s a more abstract space: Are people in my team happy? Do they feel psychologically safe? Are we hitting our OKRs? Is our product robust and performant?

Answering those questions requires a different mindset - one that relies on indirect signals, team feedback, and creating a culture of honesty and openness. It's a less immediate feedback loop, and it took intentionality to get comfortable working this way.

Operating the Submarine

An analogy that resonates for me is that of the submarine. As an EM, your default mode is periscope depth, surveying the landscape and identifying areas where you can support or intervene. But when needed, you dive deep. You help debug, join an incident call, or rally a cross-functional team to solve a thorny architectural issue. Being effective in this role means knowing when to dive and when to stay surfaced. You need to master the periscope.

Beyond Your Lane: Building for the Org

Another key learning has been realising that your influence can't stop at your immediate team. Great engineering managers contribute to the broader organisation. Whether it's supporting other EMs, helping shape engineering culture, or creating processes that improve onboarding and growth, you need to build, not just operate. My rule of thumb? Always have at least one task in flight that makes the wider engineering org better. If every EM did the same, we’d make massive, collective progress.

Advice to New or Aspiring EMs

• Own your scope, but don’t limit it. Your role is bigger than your team. Set the tone for the wider org.
• Lean into discomfort. That hard conversation with a struggling report? It matters.
• Grow others, not just yourself. Your success is measured by the growth and impact of your team.
• Embrace mistakes. There’s no playbook that covers every situation. Learn to make more good decisions than bad, in a world full of variables.

Final Thoughts

This past year has been a huge learning curve - rewarding, challenging, and full of personal growth. Every day I still feel like I’m learning, but that’s what makes it exciting. Engineering management is no longer something I avoid; it’s something I actively want to master. And it turns out, trading commits for 1:1s isn’t so bad after all.