The Art of Delegating

(This post was originally published in ACM Queue)

When I first started my career as a junior engineer, I couldn’t wait to be senior. I would review our promotion guidelines and regularly assess my progress and contributions against them. Of course, at that time I didn’t really understood what being senior meant.

Being a senior engineer means a lot of things: strong technical skills, ability to communicate, navigate ambiguous situations, and perhaps most of all the ability to grow and lead other people.

Leadership isn’t just for managers anymore.

I have worked with a lot of really talented engineers. And one thing I have noticed is that truly great engineers bring up the capabilities of everyone around them. Having them on the team makes everyone smarter, more productive, or more motivated.

The difference between being just an engineer and a senior engineer often has to do with your ability to mentor and grow your teammates. And mentoring is all about teaching and delegation.

When you are the senior person it means that you have the most experience (whether that is industry experience working with a specific set of technologies, methodologies, etc. or even just legacy knowledge of the systems you are using). And because you are senior it means that part of your job is to impart that knowledge onto others.

And when done well it is an amazing thing:

• All of a sudden you have time to work on new project XYZ instead of being burdened with legacy operations, support and fixes.
• You get to watch your colleagues grow and learn, taking on more responsibility and building their skills.
• Everyone is better and more productive because they are able to learn from past mistakes and take on new challenges.
• Woo!

However, when you are in this role of teacher it can be very challenging too:

• When you were the only one who knew system ABC you were so important. Everyone recognized you and came to you for help – and it felt good to be needed.
• It can be kind of fun to work on stuff that you are the expert on – it is nice to be able to tackle a task you know how to do (blindfolded, well maybe not blindfolded but with one hand tied behind your back).
• If I hand this over to someone else I am worried they are going to screw up all of the great work I have done.
• When it comes to delegating it seems like it can take much longer to explain how to do something than it would take you to just get the work done – and who doesn’t love to be efficient.

You know it is beneficial, but delegating is hard. You not just have to be able to trust someone to get the work done, but you have to know how much information to give enable them to make progress. And this can be really hard to do on gnarly technical problems. So how do you delegate things and teach others about something that seems very un-delegatable?

I have been there. I have seen this many times, and from all this experience I have some suggestions.

1. Change your mindset. You have heard that old saying, "Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime." Well it applies in work too. If you think that taking the time to explain something isn’t worth it, then you will never be able to teach anyone else. Sure, it takes more time than sometimes just doing the task yourself, but that time is valuable to the other person. You have to focus on growth and education, not necessarily efficiency.
2. Start small. This is the key to successful mentoring and delegating. You want to start with something that is easy to do – for example fixing a small bug, writing test cases, or adding documentation. When you start with something very tractable it gives the other person a chance to get their feet wet and a moment to peek inside the inner workings without getting overwhelmed. When you want to train someone on something new, try to find things that maybe aren’t urgent but are small, iterative improvements that would be an easy introduction into your realm of responsibility. Repeatable things
3. Lead them to figure it out. It can be easy to give someone the answers when they ask you a question. Next time this happens though, resist the urge to just tell them how to solve the problem. Instead ask them questions like:
   What have your tried so far?
   What have you considered trying?
   What did you research? Did you find anything?
   And then finally, have you tried looking up ____________? (where ________ is what you would look for to find the answer).
   You really want to lead them down your steps or your thought process on how you would solve the problem – not just give them the solution.
4. Help them come up with a plan. As you give someone more responsibility (like building a new feature) don’t just let them go out on their own. Instead have them draft up a plan and bring it back to you. Go over their approach together. Give them feedback (ideally by asking good questions instead of just giving them answers). When you can draft the idea together, you will feel more confident in their approach and they will be able to leverage your expertise and direction.
5. Setup some guard rails. Whenever someone takes on new responsibility in your team or organization it is a good practice to setup some checks and balances to make sure that things go smoothly (especially if you are handing over a mission critical part of software or operations). Figure out what information you need, and on what frequency, to feel confident things are where they should be. For example you could setup daily status meetings to go over progress, bi-weekly code reviews to go over implementation, or weekly one-on-ones with other people on the project. Try to identify what information you need to feel good about the progress and then the best way to get that information without being overbearing or micromanaging the details.
6. Don’t look for perfection. When someone is learning something it is unlikely they will get it right the first time. And when it comes to code, it seems like programmers are more like artists and everyone can interpret a task a little bit differently. Make sure you are open to these differences and you accept that other people may not do things the same way you would. If you are really worried about quality, define your quality up front when you assign the task.
7. Create a team of leaders. Last year I read the book Turn the Ship Around by David Marquet and one of the biggest lessons I learned from reading it was to adopt a leader:leader model instead of a leader:follower. Being a good leaders means allowing the people around you to be the experts in their domains. My favorite tip from the book that changed the way I lead was that when someone on my team would ask me a question, instead of giving them the answer I would ask “What do you think I would say?” Most of the time their answer would align with my thinking, and when it wouldn’t I realized that they were missing some important information or context I had neglected to share. This transformed my team to stop asking me questions, and instead make recommendations and ask for permission. How can you encourage your teammates to take more ownership and lead their own arenas?

Learning to coach and delegate is not easy. However when you build these skills it will make you even more valuable to your team. You won’t just be the person who is the expert, you will be someone who makes everyone better – and isn’t that the type of person you would want to work with?