Work Through Your Team, Not Around Them
If you’re stepping into engineering leadership—or already there—you’ll eventually face a hard truth: you can’t do it all yourself. Not even close.
The Shift From Doer to Enabler
Early on, you can juggle both. You’re hands-on, reviewing PRs, cranking out fixes, shipping features and managing your small team. But as your scope grows, that balance breaks.
Now you’ve got eight, nine, maybe more people. Some report directly to you. Others report to someone you manage. And your calendar? Packed. You don’t have time to code full features anymore. You might barely have time to breathe.
That’s when the real transition happens: from doer to enabler. From building things yourself to getting things built through others.
Why This Was So Hard for Me
I’ll be honest—this was a growth area for me. Not because I didn’t trust my team, but because I’d been doing this stuff for a while and, yeah, I could knock out a lot of tasks pretty fast.
But that’s not scalable.
My job now isn’t to do the work. It’s to make sure the work gets done—by the right person, at the right time, with the right level of support.
Choosing Who Gets the Work
Sometimes, the task is perfect for a senior on your team—someone who knows the space and can fly. Great, assign and get out of their way.
Other times, it’s a growth opportunity. You know it’ll take longer, and you’ll need to be involved at the beginning. That’s okay. That’s the job. You’re not just shipping code—you’re growing people.
Knowing which type of task requires which type of assignee is a skill. And yes, that’s a whole separate blog post.
When the Project’s Bigger
For larger projects, I take a slightly different approach.
Instead of jumping straight to tickets, I create a short document that outlines:
- What the project is
- Why it matters
- Any major constraints or risks I can already see
- Rough ideas for how it might be approached
Then I’ll hop on a quick 15- to 20-minute call with the person I’m assigning it to. We’ll talk through the context and expectations, and I’ll answer any upfront questions.
After that, I ask them to break down the project into smaller tasks on their own. This serves three purposes:
- They take ownership of the project.
- They understand the work at a deeper level.
- I get to see how they think and how they approach the problem.
This is one of the best ways I’ve found to build autonomy, skill, and confidence in my team.
Write It Like Someone Else Will Read It
Whether I’m assigning a one-off task or following up on a project breakdown, clarity is everything. I write each task like someone outside the room might read it—because they might.
I like to think: “If a QA person picked this up to validate it and hadn’t been part of any prior meetings, would it still make sense?”
That’s the bar.
My Task Template
Here’s the format I use for assigning almost everything:
- Problem Statement – What’s broken? What needs fixing?
- Desired Outcome – What does “done” look like?
- Information / Proposed Steps – Optional, but helpful. Any background, links, context, or starting points.
- Definition of Done – The checklist. If this isn’t complete, the task isn’t either.
This system forces me to slow down just enough to express myself clearly. And it makes it way easier for my team to take things and run.
Why This Matters
The bigger your team gets, the more your job becomes about leverage. Whether it’s a clear Jira ticket or a quick kickoff doc for a larger initiative, your role is to create the conditions for your team to succeed.
Clear tickets. Structured project setup. Intentional delegation.
That’s how you go from a team of one to a team of nine actually getting 9x the work done—and growing stronger while doing it.
💡Liked this post?
Get real-world solutions like this in your inbox—join the newsletter.