Promoted Out of the Codebase

I’ve recently started, or well, feels like recently, my journey into Engineering Leadership. I’ve wanted to write about this transition for a while now, but I’ve struggled to put something together that felt genuinely useful.

I also wanted to write something that I can look back on, but also provide some information for anyone else considering this as an opportunity.

Why I Made the Move #

I joined Lendable as a Senior Software Engineer in January 2025, an exciting FinTech start up based out of Shoreditch, London. I joined as a Senior Engineer, I’d come from a very Framework heavy background (Spring - for my sins), and Lendable hadn’t gone for that approach, this really interested me when joining. From the get-go, I focused on the technology and building strong relationships: understanding the codebase, the people and teams, and finally the problems.

The people part I’ve always drifted towards and that’s where I first started to think about Engineering Leadership as potentially my next step. I’ve always thought that good engineering is as much about communication as it is about what you can deliver in code.

I’ve always felt that Senior Engineer is a bit of a fork in the road. You can either continue to invest in the technical, growing more into broader technical leadership through staff / principal routes. Or you move into the people and delivery aspect. About four months in, I was put forward for an Associate Engineering Manager role. This was Lendable’s internal pathway to grow engineering managers. It allowed me to stay hands on as an IC, but also start to take on engineering management responsibilities, essentially over time slide the scale of IC duties down, to then replace them with engineering management.

This was under the direct supervision of my Engineering Manager at the time, and my Product Manager. It was a fully supported pathway and they both supported me every step of the way.

I’d be lying if I said I didn’t hesitate. There’s a real fear in stepping away from the thing you’ve spent the last 14 years getting good at. Writing code, solving technical problems, shipping features. I felt like I’d just got comfortable with that level of seniority. Was I giving that up? And was it too soon? Maybe. But I felt that I’d rather take the chance and grow into something new.

If you wait until it feels safe, you’ll be waiting a long time.

How It Started #

The transition from Senior to Associate EM happened faster than I expected. Some things felt immediately natural: unblocking people, having conversations about priorities, advocating for the team. If you’ve been a good senior engineer, you’ve probably been doing a version of these things already without the title.

But other things were properly alien. You start being in rooms where decisions happen differently. Less “what’s the right technical solution?” and more “what’s the right thing to do given these competing priorities, this deadline, and these stakeholders who all want different outcomes?” Things at first seem messier, and feedback loops are longer. You don’t get the satisfying green tick of a passing build at the end of the day.

I think the biggest adjustment early on was realising that my output was no longer something I could easily point at. As an engineer, I could show you the tickets I’d shipped that week, the physical output, whether that’s a feature or a new layer of observability.

As a manager, my best work is often invisible. It’s a meeting that prevented a problem, the conversation that kept someone from burning out, the decision that gave the team space to do their best work.

A big part of those early months was the support network I had in my engineering manager at the time, and my product manager. They backed me from early on, but they didn’t make it easy. They both challenged me in the right ways. Honestly, at times it was uncomfortable, and I’d be lying if I said I hadn’t questioned my decision outright, but I pushed through. However, looking back, that discomfort was growth, and I’ve learned a lot.

Everything’s Ambiguous #

As an engineer, you debug a failing test and eventually you find the answer. It’s there, hiding in the code somewhere. Management problems aren’t like that. Someone comes to you with a situation, maybe a team dynamic issue, maybe a delivery risk, maybe a decision about where to invest effort, and there’s no definitively correct answer, or perhaps even solutions immediately available. There are just trade-offs with different consequences.

I’m being a bit facetious, you don’t step into management expecting it to be like debugging. But knowing it and feeling it day-to-day are different things.

It took me a while to stop reaching for a definitive answer and accept that sitting with ambiguity is part of the job, not a sign that you’re doing it wrong. If I’m being honest even to date, that hasn’t changed, you just continue to learn to handle it better.

You gather context, you talk to people, you make a call, and then you live with it. Sometimes you get it right, and sometimes you are wrong, but that’s part of the challenge.

The discomfort doesn’t fully go away. You just get better at navigating it.

It Can Get Lonely #

I’ve read a lot about this one, and I think it catches people off guard more than they expect. The idea that stepping into management can feel isolating. You’re still on the team, still in the stand-ups, still in the Slack channels, but there’s a subtle repositioning that happens. You know things you can’t always share. You make decisions that not everyone will agree with. There’s a natural shift in the dynamic compared to before.

Honestly though, I think I had a bit of an advantage here. I’d been part of the team as a senior engineer before stepping into the role, so the relationships were already there. It wasn’t like jumping into a new team as a manager where you have to establish everything from scratch. That made the transition feel a lot less jarring than I think it can be for others.

That’s not to say nothing changed. It did. But it was more of a gradual shift than a sudden wall going up. The people I’d been working alongside were the same people, and we’d already figured out how to work together. I still want people to feel like they can be themselves around me.

But Do You Still Code? #

I know this is the one that engineers considering the move agonise over, so I think it’s worth me being direct: yes, I still write code.

But it varies massively week to week. Some weeks I’m reviewing PRs, poking at a problem, or prototyping something. Other weeks I don’t open an IDE at all.

I should also mention the obvious, this is also aided by the advances in LLM capabilities. Frontier models currently are able to spin context up and keep me in the loop far better than they used to be. They can enable me to fix the small things, the copy changes, the colour of a button. I don’t take on large tasks, but I think it’s important I try and stay close to the challenges the team face in this role.

I won’t pretend I’ve nailed this balance. I’m still figuring it out, and I suspect most engineering managers are, regardless of what they say publicly.

What I will say is that I still consider myself an engineer. The role looks different, the day-to-day looks different, but the way I think about problems hasn’t fundamentally changed. I’m still drawn to systems, to debugging processes the same way I’d debug code, to understanding how things connect.

When It Clicked #

While it’s been a lot of growth, there was a moment where it clicked. Where I thought, “Ah, that’s the rewarding side of management.”

In the second half of 2025, the team pivoted into a completely new domain. New problem space, new expectations, ambitious targets from the business. It was the kind of challenge that could easily have knocked confidence, but the team embraced it. My job wasn’t to write the code. It was to clear the way, set up the right discussions, shield the team from noise, and make sure everyone had what they needed to do their best work in unfamiliar territory.

We delivered ahead of where anyone expected. The kind of outcome that, when the targets were first set, felt like a proper stretch. But beyond the delivery itself, the thing I’m most proud of is that the team came out of it healthier and more engaged than when we started. The ambiguity I mentioned earlier, the lack of a clear feedback loop? This was it finally clicking into place.

Thinking About It Yourself? #

So, if you’re still reading this, thank you! I’m just over a year into this, so take all of this with a big pinch of salt. But here’s what I’d want to hear if I were back in that Senior role:

• It’s not a promotion. It’s a career change. The skills overlap, but the job is fundamentally different. Learn to treat it that way.
• You’ll miss coding some days. And that’s fine. It doesn’t mean you made the wrong choice.
• The ambiguity doesn’t go away. You just get more comfortable with it. If you need clear right answers to feel productive, this role will challenge you.
• Your relationships are your superpower. Everything I’ve achieved in this role traces back to the relationships I built early on. My advice is to invest there, because people matter.
• The wins feel different. They’re less tangible, often delayed, and sometimes invisible. But when someone on your team grows, or a delivery lands well, or a process you started makes an impact, those wins are really rewarding.

I’m still very much learning, and I suspect I’ll look back on this post in a year and cringe at how little I knew. There’s plenty I haven’t figured out yet, and I’m sure there are a few lessons still waiting to catch me off guard. But that’s kind of the point. You don’t wait until you’ve figured it all out to share what you’ve learned so far.

If you’re thinking about making the jump, I hope this gives you something more useful than a LinkedIn post. Feel free to reach out, I’m always happy to chat about it!