Having your manager change is never easy - even in the best case, you will lose someone who was rooting for you and had your best interest in mind, only to start the whole journey anew with a stranger. Re-building a shared context and a trust relationship after a handover is significant work. I collected a few ideas from performing more than 20 handovers to make that process a bit smoother. I think these ideas are useful whether you are a manager yourself or an individual contributor getting handed over.
The idea behind this whole process is that the engineer becomes the owner of their own story. They can decide what context gets moved over, and what can stay in the past. Usually, in handovers context was shared only between new and old managers, or none at all. I feel this way supports morale a lot more than moving people around like chess pieces - I always hated being handed over like this, especially as I had to rebuild all my standing again with my new manager.
Most of these learnings come from experimenting during Personios hypergrowth phase in 2020-2022.
The Handover Process
People should be aware that a manager transition is on the way a few weeks in advance - it helps just to be mentally prepared for yet another change. If the manager is a new hire, maybe some of your engineers have participated in interviewing the candidate, but for most, you will be the first time they hear of this person. I try to outline the organizational need for the handover, and the benefit they will be seeing from the transition. 1
2. Handover Document Assignment
I then asked them to prepare a handover document (more on this later), and offered my support in reviewing it. Pro-tip: Give a meaningful timeline for when you will need this document to not get anyone in panic mode :) I started with a very free format (put in what you think is important to you), but many struggled with this ambiguous ask, so I tried to boil it down to a rough outline.
3. General Introduction
The new manager will be invited into slack channels, meetings and such. They get the opportunity to introduce themselves to the team in a group setting. I’ll probably write another article on onboarding a manager, so this is just one aspect of many for them.
4. Handover Meeting
I would run a dedicated handover meeting with 3 people: the engineer, the new manager and me. In this meeting, the engineer would do most of the talking and guide us through the handover document. The new manager can ask questions to clarify what they need, and I was there mostly to kick off the introduction, and to also announce my “departure” from the one on ones. A nice time to say goodbye after celebrating all the wins from the engineer!
The Handover Document
This is the key aspect of the whole exercise: A one-pager that the engineer can prepare themselves - this way they can own the story and context of their handover.
If your engineer already has a Brag Document, they can pretty much paste it in here, and maybe cut it to the 10 most relevant / biggest things and link the rest. If they don’t have one, you both need to go research all their past achievements - maybe your 1:1 notes document has context2. You as the manager can give pointers in what you want to see in there - a lot of people are too humble, forgetful or both. This part exists of course to help the new manager understand how awesome this person is, and none of the previous achievements gets erased in transit.
2: Work in progress
All current “manager-work” that is going on. Are we working on something together that needs continuation? Of course, preparation for promotion is an obvious case, but maybe someone is looking to change teams or trying to gain competence in a new field.
It’s delicate and depends a lot on what the engineer is comfortable with, but some were okay with putting in coaching topics, like “We’re working on me not doing 10 things in parallel” or “we’re working on me avoiding confrontational conversations, that I need to have”.
3: Important Playground rules
There might be some important rules or behaviors that you have agreed on earlier, that the new manager should be aware of to not start off on the wrong foot. That could be “I pick my child from childcare at 8am, please don’t schedule anything there” to behavioral caution, e.g. “I hate public praise and being put on the spot”. Of course, putting things here needs trust, which the new manager hasn’t built yet, so don’t force people to put more than they are comfortable with.
Some people put in a section of “Things that Chris did that I liked, please also do them” :) Likely, given the power imbalance in such situations, they’ll share the inverse of “things Chris did that I want to stop” privately, or better, they feedbacked me way before and I stopped doing that thing a long time ago.
Do we need a Backchannel?
This process gives a lot of power to the engineers, and you might ask if there was any “backchannel” between the managers about people. I initially thought I would need it, but turns out the work that my engineers produced was so complete and surprisingly honest, that it wasn’t needed. I would still do it if something critical would be missed, or if someone is on a PIP or comparable process. But for all cases so far, it wasn’t needed.
Dealing with 1:1s
I am definitely guilty of running 1:1s too long during a handover phase, probably rendering the new manager a lame duck for a while. I have also experienced handovers via a three-way-1:1 with both new managers present, and I found them to be the most awkward meetings of my life: A 1:1 is a trusted space, that immediately breaks to pieces if two managers are present. I avoid doing this.
I will end my 1:1 journey on the meeting before the discussed handover meeting, and then cancel any future 1:1s, to let the new manager schedule the new iteration. The running document I had stays confidential and pretty much gets archived.
If you become the new skip-level leader of the engineer, I left an intentional gap of 2-3 months before setting up any skip-level 1:1s, to not interfere with the new manager and the build-up of their trust relationship.
Very often that reasoning was “I’m dying, I have more than 20 direct reports in multiple teams, and I can’t focus on you and your growth properly. The new person will finally be able to do a decent job” ↩︎
I keep my 1:1 notes shared with the other person - I was first skeptical because my note-taking can be a bit chaotic, but for situations like this it’s very helpful that both can take a look back at the topics discussed ↩︎