Anyone who’s had to coach a new leader or a manager can probably relate. Delegation is the primary thing I’ve seen new leaders struggle with. The good thing is, most everyone is aware of their struggle with this. The unfortunate thing is, hardly anyone has an answer to how it might work.
I’ve struggled with this myself when I made my transition to leading software engineering teams. It took me years to finally decide to let go of control (not the easiest thing to do) and allow others to shine in their work.
How did I know I was finally doing a good job? When I took a week off from work and, bar a few phone calls, everything ran as smooth as when I was in the office. Funny thing is, it probably would have always had gone that well and I just never had the guts to let it happen until then.
Why is it so difficult?
Software engineers are problem solvers by nature, but our view of a problem, and its solution, is often a narrow one. Telling a computer what to do is one thing. It’s simple, it’s systematic, and you can tell almost right away whether you gave it the right instructions.
Once we transition into leading teams though, we often get stuck on the same narrow view of problem solving. We think code is always the solution. And even when we figure out that enabling our team is the real solution, we approach it the way we would code, and that’s not really the best idea.
Here are a few aspects I’ve noticed people bring up when they talk about their struggles delegating work.
We’re afraid to get “rusty”.
I think one of the root causes why delegating is so hard for new managers and leaders is because the common reason we get assigned to the role is because of how good we are at the technical work that we do. We’re often the expert in the particular component or job the team works on and are thus assumed to be the best choice to lead the team. Unfortunately, that’s not always the case.
When you move into leadership, the expectations shift subtly towards how your team works as opposed to how you work. The skills required to meet both expectations are way different, and this is sadly often not established with new leaders. This ends up in us worrying that we become less qualified if we do less technical work when the truth is quite the opposite. The less technical work you have to do yourself, the more time you’ll have to work on the skills that allow you to improve your team.
Our organization encourages “hero” culture.
One of the most stressful parts of leading a team is when we’re hard-pressed with deadlines and our members are struggling to cope with the demands. When I was faced with this situation early on as a team leader, my first thought would often be, “if they can’t do it, I’ll do it myself”. Likewise, I thought it was an empathetic thing to think “hey, they’re having a hard time, let me take this off their hands”. In the end though, while both ideas were valid solutions to the immediate problem, it didn’t help me or my teammates in the long run.
There’s a pattern described in GitPrime’s “20 Patterns to Watch for in Engineering Teams ” called “Heroing”. This is evident in someone who often “helps” others by modifying code while, at the same time, decreasing review coverage. While the word “hero” typically represents something good, it’s not that great for the team as a whole. Reviews and mentorship are more important for long term sustainability. Trying to help others by covering for their work, on the other hand, defeats that goal.
I don’t want to delegate something I can’t do myself.
This is a particular case I heard from a transitioning team leader in my department. His dilemma was whether he should delegate the task to a new team member as a training opportunity, or should he learn it himself first so he would be able to provide guidance when needed. A very valid question and one that many ask – can I really delegate something I don’t know much about?
The simple answer is, yes. It’s important to remember that delegating does not mean just assigning tasks. It means placing an unsolved problem in front of a person and giving them the space to solve it. That also means accepting that someone else could be better equipped to solve the problem than you are, and that’s a great situation to be in.
I can’t tell how the work is going.
Another reason why delegating makes people feel uneasy is because the feedback loop is way longer compared to when you do things yourself. This is the reason some people micromanage. Micromanagement is just people trying to shorten the feedback loop on delegated work, often in unproductive ways (for instance, asking for a status report every 15 minutes).
It’s uncomfortable for sure not knowing exactly how things are going. But if you can’t trust your team to get things done, this might not be the right team for you in the first place. This isn’t to say you should be completely unmindful of the progress. Stay within reasonable bounds of the routines and mechanisms that are in place to check in on people (standup meetings, for example) and you should be fine.
How do I overcome this?
Without a doubt, delegation requires courage. Giving up control, in general, is a brave thing to do. Management these days should not be about control, but rather context. Instead of solving problems yourself, set the context and the space for your team to solve their own problems. It won’t feel natural but the conscious effort will be well worth it.
It’s also likewise important to note that delegating needs to be done in good moderation and there is, in fact, such a thing as “overdelegating”. Sometimes we can be overly self-conscious and end up behaving like we don’t actually care about the work at all. Or we forget about setting context.
When it comes to finding the balance, stretch your comfort zone just a little bit at a time. Also, keep in mind that productivity in software work can’t be completely tied to any tangible output. The key thing is the impact we make, and when you’re slowly able to make more impact with your team than you did on your own, you can be confident you’re in good shape.
This is the second of my series on middle management. When you’re managing managers and overseeing multiple teams, you’re likely to need to coach someone on delegation. I found this to be a common challenge new leaders in my team face, so I hope this helps you if you’re in the same position! Click here for the first article in this series, on managing upwards.
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.