Why I quit management to go back to coding

Going back to engineering isn’t a step down. It’s just realizing where you actually belong.

Alright. Here goes. I’ve had a “blog” for almost a decade and never took the time to write a single post. Classic developer syndrome: I spent way more time picking a static site generator (a whole story in itself) than actually writing a word on it. So to finally bump my output from zero to one post every ten years (haha), I decided to start with something that actually matters to me: how I accidentally ended up a manager, what it cost me for three years, and how I made my way back to code.

One quick note before diving in: I’m French, working at a French company, in a fairly large corporate environment. Some of what follows, especially around performance reviews, is shaped by that context. Workplace culture and management practices can differ quite a bit between France and the English-speaking world, so I’ll add some context where it matters.

The promotion I didn’t really choose

A bit of context: the project was built around a new team of junior engineers. We pretty much all joined on the same day, we grew together in the same codebase, and survived the same production incidents.

We were more than a team: we were all roughly the same age, and we were friends. But inevitably, after five or six years on the project, a lot of them wanted to see other horizons. The group started to scatter, and somehow, I was the one who stayed. I became, in a way, the person who knew every corner of the code and whom newcomers relied on not to get lost.

Looking back, I know I stayed for two reasons:

Fear, in a way, and the feeling of “it’s not that bad here, actually.”
And the more people left, the more indebted I felt, out of loyalty, to stay.

So a few years later, when my manager got promoted and I was offered his spot, I said yes. Not out of career calculation, more out of loyalty to the team and the project, and because back then, if you wanted to move up, there was only one visible path: management. The Staff Engineer role everyone talks about today as an obvious option was still vague, almost nonexistent.

I wasn’t ready. I found that out pretty fast.

The shock of managerial reality

I’m generally not a big fan of training, I learn better on my own. Well, this time, I got thrown straight into the deep end. The jump from developer to manager was a genuine speedrun. No training, barely any handover (read: basically no real transition period). Some would say that’s proof of complete confidence from leadership 😏.

Taking on a manager role is already a full job on its own. Doing it right in the middle of the COVID shift to mandatory full remote, in an organization discovering that at the same time as everyone else, didn’t make things easier. I had to juggle between highly autonomous, demanding local teams, and offshore teams that needed much closer support. I was constantly having to bridge the gap.

But the most stressful part for me was the annual performance reviews. And it mattered a lot, because I had a genuinely good team. A bit of context here: in French corporate culture, especially in large companies, forced-ranking systems with strict quotas are not unheard of. It wasn’t just a quirk of my company. Structurally, it was impossible to put everyone in the “good” bucket. There’s also this gap in perception between the micro and macro level: you can feel like you’ve accomplished everything and deserve more, while at the team level, individual impact is much harder to measure. I’m convinced that without that macro view, which you really only get once you become a manager, it’s hard to see it. In the end, I never got used to it. It felt pretty brutal, even though nobody was doing it on purpose. It was just what the system required.

Then there was the middle-management squeeze, something you see a lot in large corporate groups (or so I assume, judging by my résumé): enforcing a methodology and delivery cycles on teams, while those same plans regularly got disrupted by decisions made higher up, without any say in it. I sometimes felt like a reverse proxy! My only job was to absorb the shock, day after day, to shield my team as much as possible.

It’s a bit like becoming a parent: you go from “you” to “them,” the baby becomes your priority, and “you” clearly moves to second place. Here, the team was “them”…

Hiding behind code: tech as a shield

Oh, by the way, did I mention my senior backend dev position was never backfilled? Surprise: no replacement. I ended up doing both jobs at once. Manager by day. Developer in the evening, between meetings (or honestly, very often during meetings, let’s not pretend otherwise). If I had to live a double life anyway, I’d rather have been a billionaire in Gotham City by day, and in a cape covered in gadgets by night.

Illustration: manager by day, developer by night

That’s when a mechanism kicked in, first without me noticing, then more and more consciously: I retreated into code every time everything else got too heavy.

Code is simple and reassuring to me, it’s even a passion. It’s not a chore, I love coding and solving problems. The results are readable: it works or it doesn’t. No ambiguity, no emotional weight to carry. People, on the other hand, never resolve that cleanly. Even assembly code (and I’m hopeless at assembly) feels more understandable to me.

Naturally, I ended up using technical workload as a legitimate excuse (“sorry about the admin stuff, there’s a production issue”) to keep pushing back the management tasks I found most uncomfortable. I unintentionally hid my discomfort behind technical performance, and it worked well enough, for long enough, that I never really questioned it.

Was I a good manager? I never dared ask myself the question. Should I have? I don’t think I was good, but not bad either (I hope). I did my best. But either way, I had the feeling I wasn’t in the right place. I felt like I would be far more effective writing code, designing systems, thinking through problems, and solving technical challenges full-time.

The false promise of “just being a dev again”

One day, my wife and I decided we wanted to move away from where we were living. I decided to try an internal transfer. Logically, I proposed keeping my current role and managing the team remotely: rare in our group, but there were precedents, and with COVID going on anyway, it wouldn’t really change much for me! I didn’t even try looking for another position or another project within the group. I just couldn’t see myself abandoning my team for a personal life choice, so proposing this arrangement felt like my way of making things right.

In the end, for internal reasons, it got turned down. The move still happened though, thanks to an opportunity to join a brand new project within the group, on the condition that I’d no longer be… a manager, since that role was already filled by someone else on that project.

What’s funny is all the care they took to break the news that I’d only be a “regular dev” and no longer a manager… Where do I sign?

That finally broke me out of that routine. And the relief of going back to a purely technical role was immediate. No more reviews to hand out, no more political arbitration. I felt like I could finally breathe after way too long underwater.

But that calm had its limits. After a few months, once things settled, a kind of restlessness set in. Once you’ve tasted the big picture, it’s hard to go back to pure execution. Handling tickets without any say over the roadmap or the architecture made me feel like I was leaving part of what I knew how to do unused.

Finding my way to the Staff Engineer role

That’s when I understood something pretty clear about myself: I no longer wanted to manage performance reviews or careers. But I also couldn’t be satisfied executing without any influence over the bigger picture. I needed something in between, which simply didn’t exist clearly back when I got my first promotion.

The team I’d joined had just been acquired, and being slightly older than the team average, I was going to mess up their youth stats a bit! My experience and knowledge of the company quickly allowed me to take on a broader role within the team. People relied on my experience, my technical skills, and my network.

But that kind of role doesn’t just fall from the sky. I didn’t wait for someone to offer me a broader scope: I started working on things that went beyond my team, helping with architecture decisions, connecting with other departments, and gradually becoming a point of reference.

I also brought it up with my manager and explained that I wanted a purely technical role, but with a broader impact beyond my immediate scope. The need was clearly there, even if no one had really put a name on it yet.

At my company, the term “Staff Engineer” doesn’t even officially exist (yes, I’ve been slightly lying to you since the start of this article). Officially, I’m a “Technology Senior Manager,” and I have no one reporting to me… Like our good old Napoleon Bonaparte, I self-promoted myself to Staff Engineer. That’s how I ended up in the role: not because of a title, but because of what I was actually doing.

Generally, I don’t put much weight on titles, but my current position, a bit of an odd fit for my company’s standards, forced me to think about my status, my place, and therefore my role. I work in tandem with a dedicated People Manager, who handles all people-related and career matters. I, on the other hand, own:

Technical vision and architecture.
Connections across teams.
Crisis management and production incidents.
Mentorship and engineering culture.
Improving Developer Experience (DX).

Concretely, that can mean spending a week unblocking an architecture decision, then spending the next one overhauling how we handle production incidents. It’s picking up friction points from developers and the QA team to give them better tools and processes. It’s also producing PoCs, demos, and delivering technical presentations.

I’m not bored, and it’s the balance I was looking for without knowing how to name it.

What three years of management taught me as a Staff Engineer

Looking back, and even though at the time I would have signed up to cut the experience short, I wouldn’t erase those three years. They gave me things I would never have gotten by simply staying behind my screen.

First, I got to see what management looked like from the inside. Once you’re on that side, you realize pretty quickly that things are rarely as simple as they look. There are constraints you don’t see from below, trade-offs you don’t understand until you’ve had to make them yourself.

It also gave me real empathy for managers. Not the fake, circumstantial kind, the “yeah, I get it, that must be tough” type, but something more concrete. I now know what it feels like to deliver bad news you didn’t choose, or to carry pressure you can’t pass down to your team.

And then there’s the understanding of the business side. It helps enormously today as a Staff engineer, to speak the same language as people on the product or leadership side. This plays out very concretely: rather than explaining a technical constraint in jargon, I now know how to reframe it as direct business impact, which makes prioritization meetings much easier.

What I take away from it

If I had to do it again, I’d go through those three years of management all over. Not because I enjoyed every moment, far from it, but because it transformed me. I learned so much. And even though I moved back to the Individual Contributor track, I now know just how complementary the two paths are. Beyond a certain level of seniority, understanding these different paths and knowing how to work with them becomes essential. Even more so with the rise of AI (yeah, that too, AI 🤖…), where raw technical skill is going to matter less.

If you’re an engineer and people are gently pushing you toward management because “it’s the logical next step,” know that going back isn’t a failure or a step down. It’s just realizing where you actually belong. It took me three years and quite a bit of exhaustion to figure that out. I hope it takes you less time.

Illustration: going back to a technical role isn't a step down