Tools for effective delegation in engineering management

There comes a point in every manager’s life when we need to hand over a responsibility that is near and dear to our hearts.

Maybe it’s a piece of code that we’ve shepherded for many years, or maybe it’s a program or project that has special importance.  And, while many times we will have confidence in the person to whom we are delegating, it may still feel uncomfortable letting go. Delegating has been a frequent topic among my clients of late, so I thought I’d share some of the lessons I’ve learned over the years.

Know what to delegate

The first hurdle of delegation is knowing what to delegate. One of the first models I used to decipher whether I should delegate something is the Eisenhower matrix. The Eisenhower matrix is a 2×2 where one axis is Important/Less Important and the other is Urgent/Less Urgent. The idea is that tasks that fall in the Important and Urgent are ones that should be done immediately, tasks in the Important and Less Urgent quadrant should be scheduled for later, tasks in the Less Important and Less Urgent quadrant should be deleted, and tasks in the Less Important and Urgent quadrant should be delegated. In this model, an example of an Important and Urgent task would be prepping a presentation for your manager. And something that is Less Important and Urgent would be an initial phone screen for a hiring candidate.

While the Eisenhower matrix was useful for helping me delegate certain tasks, I found that my job did not always break down so conveniently into a 2×2 matrix. Particularly, when I became a manager of managers, I found that there were many business-critical tasks and initiatives that were both important and urgent that I had to delegate because I had neither the time nor the in-depth expertise to successfully execute them. And so, I had to find another way of thinking about delegation. A useful tool was this simple question: What are the things that my title or position uniquely enable me to do? 

So, for example, as a Director in charge of multiple teams, something that my title uniquely positioned me to do was make decisions on allocating new headcount budgets across each of my teams because I sat at a level where I could uniquely understand the tradeoffs. Something that I was not uniquely positioned to do was actively manage a development team or squad. And while I did do that as a manager due to not having enough managers to go around, I knew that I needed to hire someone to delegate the responsibility to.

I’ll admit that it took me a while to be comfortable with this idea of delegation. I view myself as the servant leader type and for a long time, I clung to the notion that no job was beneath me. I wanted to model that I was always happy to roll up my sleeves and do the dirty, menial work. And while I never completely gave up that concept, I also needed to recognize that I was in charge of dozens of careers and millions in salary, and maybe thinking about the intricacies of our homegrown ORM (object-relational mapping) wasn’t the most responsible way to be spending my time.

Finally, there was one other input I fed into my delegation equation, and that was growth and development opportunities for my reports. There were times when a meeting or a project was definitely unique to my position, but I opted to delegate it to a report as a growth opportunity. I will admit that doing this at times did spark minor doubts surrounding my self-worth as an employee (‘Am I delegating myself out of a job?’), but I learned to get over it.

Desired outcomes and constraints

Having decided the ‘what’ of delegation, the next step is to describe the task to be delegated. I generally try to distill this into two main concerns: desired outcomes and constraints. If you squint, this looks very similar to having a good practice around goal-setting. So you can start with picking your favorite framework. Whether that be SMART goals, Objectives and Key Results, Big Hairy Audacious Goals, or something else, the important part of this step is to make the implicit explicit. When we hand things off, there are usually a set of concerns that we communicate explicitly. But as humans, the things that stoke our anxieties and erode our confidence in others are often the tacit concerns that we’ve failed to communicate but somehow expect people to ‘just know’.

The passing grade version of this would be something like, ‘Here’s the project I need you to lead. The final solution needs to do X, Y, and Z and I need it done by the end of the quarter.’ This is a pretty standard statement of a desired outcome with a time constraint. And for well-understood pieces of work, this might do just fine. But as you start working at higher levels, the types of projects you delegate will be not well understood. In these cases, I found that contextualizing helps a lot. For example, ‘One of the company’s goals this year is to focus on our mobile experience as part of our strategy to increase customer engagement. In order to help us measure that, we need to be able to track users across devices. I need you to lead this project. It has to be done by the end of the quarter because we’re planning a big marketing campaign and your main stakeholder is the business analytics team.’

Other than being a lot more words, this version frames the project within the goals of the business, conveys the reasons for urgency, and connects the team lead directly to their stakeholder so that you don’t have to be the messenger in the middle.

Once you delegate, delegate cleanly

Now that desired outcomes and constraints have been communicated, the next step is to delegate cleanly. For me, this means extricating myself from the communication loops that would allow me to gain insight into the inner workings of the project. This includes bowing out from team meetings, silencing Slack channel alerts,  and putting filters on my emails. It also means referring inquiries I get about the project to the person I’ve delegated to.

The goal here is to create a sphere of influence for the person who will lead this effort, and one that minimizes overlap with your own. The more clearly you can define and separate the role of your team lead from your own, the less confusion there will be for everyone involved. This takes discipline; especially if you are delegating something that you were the subject matter expert on because often it will be easier for you to answer a question than to remember to direct them to the new lead.

Some of these moves might sound counterintuitive, but remember you delegated this task for a reason, and continuing to be intimately involved in the project after delegating it neither serves your interests nor those of the person you’ve delegated to.

If you ain’t outta control, you ain’t in control

At this point, I have taken my hands off the controls, but I still bear responsibility for getting it across the finish line. That’s awkward. But as Lil Bow Wow says in Fast and Furious: Tokyo Drift, ‘If you ain’t outta control, you ain’t in control.’ And while I may be out of the day-to-day, I still have some tools to help guide things along the way.

The first step is to define an interface between you and your team lead to communicate status. I personally like to use a templated written report on a weekly cadence, but you can also use your 1:1s or some other form of communication. The important thing is to make clear what kind of data you’re looking for and on what cadence. I find the cadence to be of particular importance because it serves as my sampling rate. Every time I get an update, there is an opening for feedback, and if I feel a project slipping into jeopardy, I’ll increase the sampling rate.

Now that we have re-established insight into the project, it’s not uncommon to revisit and redefine our desired outcomes and constraints. As we all know, changing the scope of a project bears with it some cost, but it is sometimes necessary as we learn new information about the problem space. Along the way, we might find that we have additional stakeholders or that the problem we’re trying to solve is more complex than originally thought and we need to add a few new milestones into the project.

The second tool I like to employ is effectively labeling and communicating my feelings. As you watch your team lead operate, you’re going to have feelings about the paths they pursue and the decisions they make. Your hair may stand on end. Your brow may furrow. Your heart may quicken. Instead of repressing those sensations and hoping for the best, I’ve found that I’m often better served by finding constructive ways of expressing myself. Remember that you occupy the seat of power and by opening up, you’re giving your lead a way to manage up to you. You could approach conversations with, ‘It makes me nervous that half your team is going on vacation at the same time. How are you feeling about it?’ ‘I’m afraid we’re building the wrong solution. What’s giving you confidence that this is the right path?’ These kinds of statements are openings for conversations that allow you and your team lead to bring your respective contexts into alignment. And the closer you can align your contexts together, the higher the likelihood of success.

With the peaks come the valleys

When delegation works well, it’s a phenomenal feeling. The work gets done, the business benefits, and you didn’t have to do much of anything! But we should acknowledge that not every delegated task will end successfully, and when failure happens, this is when we need to really be mindful of our lizard brains. Failure has a tendency to amplify othering behaviors; there is an instinctual urge to draw a distinction between our self-image as winners with the losers who have failed, and one data point suddenly becomes representative of the entirety of that employee’s work product.

As leaders, it’s our job to help folks pick up the pieces. In my experience, most folks already feel bad when they fail, and treating them as an outcast is not productive. It’s easy to have someone’s back when they are doing a fantastic job, but the true test of a manager’s support is finding ways to express confidence and trust through the peaks and the valleys.

Conclusion

Every leader reaches a point in their career where their old toolset is no longer sufficient to meet the needs of their new role. For me, my default tool was being able to out-horsepower any problem thrown my way. That tool worked brilliantly until it didn’t. Waking up one day on the wrong side of burnout, I realized that even if I doubled my work capacity, I’d still be underwater.

Learning how to delegate at that time was scary, but it proved to be so worthwhile. Handing off work not only provided growth opportunities for my team, but also allowed me the time and headspace to develop the skills I needed to be effective in my new role. From mapping out longer-term goals, to providing more support to my manager and peers, learning to delegate was a step function in my ability to lead. And with some of these tools, I hope it can be the same for you.