Communications of the ACM
Practice
Delegation as Art
Credit: megaflopp
When I started my career as a junior engineer, I could not wait to be senior. I would regularly review our promotion guidelines and assess my progress and contributions against them. Of course, at the time I did not really understand what being senior meant.
Being a senior engineer means having strong technical skills, the ability to communicate well and navigate ambiguous situations, and most important of all, the ability to grow and lead other people.
Leadership is not just for managers anymore.
I have worked with many genuinely talented engineers throughout my career. I have noticed that truly great engineers bring forth the capabilities of everyone around them. Having them on the team makes everyone brighter, more productive, and more motivated.
The difference between being an engineer and being a senior engineer often has to do with the ability to mentor and grow your teammates. Mentoring is all about teaching and delegation.
Adding senior to your title means you have the most experience (whether that is industry experience working with a specific set of technologies, or methodologies, or simply legacy knowledge of the systems you are using). And because you are senior, part of your job is imparting that knowledge onto others.
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 more productive and hard working because they are able to learn from past mistakes and take on new challenges.
- Woo!
Taking on the role of teacher can also be very difficult:
- 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 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 or 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 to someone else than it would take you to get the work done yourself—and who does not love to be efficient?
Even though you know it is beneficial, delegating is difficult. You not only have to be able to trust others to get the work done, but you also must know how much information to give them that will enable them to make progress. This can be really difficult to do on gnarly technical problems. How do you delegate tasks and teach others about something that seems very un-delegatable?
I have seen this many times, and from all of my experience I have come up with some suggestions.
Change your mind-set. 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 your career, too. If you think taking the time to explain something is not worth it, then you will never be able to teach anyone else. Sure, it takes more time than doing the task yourself, but that time is valuable to the person you are teaching. You have to focus on growth and education, not necessarily efficiency.
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 his or her 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 small things that are not urgent—iterative improvements that would be an easy introduction into your realm of responsibility; repeatable things.
Lead them to figure it out. It is easy to give people answers when they ask you questions. Next time this happens, resist the urge to tell them how to solve the problem. Instead ask them questions like:
- What have you tried so far?
- What have you considered trying?
- What did you research? Did you find anything?
- Have you tried looking up ________? (the blank representing what you would look for to find the answer).
You want to show them the steps you would take and lead them through your thought process—how you would solve the problem—instead of simply providing the solution.
Help them come up with a plan. As you give people more responsibility (for example, building a new feature), do not 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 draft the idea together, you will feel more confident in their approach and they will be able to leverage your expertise and direction.
Set up some guardrails. Whenever someone takes on new responsibility in your team or organization it is good practice to set up some checks and balances to ensure things go smoothly (especially if you are handing over a mission-critical part of software or operations). Figure out what information you need, and how frequently, so you can feel confident things are where they should be. For example, you could set up daily status meetings to go over progress, biweekly 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.
Don't look for perfection. People learning something new are unlikely to get it right the first time. And when it comes to code, it seems like programmers are more like artists, with each individual interpreting 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, specify your definition of quality up front when you assign the task.
Being a good leader means allowing the people around you to be the experts in their domains.
Create a team of leaders. Last year I read the book Turn the Ship Around!: A True Story of Turning Followers into Leaders by L. David Marquet (Portfolio, 2013) and loved it. One of the most substantial lessons I learned from the book was to adopt a leader:leader model instead of a leader:follower model. Being a good leader means allowing the people around you to be the experts in their domains. My favorite concept from Marquet's book that truly changed the way I lead was this: when someone on my team asks me a question, instead of giving them the answer, I ask them, "What do you think I would say?" Most of the time their answer aligns with my thinking, but when it does not, I realize they are missing some important information or context I have neglected to share. This transformed my team; they stopped asking me questions and instead started making recommendations and asking 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, but once you build these skills, you will become even more valuable to your team. You will not just be the expert; you will be someone who makes everyone better—and isn't that the type of person you would want to work with?
Related articles
on queue.acm.org
Best Practice BPM
Derek Miers
http://queue.acm.org/detail.cfm?id=1122688
Evolution of the Product Manager
Ellen Chisa
http://queue.acm.org/detail.cfm?id=2683579
The Science of Managing Data Science
Kate Matsudaira
http://queue.acm.org/detail.cfm?id=2767971
The Digital Library is published by the Association for Computing Machinery. Copyright © 2016 ACM, Inc.
Comments
CACM Administrator
The following letter was published in the Letters to the Editor of the July 2016 CACM (http://cacm.acm.org/magazines/2016/7/204035).
--CACM Administrator
I commend Kate Matsudaira's wonderful article "Delegation as Art" (May 2016), with its spot-on guidance for addressing challenges in mentoring and delegating our co-workers and students; like Matsudaira, I love to imagine my teammates asking themselves, "What would Geoff say?" Matsudaira also did a superb job explaining her suggestions in ways that make them applicable to disciplines well beyond engineering.
However, one key challenge in managing software engineers Matsudaira did not address is that senior engineers are often expected to mentor team members while simultaneously being responsible for delivering the very projects on which the mentees are working. Matsudaira did say mentoring and delegation require letting people find their own way and make mistakes, even as project success is often measured by speed of delivery and perfection. As a result, mentoring success sometimes comes at the expense of project success, and vice versa.
It would benefit us all if our managers and project managers had a better understanding of the value and process of mentoring. To this end, I will be sharing the article with fellow leaders in my organization and recommend you share it with yours as well.
Geoffrey A. Lowney
Issaquah, WA
Displaying 1 comment