Engineering Management: How To Delegate

I’m currently taking some time away from my job on parental leave, and it seemed like a good time to reflect on the lessons I’ve learned the last few years about engineering management. This is my fourth post, you can see a list of past posts on the series page

In my last post I discussed the importance of delegating work to your team and giving them room to do important work. Delegation like this is crucial for effective managers, it’s the only way that you’ll ever have time to grow and it’s the only way that you can help your team grow. But it isn’t always easy, and effective delegation certainly isn’t as simple as giving somebody a task and walking away. I’ve picked up a few principles over time on how to delegate well, as well as a few practices that have been helpful for me in finding the right mix of delegation. The principles that have been most helpful for me when delegating work have been to “trust by default”, thinking about people’s ability in terms of “task relevant maturity”, “not being essential”, and “giving objectives and context rather than just tasks”.

The most important step to beginning delegation is to trust by default rather than making people prove themselves before giving them opportunities. Trusting in this context doesn’t mean blindly handing people arbitrarty work and expecting it to go well. But it means being willing to give people reasonable stretch opportunities and then properly supporting them through them, and doing that starting early on in your management relationship with them. Ideally trust will build as you work with a teammate, but if you default to a “prove it” attitude it can be tough for teammates to ever gain your trust. If this proves difficult for you it may point to a higher level problem like you being too attached to doing work yourself or not having the right people on your team for the work you’re trying to accomplish. Don’t jump to that last conclusion though – it’s important to look in the mirror first.

When evaluating people’s ability to handle a task you’re considering delegating to them, you shouldn’t be looking at their title or general track record, but instead focusing on what Andy Grove calls their task relevant maturity – how experienced they are at the specific task under discussion. It’s possible to give brand new employees tasks that are easily within their wheelhouse and very senior team members tasks that are outside of anything they’ve done before. If you base your support and expectations solely on how senior somebody is or how successfully they’ve handled generic delegated work in the past, you’re likely to mishandle the delegation.

Adjusting well based on task relevant maturity means giving teammates who have less experience of success with a task more support and monitoring their progress more frequently. This doesn’t mean micro-managing, but being a resource to the employee, checking in on the task regularly during 1-1s and reviewing any incremental steps in the process for signs that you’ve become misaligned on the objective or that things are off track. The key is that you’re a support resource and a quality checker, not laying down specific restrictions on how the task is done. For teammates with progressively more experience with the task you can reduce check-ins and explicit offers of support to match their comfort level, though you should never completely ignore projects or lose track of what is going on with anything important.

A 3rd principle of delegation is more a warning post that you’re not delegating enough. I never want to be essential for any task as a manager. If I get hit by a bus or leave the company, my ideal is that everything in the teams reporting to me will hum along perfectly for a long time, with my absence being felt only in lost potential in how I could have helped people grow, or solved higher level problems in the company. That means that if I see areas where I am essential for success, rather than allowing that to inflate my self importance I should view it as a sign that I need to grow somebody on my team into that role. If there are people who could be doing it but I’m not giving them the opportunity, it’s time to delegate. If there’s nobody who can do the work, then it’s a gap on the team that needs to be filled by training or hiring.

Finally, it’s important to delegate at the right level. Delegating completely defined tasks with a prescribed solution is just asynchronous micro-managing. Instead you should delegate objectives, and give people the context they need to make good decisions. For technical work this can come through in how a Jira ticket or Github issue is written. Does it describe a technical change that needs to be made without explaining why? Or does it describe a user problem, with context around what we know about past attempts to solve it or any relevant constraints¹? When having a tech lead replace them in an interview, a manager could choose to give them the list of questions they have been asking and ask the tech lead to read from the sheet, or they could explain what they’re looking for in the position, any constraints around what will be accepted by the wider organization, and then have a discussion around the interview questions that the tech lead might want to use. The second way will engage the tech lead’s brain, give them ownership and maybe help the manager learn something.

Practical Activities To Delegate Better

It’s good to understand the principles and theory behind delegation, but what if you’re not getting it right in practice? When I discovered last year that I was not delegating nearly enough, there were 2 activities I went through that helped me do a better job with this: a weekly review and being extra explicit about ownership

After getting feedback from multiple folks that I was trying to do too much work myself, my first step to getting better was a simple 30 minute weekly review where I went through all of my activities from the week and listed out anything I’d spent time on that wasn’t part of what I considered my “core responsibilities”. From that first list I then considered 2 questions: who else could be doing this work, and are there good reasons why I’m doing it instead? If you’ve never thought this through before you may find some good low hanging fruit where you’re doing work that somebody else on your team would benefit from doing without a compelling reason. It’s perfectly fine if many of the things on this list are more complicated though. There may not be an obvious person for every piece of work, or there may be good reasons why you’re picking it up. In those cases the goal of the exercise is to bring clarity and give you time to think about what would need to happen to move these tasks to a teammate who would benefit from the work and/or be a more appropriate fit. Maybe you need to invest in coaching a teammate, have a difficult conversation with a peer about ownership, or just need to document the work so that other people can do it.

I started this exercise focused on “non-core” work, but scaling yourself as an EM means constantly giving up work and letting others grow into it. So feel free to consider all of your responsibilities and see if there’s an opportunity for others to grow into some of those while you grow into broader and new opportunities or just get more time back to invest in people.

Another thing I found helpful when starting to document more was being explicit about ownership. If you have been handling a type of task yourself and want others to step into it, there are benefits to creating a clearly defined role or set of work that you can give somebody. Without this it can be easy for some piece of the work to fall back to you or be missed. For instance if you’ve been doing most of the project management on tech projects and want engineers to step into that, it might be helpful to create and document a “project tech lead” position that you assign for each project. You can then be explicit that the project tech lead is responsible for keeping the project on schedule and identifying or escalating threats to the project plan along with any other duties that make sense. You can also be explicit about what ways you expect to be supporting a project tech lead and any responsibilities that still fall on you as an EM.

Why Delegate?

Delegating work well is an incredibly rewarding activity. You give others opportunities to grow. You can reduce your own stress and increase your capacity. You’ll learn from seeing other people take different approaches to work you have done in the past. Over time this will help create a team that is excited about their work since they’re empowered to do meaningful work and continue growing over time, and it will allow you to continue tackling new challenges as well. So take some time today to figure out where you can find new places to share your opportunities and create new ones.

More Engineering Management Posts

This is part of a series of posts on Engineering Management. You can see the whole series here.