On July 20, 1969, as the Apollo 11 lunar module descended toward the moon’s surface, alarms started blaring in the cockpit. Error 1202. Then 1201. The computer was overloaded. Fuel was running critically low—the crew thought they had less than 20 seconds left. Mission Control had to decide: abort or continue?
They continued. The astronauts landed safely.
Why? Because Margaret Hamilton, who led the team that built the Apollo Guidance Computer software, had delegated brilliantly. Each engineer owned a specific module of the system. One person owned the priority scheduling code. Another owned the landing algorithms. When multiple programs demanded attention during descent, the software knew exactly what to prioritize and what to ignore. Clear ownership plus clear outcomes saved the mission.
Hamilton’s team had only 72KB of memory to work with. Every line of code mattered. She couldn’t micromanage every decision. She had to trust her engineers to own their pieces completely.
If you’re a tech lead struggling with delegation, you’re not trying to land on the moon. But the principle is the same: you can’t do everything yourself, and pretending you can will crash the mission.
Here’s how to delegate effectively without losing your mind.
1. Delegate What You Most Want to Do Yourself
This sounds backward, but it’s the most important rule.
Everyone tells you to delegate the boring stuff. The problem? You won’t support it properly. You’ll hand someone garbage work, disappear, and wonder why they’re not motivated.
The best approach: Start by understanding what they want to work on.
Ask: “What kind of work energizes you? What do you want to get better at?”
Then delegate that. Work that aligns with their growth goals and interests is the most powerful kind of delegation. They’ll be motivated. They’ll push through obstacles. They’ll learn faster.
If you can’t delegate what they want, give away something you’re excited about. The feature that’s perfectly in your wheelhouse. Give it to someone who’s about 70% ready (not 50%, not 95%).
Why does this work? Because you care about it, so you’ll actually show up to help them. You’ll answer questions thoughtfully instead of with annoyed half-answers. Meaningful work motivates people when someone actually supports them through it.
The reality: Sometimes you just need to delegate the boring stuff. Nobody wants to refactor old test files or update documentation. But if that’s all you ever delegate, you’re teaching people that “delegation” means “dump the garbage on you.” When you have to delegate unglamorous work, be honest about it, make it time-boxed, and balance it with something they actually care about.
The exception: Don’t delegate what’s causing you actual anxiety. If you’re losing sleep over an architectural decision or a critical path item, keep it for now. Anxiety is different from interest. Delegate the work you want to do, not the work that terrifies you.
2. Delegate Problems, Not Tasks
Bad delegation: “Add a Redis cache to the checkout endpoint.”
Good delegation: “Checkout is timing out for 5% of users. Figure out why and fix it.”
The difference is ownership. In the first version, they’re your hands. In the second, they get to think, investigate, and propose solutions. They own the outcome, not just the execution.
This is harder for you. You already know Redis would probably work. But handing someone the answer means they don’t learn how to find answers themselves. And you stay the bottleneck forever.
Script to use:
“I’m seeing checkout timeouts for about 5% of users. Can you investigate what’s happening and come back with a proposed solution? I’m thinking this is yours to own end-to-end. Let’s check in Friday to see what you’ve found.”
3. Define Clear Outcomes (With Checkpoints)
Vague delegation kills projects. “Improve the performance” gives someone nothing to aim for.
Clear delegation: “Get checkout timeouts under 1% by end of next sprint.”
For longer projects (more than two weeks), break it into weekly outcomes:
Week 1: “Have a working skeleton. Routes set up, models defined, tests passing.”
Week 2: “Core business logic implemented and tested.”
Week 3: “Integration with the payment API working in staging.”
Week 4: “Edge cases handled, ready for production.”
Add demo checkpoints: “Let’s have a 15-minute demo each Friday. Show me what’s working and what’s blocking you.”
This isn’t micromanaging. This is preventing someone from going silent for three weeks and then showing up with something completely wrong. Checkpoints let you correct course early when it’s cheap, not late when it’s expensive.
What about more junior engineers?
Give them the outcome, the milestones, and the constraints. Let them figure out the how.
“Here’s what we need. Here’s the rough timeline. Here’s the one thing you can’t do (don’t change the database schema without talking to me first). The implementation is yours. Let’s check in weekly so I can unblock you.”
4. Match the Delegation Level to the Person
Not everyone needs the same amount of structure. And the same person needs different levels for different work. A senior engineer might need Level 1 on their first time with your deployment pipeline. A junior developer might be at Level 3 for the feature they’ve shipped three times.
These levels aren’t about seniority. They’re about familiarity with the specific work.
Level 1: Let me show you how
For brand new team members, unfamiliar territory, or high-risk work.
“Watch me do this first. Then you try while I watch. Then you do it alone.”
Move them to Level 2 when: They stop asking basic questions and start asking strategic ones.
Level 2: Explain your approach first
For intermediate familiarity on medium-risk work.
“Here’s the problem. Come back with your proposed approach. We’ll discuss it. Then you implement.”
Move them to Level 3 when: They consistently come back with solid approaches that need minimal adjustment.
Level 3: Just handle it
For anyone who’s proven they can handle this type of work.
“This is yours. Tell me when it’s done. Come to me if you need something.”
These are your most valuable people. They multiply your impact.
Your goal: Move everyone to Level 3 on as much work as possible, as fast as safely possible.
If you misjudge: Maybe you give someone Level 3 and they struggle. That’s fine. Just dial it back. “Hey, let’s add a checkpoint on Friday to make sure we’re aligned.” No shame in recalibrating.
The uncomfortable truth: Eventually, some of them might replace you. They’ll be ready for your role, or a role beyond it. That’s not a threat—it’s the entire point. If you’re doing this right, you’re building people who don’t need you anymore. That’s how you earn your next level.
5. Handle Pushback With Curiosity
Someone says: “I don’t think I’m ready for this.”
Bad response: “Sure you are! I believe in you!” (Translation: I’m not listening.)
Good response: “What specifically worries you? Let’s figure this out together.”
Then actually listen. Sometimes they’re right. They’re missing key context or a critical skill. Sometimes they just need one piece of information to feel confident. Sometimes it’s fear of failure, and your job is to create safety.
Options when someone pushes back:
Pair with them for the first two hours to get them started
Reduce scope: “Let’s start with just the investigation, not the fix”
Add more checkpoints: “Show me your approach before you implement”
The worst thing you can do is bulldoze past their concerns. Either they’ll fail because they actually weren’t ready, or they’ll succeed but never trust you again because you didn’t listen.
6. Track Multiplication, Not Output
Here’s the uncomfortable truth: when you start delegating well, you’ll feel useless.
Your commits drop. Your visible output shrinks. You watch someone struggle for three hours with something you could fix in twenty minutes. This discomfort is the signal you’re doing it right.
But it doesn’t feel right. It feels like you’re not contributing. Like you’re just... watching.
That feeling is partly about your manager’s perception, but mostly it’s about your own identity. You’ve spent years tying your worth to lines of code shipped. Now you’re succeeding by not shipping code. That’s a hard mental shift.
The practical fix: Redefine success proactively, not defensively.
Don’t wait for questions. Send a brief weekly update to your manager. Make it short—three to five bullets max.
Format: What the team shipped + your role in making it happen.
“Team wins this week:
Payment integration shipped (reviewed Max’s architecture, paired on the tricky API design)
Analytics dashboard done (got product and data teams aligned on requirements)
Unblocked Sara on the database migration (connected her with the DBA team)”
That’s it. No apologies. No “I didn’t code much but...” Just matter-of-fact reporting of how you multiplied the team’s output.
If your manager doesn’t get it:
Good managers ask about the team. But not every manager understands what tech leadership actually looks like. Some still think in individual contributor terms. If yours asks “Walk me through your week” or seems confused about what you’re doing, be direct:
“I’m spending less time coding and more time unblocking the team. The tradeoff is worth it—we’re shipping faster. Max delivered ahead of schedule because I kept him from getting stuck.”
Keep it brief. Show the impact. Don’t apologize for the shift.
About coding yourself:
Sometimes you’ll still write code. Maybe you fix something small because it’s genuinely faster. Maybe you pair on something complex. That’s fine.
But don’t write code just for optics. Don’t hold onto tickets so you have something to show. That defeats the entire point.
The harder part: Your own head
Your manager might adjust quickly. You probably won’t.
You’ll still feel that nagging sense that you’re not really working. That you should be doing more. That watching someone struggle is laziness, not leadership.
Keep a private doc of what you enabled each week. Not for performance reviews—for yourself. So when that voice tells you you’re doing nothing, you can look back and see: your job changed. Your impact didn’t shrink. It multiplied.
It takes time to internalize that. Be patient with yourself.
7. Understand Your Context (The Honest Part)
Everything above assumes you’re in a reasonably healthy environment. Sometimes you’re not.
If you’re in a blame culture:
You can’t delegate freely when mistakes get punished harshly. Start smaller. Delegate with extreme safety nets. Build trust before autonomy.
Honestly? If it’s truly toxic, delegation won’t work. Start looking elsewhere. You can’t grow people in an environment that punishes growth.
If they succeed and you don’t get credit:
This will happen. It feels terrible. Reframe it: you’re building a track record of growing people. That’s literally how you get to senior leadership. Staff engineers who can’t multiply themselves through others stay individual contributors forever.
If you’re working on complex research with no clear “output”:
Frame research as valuable output. Instead of “still researching,” say:
“Ran a spike on three database options, documented trade-offs, got team alignment on Postgres. Saved us six weeks by proving approach X won’t work before we committed to it.”
Action plus impact plus time saved. That’s your formula.
Back to Margaret Hamilton and Apollo 11. When those alarms went off, she wasn’t in Mission Control. She was at MIT. She didn’t rush in to fix it herself. Her team’s code, designed with clear ownership and priorities, handled it automatically.
That’s what good delegation looks like. You build the system where the right people make the right decisions without you in the room. Then you trust it.
You won’t land on the moon. But you will ship more, grow your people faster, and maybe actually leave work on time occasionally.
P.S. If you’re working on this transition from IC to tech lead, I’m building a private community for senior engineers. Weekly calls, real examples of delegation and leadership, and support from people doing the same work.