Everyone tells you the same thing when you move into leading a dev team. "Now you stop writing code." Cool. I get it.
I lead a dev team at a digital agency. Frontend, backend, client work, mixed stacks, real deadlines. So when I made that move, I had a pretty clear picture of what the job would be. I was mostly wrong about it.
What I thought the job was
I thought leading meant being the person who makes the hard technical calls.
The architecture decisions. The "should we use WordPress or go headless on this one" conversations. The hairy bug nobody else can crack. The code review where I catch the thing that would have blown up in production.
That was the real work in my head. Everything else felt like overhead.
That part of the job does exist. But it's maybe twenty percent of it. The other eighty is something nobody really prepares you for.
The first time someone got stuck
Early on, someone on the team hit a wall on a ticket. I looked at it and saw the fix in about thirty seconds. My hand was already moving to the keyboard.
Then it hit me. The right move depends on how clear it actually is to me.
If I have it crystal clear, fine, I fix it and move on. No ceremony. But if I have any doubt, that's the signal to not solve it alone. That's when we work it through together with the person who owns it, and sometimes it's worth pulling in someone else too. The doubt is not a weakness to hide. It's the most useful thing in the room, because it's exactly where the team learns something instead of just receiving an answer.
If I fix everything the second I see it, the bug is gone today and the person is no better next week. So now I check myself before grabbing the keyboard. Is this a thirty-second fix I can hand back with an explanation, or is this a "let's look at it together" moment. That single question reset how I think about the whole role.
The moment delegation starts working
Here's the part that genuinely surprised me with how good it feels.
When you start transmitting clear ideas, and the other side responds the way you would have done it yourself (or at least follows your work patterns at 80%), something clicks. You hand off a piece of a project, you brace for it to come back wrong, and instead it comes back right. Maybe better than right.
So you hand off a bigger piece. Then a whole feature. Then a whole project.
That's the addictive part of the job nobody warns you about. Not control. The opposite of control. Watching a thing you used to hold get done well without you in the loop. The first time it happens you almost don't trust it. After a while it's the most satisfying part of the week.
You start seeing who they really are
The more this happens, the more you start noticing the shape of each person.
One gets sharp on performance. Another is the one who actually enjoys untangling a messy data model. Someone turns out to be great at the client conversation you used to dread. These specializations don't show up in a job description. They show up over months, in small moments, and a big part of leading is just paying attention long enough to see them.
And then the job is to expose them. A retro is one of the best places for this. When someone solved something clever, I don't summarize it for them. I put them in front of the team and let them walk through it. People need to be seen for what they're good at, by the people they work with, not just by me in a 1:1. That visibility is fuel, and it's free.
Throwing people into the deep end
The harder version of this is putting people into situations you've already lived through.
I've been in plenty of those. Some I walked into well prepared. Plenty I learned the hard way, getting hit until I figured it out. Part of leading is deciding when to recreate that on purpose for someone else.
Sometimes it's planned. You give someone a project that's slightly above their current level because you've seen enough to know they'll rise to it. Sometimes it's a bit "a los golpes", you let them take a hit you could have softened, because the lesson only lands when it costs something.
The skill is calibration. Too easy and they don't grow. Too hard and you break their confidence instead of building it. You're constantly guessing where that line is for each individual person, and you don't always guess right.
The variable nobody puts in the spreadsheet
And here's the thing that makes all of this messy: people aren't constant.
When I decide who goes on which project, the technical fit is only half the equation. The other half is where the person is at. Someone coming off a brutal sprint shouldn't get dropped into the next firefight. Someone who just nailed something hard might be exactly ready for a stretch. Someone going through a rough patch outside work needs a different kind of ticket this month.
And personal situations cut both ways. Sometimes life outside work is a distraction that pulls someone off their game. Sometimes the work is the calm, the steady thing someone holds onto while everything else is moving. Reading which one it is, for which person, in which week, is part of the job too.
You can't put that in a staffing spreadsheet, but it's real, and ignoring it is how good people burn out on your watch. Skill, timing, morale, what else they're carrying, who they work well with. A lot of things matter, and most of them have nothing to do with code.
Here's the payoff for getting this right over time. Even when I have to be out for four days, the team holds. They respond at maybe 80% to how I've taught them, and the gap between that and 100% is mostly the screwups I made and learned from the hard way, the ones I can now spare them from repeating. That's the whole point of teaching instead of just fixing.
And to be fully honest, I've had a margin of comfort that not every lead gets. Part of my team has been solid for more than six years. There's a real bond there, in every sense, and I don't take it for granted. I hope it stays that way. A lot of what works isn't a system I designed. It's trust that took years to build.
It's not a promotion, it's a different job
This is the thing I'd tell anyone moving into it. Leading a dev team is not "senior engineer plus meetings." It's a career change that happens to keep the same job title.
The skills barely overlap. Being great at the code can even get in your way, because it makes the keyboard so tempting. The new job is teaching, reading people, knowing when to delegate, knowing when to expose someone and when to protect them, and keeping a group of humans pointed in the same direction. The code is the most visible part. It's not the part that needs you most.
The first time someone on the team builds something better than what I would have written, a small part of me wants to find a flaw in it. That reaction is the trap. If everything good has to come from me, the team has a ceiling, and the ceiling is me. The whole job is raising that ceiling above my own head. You're trying to make yourself the least impressive engineer on the team over time. That's success, not failure.
I used to think this was the boring half of the work. Now it's the part I find genuinely interesting, because it never gets "done." There's always another person to read, another call to calibrate, another thing to hand off and watch come back better than you left it.
If you're about to make this jump, go in knowing you're starting a new job, not getting a reward for the old one. The sooner you stop reaching for the keyboard, the sooner you're actually doing it.
