How do I delegate when I can do it faster myself?

I remember why I became a manager. The team needed someone to advocate for their growth, compensation and overall well-being. I knew very little about leadership or management and the resources were somewhat scarce - I didn't even know what to look for. But I was determined to do my best.

At times my best meant doing everything myself. After all, I was the most experienced engineer on the team. I could write code faster than anyone else, review PRs quicker than anyone else and ship features quicker than anyone else. Well, not really, but I'd like to think so anyway.

Every once in a while I'd make a stupid mistake, miss a bug or forget to test something properly and these moments suck. They made me doubt my abilities as an engineer and a manager. If I can't even do my job properly, how can I expect others to do it for me?

I did do some things right: I have been the first one to point out my mistake, own it and fix it. I have been transparent about my shortcomings and asked for help when needed. I was very proud that I could be a manager who still codes, who still understands the technical challenges and can help the team out.

It was all going great till one day at the retro a developer said: "You know, Valeria, you should stop coding. Let us handle it, we can do it ourselves."

"You should stop coding"

Oh boy, did that hit me hard. I was doing my best to be a good manager and a good engineer, and now I was being told to stop coding altogether? It felt like a rejection of my skills and my contributions to the team. I was confused and frustrated. Why would they want me to stop coding? Was I not good enough? Was I not contributing enough?

I did listen. Well, almost. I still code, years after, but I no longer do that within my team. I can pick up some small side tasks here and there, but I don't own any features or projects. I don't review PRs or write tests. I don't deploy code or fix bugs. I delegate all of that to my team.

Not because I'm incompetent, but because they needed space to grow. They needed to own their work, make mistakes and learn from them. They needed to feel empowered and trusted. And I was in the way.

Here's the paradox: the fact that I could do it faster was precisely the problem. Every time I jumped in to save time, I was robbing them of the chance to develop their own speed, their own judgement, their own mastery. I was optimizing for today's velocity at the cost of tomorrow's capability.

So how do you delegate when you can do it faster yourself? You delegate because you can do it faster. Because if you don't, your team will never get the practice they need to eventually do it faster than you ever could.

Feeling guilty about not coding is normal

My whole identity was wrapped around being a great engineer. I was proud of my technical skills and my ability to deliver results. Who am I now that I'm not coding anymore? Am I still valuable? Am I still relevant?

To top it all off, I was still painfully aware of how little I knew about management. I was making mistakes left and right, trying to figure out how to lead a team, how to communicate effectively, how to motivate and inspire others. I was constantly doubting myself, wondering if I was doing the right thing, spiraling into a vortex of imposter syndrome.

It didn't matter that I was getting praise left and right, I felt like a fraud. I felt like I was pretending to be a manager, while deep down I was just an engineer who couldn't code anymore.

WTF Button

Instinctively, I was searching for a new identity. I wanted to find a way to feel valuable again. I wanted to find a way to contribute to the team, to the company, to the world.

One day one of the developers called me a "WTF Button" - whenever they were stuck, confused or frustrated, they would come to me and ... I'd solve it for them. Just like that. No questions asked. Just hand it over to me and I'd fix it.

It worked for a while, even though now I'm cringing at the thought of it. Nonetheless, it did help me find a new way to contribute. I was no longer coding, but I was still helping the team. I was still solving problems, just in a different way.

I thought I was being a mentor, a guide, a coach (I wasn't, but it took a bit to figure that one out). I always had an answer and a solution. I was the go-to person for everything. I was the one-and-only WTF Button.

But something was still off.

Manager or therapist?

At some point I realised that there's more to being a manager than just solving technical problems. There's also the human side of things. The side that involves those pesky feelings and interpersonal dynamics.

Psychology has always fascinated me and I found myself reading books and articles about it, trying to understand how people think, feel and behave. I wanted to be a better manager, a better leader, a better human being.

I had the best intentions, but I was still struggling: I was trying to fix everything for everyone. A caring, empathetic, misguided Emotional-WTF Button.

My team loved me and hated me for it. Thank god I learned to read the room and not push when they needed space.

My team, they were so understanding with me and patient! I'm certain that I wouldn't have learned without them letting me fall flat on my face a few times.

Luckily, I stumbled upon "The Phoenix Project" by Gene Kim & co and my falls become way more strategic. I got absolutely inspired, by Bill Palmer, the protagonist, but even more by his mentor, Erik.

Erik reminded me of a "Good Witch" Cassie Nightingale - a magician who knows what to say and when to say it. A wise, experienced guide who helps the hero find their way to what they must do without any direct interference. Everyone knows that they did something, but no one can really point out what it was and to all intents and purposes, the hero did it all by themselves.

I was clearly not even close to that level! I was way too involved: the problem solver, the fixer.

I didn't even know how to measure the impact of my or my team's work!

What number should go up for you to be happy?

One of my favourite moments from the book was when Bill asked CFO, Dick Laundry (I have a feeling that the authors don't like CFOs): "What number should go up for you to be happy?", which kickstarted the whole DevOps transformation.

I started to wonder what number would that be and who should I even ask? I asked my manager and he said that he's happy with my work and that I should keep doing what I'm doing.

I don't blame him: I had a dozen developers spread across 5 teams, each with their own goals and metrics. I knew goals for the company, but how do I move RevPAR (Revenue per Available Room) with just web developers, excluding designers, integration and backend engineers? Especially since I had no idea what their work really entailed on day-to-day basis.

I had no idea and at that point I blamed our setup for it. I even came up with a couple of "strategic initiatives" on how to fix up our product teams.

I really wish I knew what I was starting back then. A lot of good came out of it, but it was a long and painful journey.

Stakeholder management

One of the biggest challenges I faced as a manager was dealing with stakeholders. They had their own agendas, priorities and expectations, wanted things done their way and yesterday.

Now while I was playing the WTF Button they didn't mind - the problems were getting solved, after all. But once I started to poke at the process, they were not too happy about it.

Prior to product teams they could never align resources between different tech departments. Expectedly (for me now), the idea of going back to "silos" was causing them a lot of negative emotions.

It wasn't pleasant, but after being surprised that my super-awesome proposal was met with a "hell no", I realised how little I knew about people me and my team were working with.

In my head my only stakeholders were the developers and perhaps my manager. In reality, there were lots of people we depended on, each had their own goals and metrics and I knew nothing about their needs.

"Business is about people", they say. I think I finally understand what that means: it's about learning their needs, removing their obstacles and respecting their boundaries.

Easier said than done, that's for sure.

How to be at 5 places at once?

When I sat down to map out all the stakeholders, I was shocked. There were so many of them! Product managers, designers, content editors, customer support, data, architects, security... the list was endless. Each of them had their own priorities, timelines and expectations. How was I supposed to keep track of all of them? How was I supposed to manage their expectations? How was I supposed to make sure that everyone was on the same page?

Clearly at this point coding or technical problem solving was the least of my worries. I spent so much time preparing slides and attending meetings that I barely had time to think about anything else.

And then it hit me: I was at a point where I had to delegate not only technical parts, but management as well. There was no way for me to do it all and be everywhere at once and 1-1s alone were taking most of my calendar slots.

I started to look into team topologies and among other things it became very obvious that each team needs a clear purpose to succeed. Ours had 5 instead.

That meant that we had to split. Luckily at this point I already knew who in the team was leaning towards people management and we came up with a special "Web Goal Keeper" role in several of the teams. As the title could hint, I delegated goal setting to couple of team members.

Having a dedicated person to own the goals within the team made a huge difference. It freed me up to focus on the bigger picture and gave each member clear objectives that they could achieve while doing their day-to-day work.

But numbers?

I still couldn't answer the questions about our impact. I tried different approaches, from OKRs to KPIs to simple metrics dashboards. Nothing seemed to work.

The solution came when my most prized initiative, the Foundation Team, was disbanded. It was a team that was supposed to own the shared infrastructure and work on strategic prototypes.

It had been a cross-functional team, but only engineers from my team were excited about it. So when the other ones decided to pull out, I simply had to let it go.

But before that, I had a chance to talk to a product manager about success metrics needed to secure buy-in from their side (they didn't understand nor support the idea of a Foundation Team).

And what she taught me is that before you have metrics, you need to have a Vision. One distilled reason for the team to exist. A North Star that everyone can rally around, including stakeholders, tightly linked to shared goals.

Once you have that, metrics become much easier to define: what numbers should go up for that vision to come to pass faster?

I started thinking about the vision. Not the split tiny ones for each team, but the big one for all of us.

If we were a startup...

If we'd be a startup, what would be our mission? What would be our purpose? What would be our why?

And the answers started to come. We were experts in web development. We were working as long term consultants for several teams within the company. We had insider knowledge and we were building reliable in-house solutions.

Around the same time I got introduced to the concept of SLIs and SLOs (Service Level Indicators and Service Level Objectives) and it all clicked.

In one short session we aligned on our SLIs and objectives for the next 3 months together with the team. We picked the ones that were directly linked to guest experience and business outcomes: latency, availability and costs.

And then the next day we had a dashboard to look at. Pure, distilled accountability: we could see exactly what we could control and knew what to prioritise.

Culture <3 KPIs

One downfall of numbers is that they can be gamed. If you only care about latency, you'll cut corners on user experience (cache it all) or security (let's serve everything from the edge). If you only care about availability, you'll ignore costs. And if you only care about costs, you'll cut corners on everything else.

Without the culture to keep team aligned on the right values, KPIs can lead to disastrous outcomes. Some say blindly following KPIs is the root of all evil and source of many bankruptcies. I cannot neither confirm nor deny that, but it does make sense to me.

I don't like the idea of placing people into tiny little boxes with labels on it, even though I see value of KPIs and OKRs. People are complex and multi-dimensional, and reducing them to a set of numbers is compelling, but dehumanising.

By that time I've attended a few leadership workshops (I should have done that sooner) and read a couple of books on culture building ("The Culture Code" by Daniel Coyle is a masterpiece, by the way) and now I had the knowledge to offset the risks of numbers.

We switched to more small groups meetings, actively learned the skills of giving and receiving feedback and set individual goals for each smaller subgroup.

A couple of days ago I skipped the meeting where the team discussed the next tech stack to strive towards. Of course I couldn't leave them empty handed and left them with a draft.

They delivered above and beyond what I expected. I definitely couldn't have done it better or faster myself.

Conclusion

I still think that one engineering manager shouldn't manage more than 5-7 people directly. The quality drops and the complexity increases exponentially. And one team should have one clear direction. No more, no less.

But we, leaders, are usually rising when things aren't perfect. It takes time and tremendous amount of selfless courage to take the responsibility and let go of control.

The work doesn't stop - it transforms. And honestly? The parallels to engineering are stronger than I thought:

Meetings and slides are your new coding sessions. Just as you used to craft elegant solutions in code, you're now crafting clarity and alignment through communication. The syntax is different, but the goal is the same: turn ambiguity into actionable structure.

Sudden stakeholder dissatisfaction is your new bug to fix. Root cause analysis still applies. You still need to dig deep, understand the system, and address the underlying issue - not just the symptoms. The debugging tools are conversations instead of logs, but the analytical mindset remains.

Helping people grow is your new feature to ship. This one has the longest feedback loop you've ever worked with. You won't see the results in a sprint or even a quarter. But when someone on your team tackles a problem you would have struggled with years ago, or leads an initiative you couldn't have imagined - that's your deployment going live.

You've done it before. You learned to code, to debug, to ship. Now you just need to do it in real time, using natural language, in an ever-changing environment with far messier requirements.

Just an N-dimensional puzzle, no biggie. And I think you absolutely are up for the challenge.