Delegation is critical as you go up the engineering career ladder, becoming expected of senior and staff engineers and above. When you start delegating, it seems like a lot of work for unclear gain. But trust me, it's worth it. Once you get the hang of it, you'll kick yourself for not doing it sooner.
Initially, I perceived delegation as just "giving work to someone else to do". But if that's all you do, you'll find that the work doesn't get done on time, it's poor quality, you end up wasting your own time, and the person you delegated the work to gets stuck and frustrated. This post will go into why you should delegate more than you feel comfortable with, and how to do that effectively.
Really, delegate more than you are comfortable with.
Why delegate?
The cop-out answer: if you want to grow your career past a certain point: you have to delegate work. Or you simply won't get promoted or gain more responsibilities. Seniority is often a function of how much you can reliably get done, and there is only so much a single human being can do. To get more done, you have to scale yourself out. And to do that, you have to delegate.
Delegation has a lot of benefits:
- You can get more done (duh!). You can have the satisfaction of seeing larger projects succeed with your involvement
- Someone else gets the opportunity to learn from you
- When approached correctly, work is of higher quality (since there are now multiple pairs of eyes on it)
- The bus factor for that particular project/area gets better
It takes a mindset change to delegate well - you need to care more about achieving the end result and derive your motivation from that, rather than caring about doing the thing yourself. If that doesn't motivate you, and you want to get the rush of doing an exciting technical task by yourself, that's okay! Maybe delegation isn't right for you at this time. Please don't try to delegate work while keeping all the fun work for yourself - it leads to bad outcomes.
Think about the why's
Before handing off some work, think about why you're doing it in the first place. It's likely a given that you have too much work on your hands.
Are you doing it because someone is new to the team and needs to ramp up on an area? If so, you likely want to be more hands-on and provide more mentorship. Are you doing it so someone can take over ownership of a project? If so, you probably want to handhold a bit early on but then quickly delegate bigger pieces, and spend your time explaining the bigger picture. Are you doing it because someone needs help growing in their career? If so, you should be focusing on giving them ownership and taking a back seat from the get-go so they can learn by doing.
The art of effective delegation: it's all situational
Good delegation is about giving the right task, to the right person, at the right time.
Delegation is very situational - make sure you apply the right style at the right time. The Task Relevant Maturity framework is a great one to use, and I recommend reading up on it!
In short, you want to match the scope of the tasks to the experience the person has in the given area. If someone is an industry veteran with 20 years of C++ experience, you don't want to give them a beginner-level task in it. On the other hand, if that same person is asked to write UIs, you probably want to give them more concrete guidance. It's all situational.
Timing is also key - for most cases of delegation, you want to avoid tasks that are super urgent - as it's hard to learn and grow under pressure. At the same time, though -- once someone has taken over ownership of an area and an urgent task comes up, resist the urge to do it yourself. They'll likely do it faster and better than you at that point!
General strategies for delegation
- Seek to understand: Before delegating a lot of work to someone, talk to them, and understand their wants, motivations, and skills - that will help you frame the work you give them in an appropriate manner.
- Inspire people: Don't jump in and talk about the task at hand. Talk about the broader project, what the team does, and what the org does. Explain how the task at hand fits into the broader goals so that they can think of ideas to expedite/improve the task while still meeting the broader goals. This is especially useful when you have to decide which corners to cut after getting stuck - something you want them to do independently after a while. And it helps people come up with new and exciting project ideas.
- Trust, but verify: It's hard to let go. But when you give someone a task, trust them to get it done well. And then when the work is done, go over it with a fine-toothed comb to verify it meets your standards. Over time, you'll be able to trust them more and even delegate the verification responsibilities to them. But make sure to regularly verify some part of the work, or at least ask how they did it.
- Set clear expectations: The most common problem I see when delegating work is that you tell someone what you want to be done, they do what they think you wanted them to do, and later on you realize they worked on the wrong thing. Try to over-communicate and be explicit. Better yet, ask them to repeat the task description (or write it down) in their own words, so you can correct the misunderstandings upfront.
- Set clear deadlines: In addition to making the what clear, make the when clear. Set a clear deadline for when you want something done. Even if there isn't a hard deadline, set a rough one - so people can prioritize the work accordingly, and have some structure. Especially when a task is large - set earlier deadlines for each milestone and check in regularly to make sure things are on track.
- Check in regularly: You can't just delegate work, forget about it, and have it all work out. Check-in regularly - even unprompted - and ask how things are going and if you need to provide any help. Many a project has been delayed cause the mentee was stuck, waiting for guidance, while the mentor assumed the mentee would ask when stuck. Setting deadlines helps with this, but you need to be proactive and check in regularly.
- Provide structure: Early on, it can be overwhelming to take on a large task. When you give someone a big task and ask them to get started, it's quite likely they will get stuck and just spin their wheels without guidance. Point them to examples of similar tasks they can learn from. Talk to them about how you've approached similar work in the past. Help them break up the task and check in regularly - e.g. ask them to break the task down into deliverables, verify those, then ask them to come up with an implementation plan, then watch them execute it, etc.
- Ramp up the difficulty over time: Early on, you'll probably have to spell out tasks in great detail so they get done correctly. As your mentee improves, though - save yourself some time, and help them grow by letting them break the task down themselves, or even write out a detailed description. And then let them own the whole feature. Then the whole project, etc. They'll be happy, you'll have more time, and everyone wins.
- Teach a man how to fish...: This was a hard one for me. Instead of jumping to provide a solution when someone is stuck, take a step back and ask them how they would solve the issue. Let them ask questions and guide them through the debugging process. If you tell them what to do, they'll do it, and then ask you for help the next time they are stuck. If instead, you teach them how you solve a problem, they'll learn from that, apply it next time, and hopefully avoid getting stuck in the first place.
- Make the teaching explicit: There's a natural tendency for people to want to be told what to do. Explain that you are trying to help them grow, and don't want to bias them with your thoughts. Ask them for their approach to a problem, and discuss the tradeoffs, before giving them your solution. Ask them to contrast their approach to yours, so they can learn from your way of thinking. Don't overdo this, though -- sometimes they might just need explicit direction and not be in the mindset for coaching.
Common refrains
It was hard for me at first to delegate more work. I would whine on and on and get frustrated. Here are things I've complained about and heard others complain about:
- "But I don't have time to delegate!". Delegation is always a time-sink in the short term. People will need to ramp up, and there is communication overhead. But, over time, the payoff is large. It's an amazing feeling when you can just have a 5-minute conversation with someone and then they go off for a month and build the perfect thing. If you don't take the hit now, you'll never get that long-term payoff.
- "But then I'll miss out on the fun stuff!". Well, you will miss out on some things (doing the actual work yourself), but there are a lot of things you won't miss out on. Realistically, you'll probably still work on the hardest, most difficult challenges (people will get stuck and need your help). And even if you don't, you will get to learn about all of those things - as you verify people's work, you can ask them to explain how they did it and learn from that. For me, a personal favorite was that I could get people to explore ideas I had always wanted to do but never had the time for - and then learn from their experiences.
Mistakes I've made and learned from
I've certainly made a lot of mistakes along the way. Here are some I made and learnt from:
- Over-preparing before delegating: As called out in my last post, I had a tendency to spec out work and give people very very fine-grained tasks to do. That's great for someone's first week or month but is actively harmful to career growth. I became a single point of failure for the team until I stepped back and let people own those bigger pieces of work.
- Not finding more opportunities to delegate: For a while I'd complain about all the project meetings and collaboration syncs I had to go to. It took me a while (and some helpful feedback) before the solution was painfully obvious: I should delegate those. I focused too much on the "what" - going to those meetings, gathering work items and projects, and delegating to the team; but the team became dependent on me in a different way: I was the main source of project ideas. By bringing others along to these meetings (and delegating them), people grew their collaboration skills, I found more time, and people came up with way better project ideas than I could have on my own. As you work, think about where you're spending a lot of your time and try to delegate more than you're comfortable with. It'll work out okay. I promise.
- Jumping to solutions: It took me a while to change my default response from "here's how you should do this" to "what have you tried to do? why didn't it work?" when someone got stuck. Just that simple mindset change was enough to help people get much more out of their projects, and it helped them take on bigger chunks of work.
Conclusion
Delegation is hard, and it's a lot of work. But it's worth it - you just need to work on it like any other skill. Once you understand your job is to delegate and get things done, you'll be happier and more effective. With practice, you'll become a pro.
As always, please reach out with comments and feedback, and opinions on which topics you'd like me to expand on first!
Many thanks to Yaohui Chen for the fruitful discussions which prompted this post.