How do you delegate to a group of people?

21 June 2019 / Leadership

I’m the Technical Director of Customer Products at the Financial Times. In Customer Products, we run FT.com and the FT apps (as well as some other products, like Alphaville), and we have about 55 engineers.

I’ve got a team of five excellent principal engineers reporting to me, and my goal is for them to be running Customer Products without me. Ultimately, I’d like each of them to be a good candidate to take over my job.

However, one thing we’ve struggled with as a team is how they can figure out what they should be working on, and particularly, how best for me to delegate to them as a team rather than individually. This is about some changes we made to help with that.

What kind of things am I delegating?

The things I need to delegate are cross-cutting, rather than domain-specific, so any one of them could pick them up. Examples of the kind of things that come in are: coordinate an evaluation of our testing strategy, lead on recruitment for a senior engineer role, work out what team should take on a piece of work and help define it, give an answer to this technical question from another team, and many others.

Ideally I want to be able to delegate anything that I am asked to do, as this is the best way for them to be running the group, and to get insight and practice at doing my job.

How I initially delegated work

To start with, I delegated in one of three ways:

1. We have a weekly meeting. In that meeting I might explain the item and someone would volunteer to pick it up.
2. I would send all of them a message (Slack/email) and say “Can someone pick this up” and someone would.
3. Occasionally – usually when things are very busy – I picked one of them myself and asked them individually to do something.

This didn’t feel right. It got things done, but it meant that I was still in control of the flow of tasks and often even who did them.

I felt that there must be a better way to do this so that the principals know the problems we have that I need help with (and also know about the problems I don’t know about), without me doling them out.

I asked for advice

I have read a lot about delegation and had coaching, but that has tended to focus on how to delegate one piece of work to one person. I couldn’t figure out how best to delegate to a whole team. So I reached out to my network and asked them for advice and to hear some of their experiences around what had worked and what hadn’t.

I particularly asked for people’s experience around the practical aspects – types of/frequency of meetings, how/when people used email groups, etc.

I got lots of extremely useful suggestions from people. Here are some of the suggestions we had, what we tried and how it’s going for our team.

Some people suggested a more Kanban approach

Some people suggested using an approach as I would in a delivery team. For example, weekly/fortnightly kick-offs, Kanban board, stand-ups, etc.

I was initially resistant to this. After all, we are not a delivery team, and part of the job is juggling many things at once; most of the things we do can’t be worked on until they are done. They are often ‘prepare for something in the future then wait for that thing to happen then do something else’, or ‘ask some people to do some work and keep an eye on it’.

However, we decided to try having a physical wall to see if that helped. Rather than a normal Kanban wall, we have columns for each of our names, and rows for ‘on their radar’, ‘working on’ and ‘done’. Next to that we have three other areas for cards: ‘Upcoming considerations’, ‘To pick up’ and ‘Not looking at’.

(c) Luke Kavanagh

We have a weekly stand-up, on Fridays, which usually lasts half an hour. We initially tried it as an experiment, and quickly found that it was really helpful. I’ve also found the wall extremely useful, despite my initial reservations. It works really well to be able to see that something is being worked on and who is working on it.

We also added retrospectives, once every six weeks, in which we reflect on just our processes within the team of principal engineers and make improvements.

I wasn’t sharing all the context

Other people usefully pointed out that because of my role, I have a huge amount of context not available to my team.

For example, Nik Silver gave me this insight: “By virtue of you being in the position you are you attend a wide variety of meetings, you meet and listen to all manner of stakeholders, you weigh up and synthesise what you hear and you make judgements accordingly. None of your team are in all the same meetings you are, listening to those stakeholders, and therefore they can’t reasonably create the same backlog of things to do.”

As well as being in those meetings, I was also being sent emails on a wide range of topics and copied in on lots of email threads where they wanted engineering input from Customer Products.

Why I didn’t share context

In fact, not sharing context was a deliberate decision on my part. I get a lot of emails and go to a lot of meetings. A lot of this is requests to do things that I don’t think are a priority at the moment, so it didn’t seem to make sense to me to pass all that on.

I also didn’t want to drown my team in emails, because it’s hard to get stuff done when you are getting lots and lots of emails.

However, the downside of not passing this on was that I was denying them the opportunity to get all the context I had and make their own decisions about what was a priority; and it also meant that I became a blocker for information to pass through. If someone went directly to them about the same issue, they wouldn’t even know that I’d stopped it earlier.

Essentially I thought I was protecting them and helping them do their jobs, but in fact I was actually blocking the information flow and making it harder for them to do their jobs.

I asked them if they wanted the context

I explained the situation to the team and some of the recommendations, and they said that they would prefer to get lots of emails and have the context, rather than have me policing it.

So we made some immediate changes:

• We set up a mailing list for the principal engineers and started publicising that as who to email, rather than emailing me only.
• I started sending a lot more emails to that email address. Sometimes this would be forwarding an email I’ve received, adding “FYI”, so they have the context. If I had a bit more info I might add it in the email.
• I look for opportunities for principals to go to meetings as my delegate. After the meeting they share back notes to the rest of the team, including me.
• If I feel I need to be in a meeting where useful context will be shared but it’s possible to add someone, I ask one of them to accompany me, with the purpose of taking notes and sharing context with the rest of the principal engineers and also getting in practice at those sorts of meetings, and meeting the stakeholders.
• Where it hasn’t worked for someone to come to the meeting with me (perhaps a 1:1), I write up notes and email them to the group, or talk through them at our weekly meeting.
• We already had a short weekly meeting, but we extended it to 50 minutes. We now mark items on the agenda as ‘Proposal’ (ideally will have been circulated in advance), ‘Discussion’, or ‘Info’.

The team solve problems before I’ve even heard about them

From my perspective a lot of these changes are going really well. Quite often, someone will email or mention at stand-up a problem that they have picked up and solved before I’ve even heard that it exists.

It also seems to be helping balance work a bit better – things sometimes get passed to others at stand-up if someone has too much on their plate.

People email our group email address rather than me or individuals in the team much more often, which means we all have a lot more context, and we can respond to things much faster as questions don’t get lost in someone’s inbox.

Making sure we are working on the right stuff

These changes meant that we made huge improvements in getting things done, but we started to wonder whether we were always thinking about whether the things we were doing more efficiently were the right things. We felt that we might be being too reactive, and not necessarily always working on the highest priority or most strategic pieces of work.

Colour-coding types of work

We have taken two approaches to this. Firstly, we decided to be more conscious of the type of things we are working on. We think there are three categories of work we should be doing:

1. Team health e.g. making sure line management is working, improving the dev huddle, helping to create opportunities for engineers on our team to grow their careers, helping with recruitment, etc.
2. Technical oversight, e.g. using our expertise as senior technologists to support team members with technical issues, helping with decisions that might affect the architecture of a number of teams, overseeing pieces of work with other teams at the FT, etc.
3. Technical strategy: mainly this is working on the defined next steps of our tech strategy, but this also includes strategic things like writing blog posts, or arranging workshops.

We then colour-coded the cards we use on our wall. The idea is that we should be spending around a third of our time on each of those things.

Because we are still using cards on a wall, we can’t measure how much time we are spending, but we can at a glance make sure that the team in general, and each of us individually, are doing roughly a split of those those types of task.

It’s also turned out to be really useful for making sure that certain people weren’t always doing certain things, e.g. for making sure that the women on the team do not always end up doing the team health tasks.

Regular planning meetings

We’ve also recently added planning meetings. While we do have a weekly meeting, we don’t always make sure that we cover upcoming concerns. We haven’t quite worked out the best format for the planning meetings yet, but so far it’s involved discussing a list of things that are coming up that we are not sure are being addressed in other ways; for example things that we don’t think are covered by our tech strategy and possibly should be.

A lot of the work in the planning meeting is ahead of time in compiling the agenda. This has been useful so far, and we will tweak the format to make it more useful as we go on.

Sharing my thinking

I have a clear idea of where we are trying to get to with our tech strategy and what good looks like, but I don’t think I’ve shared that consistently well, so I’ve been consciously working on communicating that better.

For example, I’ve added a page to the internal wiki, I gave a talk at a conference and I’m currently working on a blog post (watch this space!). I’m also working on how we actually measure/evaluate that our tech strategy has been successful.

Interesting suggestions I had from my network around this included the idea of command intent and Amazon’s practice of working backwards.

As a team, we could also do more to share what we are working on with the rest of Customer Products. We’ve let people know that they are welcome to attend our stand-ups, but so far no-one has, and we could do more to let people know what we’re working on.

These changes have really improved how we work together

We are now working together and sharing information really well as a team, and others are approaching the team with questions, rather than approaching individuals.

We’ve got room for improvement, but it’s definitely going in the right direction. Recently, I’ve been out of the office for a couple of weeks. When I came back, everything had carried on. Decisions had been made, new work had come in and been handled, and apart from some budget approvals, there was nothing that had been on hold waiting for me to get back. This is a brilliant result.