What I Learned Going From Engineer to Lead (and Back)

In 2022, I moved from Senior Engineer to Engineering Lead. At first I thought it was a reward for being good at the technical stuff — a promotion. I was wrong. It wasn't about me writing more or better code. It was a completely different job: the work was now the people, not the code.

It took me four years, a lot of mistakes, and a stretch of missed deadlines to actually understand that. The "soft skills" everyone talks about turned out to be the hard part, and the most important part. This is what I learned along the way — the real stories, not the clean version.

1. I Thought I Was the Hero. I Was the Bottleneck.

When I became lead, I kept building everything. I told myself I was a superhero — fixing five bugs before lunch, running effort estimation, reviewing every PR, still shipping features. Felt productive. Felt indispensable.

Then it caught up with me. I started missing deadlines. Escalations piled up, one after another. My effort estimates were off because I was estimating for a version of myself with unlimited hours. I was a mess, and the reason was simple: every decision, every fix, every estimate routed through me. I hadn't built a strong team — I'd made myself the single point of failure.

What fixed it wasn't working harder. It was handing whole modules to my senior engineers and letting them own the P0/P1 escalations — even when it took them longer at first. That slower start was the price. Watching them grow confident enough to handle an escalation without me was what finally took the weight off.

It didn't stop there. While the seniors handled criticality, I pushed freshers and juniors to pick up the seniors' routine tasks. The whole team shifted up a level: juniors grew into the day-to-day, seniors grew into the hard problems, and I finally had room to lead instead of firefight.

If you are the only one who can fix a critical system, you haven't built a robust system. You've built a bottleneck — and you are it.

2. Assign Problems, Not Tickets

The best example I have is a feature we called serialisation. The idea: attach a unique serial number to every SKU so we could track each unit end to end — almost like a blockchain for inventory. I worked with product to shape the high-level architecture, then handed it to one of my engineers.

I could have specified every table, every endpoint, every edge case. Instead I gave him the problem and the shape of the solution, and let him own the rest. He designed the entire low-level implementation himself. It took months to ship — longer than if I'd micro-managed it into existence — but that's not the part I remember.

The part I remember is what it did to him. He came out of it a different engineer. Confident. Proud. He'd built something hard, end to end, and it was his. His sense of ownership never went back down after that. If I'd handed him a stack of tickets instead of a problem, I'd have gotten the same feature and none of that.

Micro-management gets you the code. Handing over the problem gets you an engineer who grows.

The hardest part is knowing when to let go. My rule: if a team member can do a task around 70% as well as I can today, it's theirs. The remaining 30% is where mentorship happens — they close the gap by doing, not by watching me do it. The usual excuse, "it's faster if I just do it myself," is true exactly once. Every time after that, you pay it again.

3. Make It Safe to Tell You the Truth

I always kept myself open to questions, and over time it changed how the team worked. My senior engineers started challenging me openly in standups and retros. One would ask why we were loading all the SKU records in a single query instead of paginating, when we were already handling millions of transactions a day. Another would push back on a schema I had signed off on. It could have felt like they were bashing me. It was not. It was them taking ownership.

The clearest sign was a small role reversal. In standup we would go through the bug list and PR reviews, and when something looked off, I did not have to be the one asking anymore. They asked me. Those "why is it this way" questions turned into real technical discussions, and the outcome was better because of it.

The juniors and freshers were the real test. Early on they were scared to speak, and I did not fully understand why. So I made space for it. I kept asking, kept clarifying, kept giving them the chance to say something. Slowly their confidence grew. I could also see the other side of it. A team gets stressed while shipping features, worried about bugs, stretched thin helping each other. Being open, clarifying doubts, answering the question instead of judging it, that is what helped.

A team that is afraid to bring you bad news does not have fewer problems. It just tells you later, when it is too late to fix.

4. Build Leaders, Not Just a Team

The real test of a leader is how well the team runs when you are not around. If your phone blows up every time you go on leave, you haven't delegated — you've just stepped away from the controls for a while.

So I built a second line of leadership. One of my engineers was a natural lead, but she wanted to stay an IC, and I respected that. It didn't matter. When I was away — vacation once, a family emergency another time — she was the one who stepped up and took ownership of everything. And here's the part I still think about: no one ever asked "why should I follow you, you're not the lead?" The whole team just followed her. I only had to make it clear once — if I'm not around, she's the point of contact.

Then it turned into a chain reaction. She groomed two more engineers into that same kind of informal leadership, without anyone handing them a title either. That's what building leaders does. It didn't just cover for me when I was gone — it gave me back my own time to learn, experiment, and think about what's next.

5. Be the Bridge Between the Dev and the Business

An engineering lead who only cares about code is just a senior engineer with a more annoying calendar. The real job is to sit between two worlds and translate.

On one side is the business. I lost count of how many times a feature came in as "we need this in one week or it's a churn risk." Building at scale needs planning, structure, and proper execution — you can't always do that in a week. But I learned not to just push back and say it's not possible, and not to blindly say yes either. I negotiated. Build what's actually needed right now in that week, but be clear about what it has to look like at scale, and buy the time to build that part correctly. Say no to shipping it wrong, not to the deadline itself.

The other side is the vision. Take serialisation again. To a developer, it's simple: store some data in the DB, pull it up on the inventory and transaction screens. That's the math, and developers are good at the math. But the end user doesn't care about the DB. They want to open one screen and see which SKU unit is sitting in which outlet, how it got transferred there, and what action they should take next — all in one click. Product knows what makes the user's life easier. Developers know how to build it. The lead is the bridge that carries that vision from one to the other.

That's the whole job. Developers are good at how. Product is good at why. The lead makes sure both sides are building the same thing.

Going Back to IC Was Not a Step Back

Recently I moved back to an individual contributor role. Some people see that as a step down. I don't. The four years I spent leading did not make me a worse engineer — they changed the kind of engineer I am.

Today I lead the engineering side of Bizom Marshal. A lot of my work is on building autonomous web automation, using Claude together with Playwright test agents to create and run browser tests on their own. The rest goes into the tech debt that quietly slows everyone down: improving developer productivity with tools like PHPStan and the wider Laravel ecosystem, and keeping the system stable. Notice what that work is: it's still about multiplying. I'm not just shipping my own code faster. I'm making the whole team's code safer, the system steadier, and their day easier.

That's the part that stuck. Whether the title says "lead" or "senior," the real shift is from doing to multiplying. Once you've made that shift, you don't lose it. It just shows up in different work.