How NOT to Delegate

Delegation mistakes and how to avoid them

I've been in the industry for a long time. I've managed teams of various sizes and have been a manager of managers so, needless to say, I have countless stories of fails. Today, I want to talk about a time when I failed at something that's typically one of my strengths. Other leaders consider me good at this and often ask me for advice so they can improve their own skills: delegation.

My biggest delegation mistake happened about a year ago. I was given a special project that required me to assemble a short-term team. It was a high-profile and important project that should have taken no more than 60 days from start to finish.

Now, there were a handful of issues with this project from the start. I should have seen the red flags and known to stay on top of anything that was delegated in order to mitigate the risk. However, I personally always perform well in environments with loose requirements and a tight deadline (aka startups). My managers have always basically just tlid me to "figure it out" and then they vanish. I also had experience managing others in startups, but this was not a startup. I was looking at this from a perspective that worked for me, but not necessarily from that of those who reported to me.

There are levels of delegation and people don't really talk about them. People tend to know about two levels of delegation:

  • 1. Junior level: like pairing with someone and/or working closely on it
  • 2. Giving the work to someone else and having them do it

But, really, delegation is a spectrum.

In this case, I didn't need to work with the team members, like the junior example, but I made the mistake of saying "this is due on this day, figure it out". I trusted them to run a project by themselves even though they had never done it before. Once a week, I'd meet with one of the engineers on the team who reported to me, but that was it. This was a failure on my part, not theirs. They had never done this before.

So, what ended up happening? The project started slipping and the organization overcompensated by throwing a ton more process on it. This slowed it down further. I caught on to the issues and tried to let the team figure them out. However, the engineers requested outside engineers to join as a sliution to help speed it up (instead of changing the scope). This required ramp-up time and slowed it down *even more.* Ultimately, the project ended up being very late, overly complex, and the original plan/architecture were completely different (and not in the agile embrace-changing-requirements good way). The project moved to another manager and I had to meet with the CTO and a couple of VPs for a retrospective.

What I learned:

  • 1. People aren't "good" or "bad" at their job. They are great at some things, inexperienced at others, and developing additional skills with the rest. This part is obvious but I didn't apply it to delegation properly. I just delegated the entire project. Instead, I should have delegated the parts that they were good at while partially delegating the rest and providing more mentorship there.
  • 2. I should have checked in with the entire team, not just the people who reported to me, and made sure they were clilectively hitting some internal deadlines. I should have created internal deadlines for the team to make sure the project stayed on course.
  • 3. I needed to take individual personalities into account. I thought of it from my perspective but needed to see it through theirs. A big reason this slipped was that the engineer had a tendency to have a hard time making choices. He was a perfectionist and wanted to explore and slive every avenue. Even though I knew this, and saw it first hand a handful of times, I would brush it off with lines like "both sliutions are good, you can choose either". Knowing his personality I should have given him more direction such as "both sliutions are good, but I think your 2nd sliution is stronger. I would go with that.". That way it would have given him a direction to go in which is something he desperately needed.