When Your Job Shifts From Doing the Work to Leading It
How to let go of tasks, grow your scope, and stay productive as a new lead
The first time my manager said “you’re ready for a bigger scope,” I made a dumb assumption.
I thought I was ready to take this “easy extra task”.
But I didn’t change anything about how I worked.
Same code ownership, same incident pings, same review queue, same “let me just take this one, it’s faster if I do it.” The only thing I added was more: more meetings, more cross-team discussions, more planning. On paper, my role changed. In practice, I was still behaving like a senior IC who’d been handed extra chores.
Weeks later I was exhausted and quietly asking myself a question I hear from a lot of tech leads: if I’m not the one doing the hard work, what exactly is my job?
This is the gap nobody really prepares you for. When your scope grows, the company is not asking you to do more tasks. They’re asking you to own bigger outcomes, carry more risk on behalf of the org, and create clarity where there wasn’t any. The catch is that you can’t do that while still holding all the same individual work you had before. Something has to give.
I think of my time now in three rough categories. There is doing the work. There is enabling other people to do the work. And there is shaping which work exists at all. As a strong IC, you mostly live in the first category. When your scope grows, your calendar needs to move toward the second and third. If it doesn’t, you end up in a strange place: overloaded and yet underused at the same time. You’re busy all the time but not really moving the things your new role is supposed to move.
The mistake many of us make, and I absolutely did, is trying to keep that first category the same size so we “don’t lose our edge.” You don’t lose your edge. You just lose sleep.
There are a few signals that you’re stuck in this in-between state. You finish most weeks feeling like you worked hard but moved nothing that matters a quarter from now. Your one-on-ones are mostly status updates, because you already know every detail from being deep in the code and the incident channels. You’re the contingency plan for every risky project: if it gets hairy, everyone knows you’ll jump in. Your calendar is full, but when your manager asks, “Who owns this area?” the honest answer is still “me, accidentally.” When two or three of those are true, you’re not in bigger scope yet. You’re in same scope, new title.
Letting go is not a soft, vague skill you pick up in a leadership training. It is a very concrete change in how you operate.
The first move for me was deciding what only I can do now. Before delegating anything, I sat down and wrote my real responsibilities in this new role. In a tech lead or Engineer Manager seat, that list usually includes things like choosing technical direction for a set of systems, protecting the team from randomization and bad bets, making sure every important area has a clear owner, and growing at least one or two people into the next level. That is the job.
Once that list is clear, the next question becomes much easier: what am I doing today that someone else could realistically do within three to six months with support? That’s the work you need to let go of. If you skip this step and start “delegating” randomly, you’ll default to giving away only the boring work while keeping the interesting problems for yourself. People notice. They feel it. And they stop believing that what lands on their plate is real ownership rather than overflow.
A very practical thing that helped me was doing a short work review over a week or a sprint. I wrote down everything I coded, every decision I made, every meeting where I was essential versus just present. Then I tagged each item in my own notes: this really has to be me because of context, relationships, or risk; this could be me for now but someone can grow into it; this doesn’t need me at all. My goal over the next few months was to shrink the first group and move items from the second to the third. Nothing fancy, just intentional.
Once you know what to let go, the question becomes how to do it in a way that actually grows people instead of dumping on them. There is a big difference between throwing tasks over the wall and handing over ownership. “Can you take this, I’m too busy” is dumping. “This is yours now, here’s why it matters, where the boundaries are, and how I’ll support you” is ownership.
When I hand off something meaningful, I talk through four things. I explain the context: what problem this work exists to solve, who cares, and what good looks like. I clarify decision rights: what they decide alone, what we decide together for a while, and what I still own for now because of risk or politics. I describe the safety net: when they should pull me in, how we’ll review decisions, where the docs and history live. And I give a time frame: my aim is that in a few months you’re making almost all the calls here without me. That time frame matters, because without it people assume you’re just overloaded and will take it back as soon as you “have time again.”
Behind all of this sits a very real question your reader raised: when and how do you detach, when do you trust, and when do you cut the cord? I don’t treat that as a gut-feel problem. I look at risk, visibility, and experience. Risk is about what happens if this goes wrong. Visibility is about who is depending on this work and how public the failure would be. Experience is how many similar problems this person has owned before.
If something is high risk and the person is early in that area, I stay close but let them drive. They lead discussions, they write the docs, they speak in reviews, and I sit next to them. I ask questions, I model how to think about trade-offs, I intervene if we’re about to violate a regulation or an SLA, but I don’t rip the work out of their hands at the first sign of discomfort. As their experience grows or as we move into smaller, less visible changes, I increase the distance. I stop joining every meeting. I move from reviewing every decision up front to reading summaries. At some point my involvement switches from approving details to occasionally adjusting direction.
That distance is not fixed. I keep adjusting it based on those three axes. Trust is not all-or-nothing; it is how far I let you run before I check in, and that distance expands as you show you can handle it.
The harder part in all of this is not the mechanics. It is how you feel about your own productivity. For years, your sense of a “good day” probably came from visible output: tickets closed, pull requests merged, bugs fixed at 11:30 p.m. In a bigger scope role, your impact becomes slower and less visible. You might spend an afternoon aligning two teams so they don’t ship conflicting solutions, reworking a roadmap so the company isn’t betting everything on one fragile dependency, or coaching someone through a design so they can lead it without you. None of that shows up on a GitHub chart.
What helped me was changing what I count as a productive day. I started asking myself different questions. Did I make it easier for the team to move next week? Did I reduce risk on anything that would hurt us in the next few quarters? Did I grow someone’s capacity so that a year from now they won’t need me for this category of decision? If the answers were yes, that was a good day, even if I hadn’t written a line of code.
You can make this more concrete if you like numbers. Look at how many decisions are now made without you that you would have made a year ago. Look at how many systems or areas have clearly named owners who are not you. Look at how often people start conversations with “we decided” instead of “I was waiting for you to weigh in.” Those are all signs that your scope is actually bigger, not just heavier.
The last piece is the identity shift. Letting go means watching someone make a call you would have made differently. It means seeing a system you built evolve in a direction you wouldn’t have chosen. It means hearing about an incident in a domain you know well only after it’s already solved. Early on, that can feel like losing status or relevance. Your brain wants to jump in and prove, again, that you can still crack the hard problems.
When that discomfort kicks in, I try to pause and write down the thing I’m tempted to fix personally. Then I ask: what would need to be true for this kind of decision to be made well by the team every time without me? The answers to that question become my real work. Maybe it’s clearer guidelines. Maybe it’s a better review forum. Maybe it’s coaching one person so they become the go-to in that space. In all cases, the result is the same: my attention moves away from the specific incident and toward the system that produced it.
If you’re already in a tech lead or manager seat and you feel like you’re half IC, half firefighter, half therapist — yes, that’s three halves — you don’t need a reorg to change this. You can start small. Pick one area where you are the de facto owner. Pick one person who could grow by owning more of it. Have an honest conversation about what ownership would mean, why it matters, how you’ll support them, and what success looks like a few months from now. For the next big decision or incident in that space, let them lead while you sit in the second chair. Afterwards, review together what worked, what scared them, and what you both would do differently next time.
Over a few cycles, the texture of your work starts to change. Your calendar will probably still be full, but it will be full of different kinds of problems. Less “do it myself before it breaks,” more “shape the work, grow people, steady the system.” Your feeling of productivity shifts from “I fixed it” to “we can handle it.”
That’s when bigger scope stops being a sentence and starts being real. Not just more things on your to-do list, but a different job: one where letting go is exactly what creates space for the work you were actually promoted to do.