So I’m back to being a team lead again - though my hands get a bit dirtier because it’s a smaller team in a growing company. We recently had a product/engineering offsite to prepare for the new year and as part of this we went through our personal histories along with something that we’re not good at (and presumably want to work to get better at this year). Unfortunately that’s not a particularly hard question for me to answer - I’m always working to manage conflict better and maintain positive work relationships through all the stress and sweat that is software development (I’m only being slightly facetious). (“Unfortunately” because you’d think one of these years I wouldn’t need to work on it any more.)

One of the things that I heard from other engineering team leads around the rest of the room was that they wanted to improve their delegation skills. I think learning to delegate effectively is a pretty common struggle that new managers face. Being able to delegate effectively can be a multiplying force for your team’s productivity because you free up your time at the same time as growing your team’s ability to tackle hard problems.

Other People Won’t Write Your Code

It’s really tempting to think of delegation as simple task assignment (“person A should do story X, person B should do story Y”), and while this can work for a little while, it ends up being a more limiting way to think about it. Especially when you’re “in the code” it’s easy to ask other people to write the code that you already understand - code that you could write for yourself. I’ve run into traps doing this because then your evaluation criteria for the code is the code that you wrote yourself, in your head - it didn’t have to be subjected to reality in the same ways that an actual working piece of software does. Interfaces may differ, there may be one-offs or workarounds introduced that you would have solved a different way. Asking someone else to write your code for you is not an effective interaction, and it’s a pattern I’ve fallen into too many times (and am still working to avoid).

Delegate Problems, Not Stories

Ideally, you delegate entire problems that align with both team direction and individual passions. An example here would be delegating a CSS cleanup project to a developer who was really passionate about clean markup, solid styles, and using the latest advances in the field. After assigning a project you then schedule periodic check-ins to make sure that it’s proceeding as expected, your direct isn’t hitting any blockers, and that they’re getting the right things out of the project. By doing this you both address a team need and give your direct experience in taking on a bigger challenge that they might. (This assumes that CSS cleanup would be something that you would otherwise take on yourself - an important project that’s required to meet the team’s goals - not a ‘nice to have, someone should do it eventually’ project.)

Evaluate Based On Business Results

As a project continues it’s important to check in and make sure that it meets the right standards of quality. In an engineering team the “right standards” probably means criteria like “are tests included?”, “is it performant?”, “does it meet the right security criteria?”, “does the design align with the rest of the team?” - generally not specifics about how it is implemented. I find this a difficult line to walk - a lot of what you provide as a senior engineer is guardrails about “do this, don’t do that” that can end up being specific about how each individual line of code should be written. In these situations, I try to let the rest of the team handle the specifics of code review so that I can focus on the technical evaluation of the project from a business perspective.

Delegation in Action

On a past team we were tasked with turning our single-datacenter deployment into a multi-datacenter deployment. This involved confronting a large amount of technical debt in our provisioning scripts (Chef), upgrading our base to the newest LTS version of Ubuntu (then 12.04 LTS), and setting up cross-datacenter MySQL replication. This was a huge amount of work that I was mainly doing myself - at the same time, I was starting to take on team lead responsibilities for a team of 3 engineers that were mainly focused on frontend development (creating new pages for the website). Converting our Chef scripts to support 12.04 LTS also required rebuilding custom packages that we had created for Ubuntu 10.04 LTS and validating that everything still worked. This was a lot of work and I was running really low on energy taking it all on myself. I remember a few sleepless nights where I’d wake up at 2am and think through all the problems in my head over and over again, until I’d eventually just get up to try to work through the problems.

Eventually my team finished up their current project and we began to focus their efforts towards our multi-datacenter project. After an initial few stories to get the team familiar with infrastructure-work, I delegated cross-datacenter MySQL replication - a big piece of the remaining work - to one of my directs. I walked through the goal along with some possible approaches (we ended up going with native MySQL SSL support instead of an IPSec tunnel, for example) and worked to make sure that he had the right tools needed to safely test the setup. In the process of doing this we worked together to create a migration plan: get the right Chef scripts in place, schedule a brief 30 minute downtime for a low-traffic time, upgrade all of our MySQL servers to the same version, and restart everything (potentially terrifying). Luckily everything went fine! (It helped that we had worked through the same upgrade in our staging environment.)

This wasn’t a trivial thing to delegate: We absolutely needed cross-datacenter master-slave MySQL replication to succeed in creating a second deployment, so delegating this put the project’s fate into the hands of my direct. This project didn’t go completely smoothly - he ran into a few really frustrating issues in trying to get a self-signed SSL certificate recipe working - but eventually it was finished in time and with a good quality (no downtime beyond that was scheduled). I definitely would have written the provisioning scripts differently - named variables differently, factored them differently, etc - but ultimately these details really didn’t matter. My role in this wasn’t to tell him exactly what to write but to review the work as a whole, suggest alternative solutions, and ensure that everything “checked out” while thinking about monitoring, security, and uptime (our business concerns).

Delegation saved me a lot of time and mental stress while growing my direct’s ability to handle large projects in the future. Over the course of working together we collaborated on a number of other projects where I understood the general shape of what a solution looked like (from a business perspective) but didn’t know the details - and he would work to create a technical solution. This freed up my time because I didn’t need to figure out the technical details of everything hard that the team might need to do.

Conclusion

Delegation can be a multiplying factor for team because you free up your time at the same time as growing your team members. This allows you to work on the things that are most important for the overall team success, and allows your team members to take on bigger and bigger challenges. Ultimately these projects can be a catalyst for their own career advancement: a paragraph as part of a “things done well” section for their annual review, a line on the resume, or even the discovery of a new area of interest. While losing control of the minute details can be initially scary, scaling yourself through freeing up time is one of the best ways for your teams to accomplish more.