In a dynamic, fast-paced company, there always comes a time when you need to handover some thing to someone else. That thing could be a project, a system, a team, someone who reports to you, or even an entire role.

In the last couple of years, I have done this several times–mostly because Monzo had grown. I started a regulatory data project because we were a lean data team, and then handed it over to a new colleague who was hired for that area. I started managing some of our new Data Scientists, and then handed some them over as they moved into newly formed teams or domains. For a while, I was the Data Lead for all of Operations, until we hired someone specifically for that role. Most recently, I stepped into a role where I temporarily wore the Product Manager hat in an Engineering squad in order to ship some much-needed core systems work, and inherited and then handed over a system in within one quarter.

Handovers are never easy. There’s always some uncertainty. There’s a fear of inheriting a thing that is full of hidden surprises when gaining a hat; there’s a worry that the quality or pace of the work is somehow going to suffer when giving it away; that decisions will be rolled back or viewed retrospectively as incorrect. There is definitely an uneasy feeling when handing over a hat or role that has been a big part of your day-to-day (perhaps accompanied with a ‘what am I going to be doing next?’ feeling). Giving away your legos is hard. However, I have yet to see many of these worries turn into anything substantial.

What I have seen more often is that there is a lot of uncertainty with the handover process itself, and it ends up happening too fast or too slow. This is compounded by the fact that multiple handovers may happen at the same time, as you exit one project and enter or start up a different one. Both of these do not set up the folks involved for success: if it happens too fast, the ‘new’ person is dropped into the deep end; if it happens to slow, the ‘old’ person ends up doing two jobs for a long time.

Every time that another handover looms, I tend to recall Kevin Goldsmith’s talk “Using Agile Techniques to Build a More Inclusive Team” from Lead Dev 2018, which was recommended to me by @willpillar.

Although the title doesn’t sound like it has much to do with handovers, Kevin describes a four-step process for them - likening it to an kanban board of sorts. I have used this (sometimes explicitly, sometimes just for myself) to smoothen the handover journey.

Here’s how it works. Imagine breaking down all of the things you do as part of the role or project that you are handing over - as if each one were on a post-it. You start out with all of these post-its on the left-most column of a board with the headers below. Each one clearly demarcates a stage of handing something over between two people.

1. You are doing. These are the items that it is your sole responsibility to plan, track, do, and finish. It is important to map them out - giving visibility to the work - and making it clear that these things are due to be handed over in the right time.
2. You are onboarding. Items in this column are still your responsibility to execute – but it is now your job to onboard the new person into what they are, why they need doing, and how you do them.
3. They are offboarding. Moving a ticket from the previous column to this one is where the new person takes the wheel. They are now in charge of doing this item, with a few conditions: they loop back regularly, communicating progress, asking questions, getting support, and validating their approach.
4. They are doing. This is the ‘done’ column for a handover. Items that reach this column are done by the new person, without needing to loop in the old one. By this point, the new person should have the confidence that they have all the right context; the old person should have confidence in the new person’s ability to do this thing.

The key thing that this format provides is a structure for handovers. It highlights that moving everything from left to right can’t happen overnight; critically, it gives both parties a clear view of who is responsible for what over time.

I’ll close, though, by describing one way this can fall over a bit: when you handover a role and that role changes at the same time, perhaps by taking on a new scope, or by splitting itself up into multiple roles. In these cases, it may mean that the post-its that are on the board do not make it from left to right; instead, they drop out altogether. Ultimately, this is fine! At least you know what happened to them 🙂

📺 Using Agile Techniques to Build a More Inclusive Team

Here is the full talk below: