Learning to Delegate Responsibly

Struggle, learn, practice, repeat

Learning to delegate well is hard. Delegate too little and you burn out while work stalls and your people stagnate. The opposite is no good, either. Take your hands off the wheel and you’ll spin out. It’s not really a spectrum, though- too little, too much, just right. Delegating well means delegating responsibly. In other words, it’s not about how much you delegate but how you delegate. There are specific things you can do to make delegation more effective which we’ll talk about here. That’s not enough, though. You also need practice and, at least in my case, a lack of alternatives in order to get good at it.

If you’re not feeling a big read today, go ahead and skip down to Tips and Tricks. If you would like to join me in my delegation journey, though, then read on.  I have broken it down into three parts: I Should Have Delegated, I Need to Delegate Responsibly, and No, Seriously, I Need to Delegate.

Part 1: I Should Have Delegated

My first experience with management was rough. I went directly from a senior IC role to leading my team of nine. Our systems were unstable and each team member was budgeted toward one or more projects where they were essentially by themself. It went about as well as you’d imagine: disastrously.

One¹ of my biggest learnings from this time pertained to my near complete failure to delegate and how that impacted our work, my team, and myself. I shielded my team from the horrors of supporting our always-on-fire systems and pushing releases through our bloated and draconian approval process by doing all these things myself. Project siloing on the team was astronomically high; I wanted to learn what each person supported but also felt that neither I nor they had time to ramp anyone else up on my own silos. 

Our project roadmap stalled out, work silos remained in place, and I actually managed to work myself sick. Less than a year later I left the company and swore I would never return to management.

Part 2: I Need to Delegate Well

Act 1: A Return to Management

Fast forward one more year. I was working at a truly wonderful company. I had been in an IC role that I enjoyed and had vehemently told my leadership that I wasn’t interested in exploring a management role again. But the thought kept niggling. I looked around and had deep thoughts about what I thought worked and didn’t work.  I got an awesome college intern who I enjoyed clumsily guiding through the summer.

Soon enough it was time for my manager to take parental leave. I was asked to hold down the fort in his absence - just six weeks since he was taking his leave in two parts.

I loved it. I felt challenged in ways I hadn’t before but with way more support. I was exposed to bigger problems and more people. It also didn’t hurt that our systems weren’t on fire, our engineers weren’t over subscribed, and everyone was fairly independent already.

When our team lead returned I was asked if I wanted to take on the job permanently. He was ready for a new role with a different set of challenges. It was agreed that I would take on leadership of the team permanently once he took the second part of his leave a few months later.

Act 2: Taking My Hands Off the Wheel

This second management experience was also hard but, as I said, I had way more support and better circumstances overall. I had access to all kinds of excellent guidance, not just from my own very experienced and thoughtful manager but from a large number of other managers as well as formal trainings. I was taught how to do good things like encourage psychological safety and deliver critical feedback. I didn’t get these things exactly right the first time but it didn’t take a whole lot of practice to get to a good starting point.

Delegation was something else entirely, though.

I was determined to actually do it this time around but didn’t really know how. My first attempt looked like this:

• Assign one of the big projects to my two software engineers to work on together. Put them in a corner with our product manager and check in during standup to see how things are going but otherwise give them full autonomy.

• Check in even more lightly with our data engineers who worked on our big value add data pipelines which I didn’t really understand.

• Keep the other project that I was already invested in to myself. Fiddle with it constantly and barely come up for air.

Perhaps you already know how this went. If not, my two software engineers got stuck and very frustrated while my own project stalled out as I chased my own tail. I am still not 100% sure how things netted out with the data pipelines.

I had delegated but not well.  I hadn’t properly considered each engineer’s strengths and immediate growth opportunities when assigning their project. I also neglected to stay adequately plugged in to everyone’s work. My job should have been to keep them on the productive path while spotting and removing potential setbacks. In other words I was still very much in hold-down-the-fort mode, not lead mode.

Fortunately it wasn’t too late. I took these learnings and, in close cooperation with my product manager, cut my own project from the roadmap. I joined my two software engineers in their project while making a greater effort to plug into what our data engineers were up to. 

Act 3: Practice, practice, practice

Naturally we reorged soon after. I had done well enough in my role to be given a larger team of five engineers.  This came with its own challenges and learnings, but as far as delegation went I was mostly in practice mode. My delegation decision making looked like this:

Here is a task - does it need doing? Is it specific to my role? If not, who should I assign this to? Do they have capacity? Do they have the requisite skills? Will it present a reasonable growth opportunity? What kind of oversight will I need to provide them myself? How will I know if the task is going well? How will I catch disasters early on? Is there a more senior engineer I could pair them with?

And on and on. Practice, practice, practice.

Part 3, Act 1: No Seriously, I Need to Delegate

Eventually it was time for me to take my own parental leave. I did so in one large piece. By the time I returned we had reorged yet again. My new team was the sewn together pieces of my old team plus one other. Projects were in swing and had decent momentum but the team had suffered some natural pains associated with combining two separate cultures.

At this time my son was not yet sleeping through the night. He would sleep for maybe an hour or so at a time with much soothing in between. I was getting something like 4-5 fragmented hours of sleep each night. I was also pumping at work which looked like 2-3 sessions spaced over the course of the day. I got in a little before 9 and left at 5 so that I could get home by 6. Evenings, nights and weekends were entirely spoken for by family obligations.

Looking back, I wouldn’t trade it for the world. It did mean, though, that my time was truly limited in a way that it never was before. I couldn’t flex into my evening or weekend hours to do just a little more. 9-5 was what I had to give.

So I took out my tube of industrial strength delegation and slathered it all over the roadmap.

Every time a new task came in I determined whether it was specific to my role. If so, I kept it. If not, I delegated the heck out of it. It didn’t matter how interesting I found it or how much I would have liked to do it myself - it was not specific to my role and so it went to another member of my team. I was finally ready to give up my legos because there was simply no alternative.

Getting the team to communicate effectively and not talk past each other during disagreements? Evaluating each person’s strengths and growth areas? Yes, these things were definitely specific to my role. Designing and launching a new web service? Putting together a data migration plan? These things were not specific to my role - I had a couple awesome senior engineers on my team who could lead these efforts and so they did².

Part N: Learn to Delegate Again, and Again, and Again

I lied. There aren’t just three parts to my little delegation mini-opera.  My next career step was to take on a manager of managers role.  Once more it felt as if I were learning to delegate all over again.  Sometimes this was because I had to delegate a task that I myself didn’t know how to do. Most of the time, though, it was the stuff that I did well myself but had never taught to another. How could I teach a new manager how to have effective 1:1’s? Or partner effectively with their product manager? Or hold their people accountable? More to the point, how could I trust someone to lead an entire team?

I did learn, though. And then I took on a different role and, again, I struggled and learned.

Struggle, learn, practice, repeat.

Tips and Tricks

So “ends” my delegation story. I did promise concrete tips and strategies for delegating well, so let’s get going. First ask yourself:

What should I delegate?

Don’t delegate things that are specific to your role. Obvious things that fall into this bucket for engineering managers include 1:1’s, delivering feedback, and creating the technical roadmap for your team³.

Just about everything else is fair game. Whether or not you delegate these things will depend mostly on who you have on your team and what capacity looks like. This brings us to:

Who should I delegate this thing to?

It depends. Does the thing need to be done ASAP with little to no room for error? If so, pick someone who has done this kind of thing in the past, preferably more than once.

If the timeline is less critical, now is a good time to think about who would grow from taking on a task like this.  This takes some thought. Assign tasks that make your engineer stretch but are achievable for them, not tasks that are completely out of their reach based on their current experience. You would not, for example, assign a DB migration to a junior engineer who has only done front end development just because you want them to grow their SQL skills. You would, however, assign this larger project to a senior engineer and then have your junior engineer pick up the smaller JIRA tickets that come out of it.  This in turn brings us to:

How do I set my delegate up for success? 

In order to make sure the task is completed well you will need to determine what level of supervision the delegate will require. If this is a growth scenario (an engineer taking on a task that is notably bigger or different from what they’ve done before), you will need to provide more supervision. Sometimes you supply all of that supervision yourself, sometimes you enlist the aid of a senior member on your team to provide more hands-on guidance.

Either way, stay keyed into decision making. For smaller tasks this probably looks like discussions during standup and code reviews. If the person is senior enough and the task large enough, though, then they will end up making real decisions. It is your responsibility to go over their decision making at critical points, kicking the tires along the way. Push them to flesh out details, summarize alternatives, and solicit input from peers. Read everything closely - it is tempting to assume that all is well but this is where you (and they) will get tripped up. Get into the details. They are responsible for driving these decisions but you are accountable for ensuring that they are good ones.

Finally, all delegated tasks, small and large, are vulnerable to getting stuck. Think and listen critically so that you can predict obstacles and then clear the path. Getting stuck still happens for reasons that you do not foresee, though. Check in regularly to detect this stuck state and then, when it happens, get them unstuck.

1. There are many, many more but this post is about delegation.

2. My son finally slept through the night several months later after 10 brutal nights of full on cry-it-out. One week after that some set of neurons came out of Low Battery Mode and I realized that there was a major flaw in one of the projects I had delegated. I dove back in and, with much discomfort, we pivoted. I had learned once again that I needed to stay deeply plugged in. I also appreciated just how badly moderate but chronic sleep deprivation can mess up your brain.

3. This last one can and should be broken up such that you give healthy size chunks to senior engineers who are ready to take on more. The entire team should participate in roadmap and vision but you, as the team lead, ultimately own them as a whole.