Succession planning for when you leave a job
It's time for you to move on, and you're excited about your new job. But before you go, you want to smooth the path for the next person in your role.
The idea of passing the reins sounds good, but how do you do that? Perhaps this advice may help.
My premise is that you genuinely want to help the person who moves into your old job. This isn't a job separation made in anger, where you're tempted to slam the door when you go. You sincerely want your former co-workers to succeed. The old joke wherein a departing boss hands the new manager three envelopes to open when things get tough is not relevant.
Also, these tips apply even when you are not actually leaving the company. Perhaps you were promoted, have shifted to another department, or are going on maternity leave. The point is that someone else has to do what you were doing.
Document everything. Duh.
The most common suggestion is to document everything you do so the new person has instructions to rely on. You may think in terms of writing out the standard operating procedures, but that's just the beginning.
"When I stepped into my previous job, which was basically a system administrator role, I had no clue what the guy before me did," explains Kelly, an IT professional. The previous sysadmin didn't share who his contacts were (vendors or otherwise), logins… nothing. "I had to spend a lot of time just figuring out what to do in order to do my job effectively," says Kelly. "I also walked into a huge project that was left stagnant and needed to be completed straight away."
It's a good idea for you to document your job, in any case. First, there's the so-called project bus factor, which describes how many people can be incapacitated before a project can no longer continue—that is, if you were hit by a bus tomorrow, someone would have to replace you, probably before your obituary is published.
"Have an 'if I get hit by a bus' file that you regularly maintain regardless of whether you're planning to leave," advises Sarah Vela, senior manager of digital communications at Forcepoint. Make it accessible to your team so they know where to find it, she adds.
That file has additional benefits:
- The documentation can serve as your own "style guide," particularly for tasks you do infrequently. (Let's see, how did we handle this last year?)
- A list of your regular duties and how to accomplish them can be useful evidence when you ask for a raise. Few people realize how much they do, including their bosses.
- If things go pear-shaped and you're laid off without warning, the documentation can help those left behind. You might be angry about the company's behavior but still want to help your teammates.
So, what should be in that documentation?
The State of Hiring: Learn how 101 IT execs find staff for critical positions.
Start with the big picture
Start with an overview. "Often, it's that bigger picture layout that is missing," says Abadesi Osunsade, co-founder of Elpha, a network for women in tech. "Begin with a reminder of what we're collectively striving for, so I can prioritize my workflow."
Think in terms of projects, process, and details to support those. When Catt went on maternity leave, she wrote up a yearlong plan that included long-term milestones; common questions and answers, including the why behind the answers; and clear-cut duties, to prevent scope creep while she was gone.
One way to help the new person prioritize is to organize the document by urgency. Intellectual property lawyer Judith suggests you list upcoming matters that require action and then the status of everything in progress.
Dave Neary, a software developer tools expert, says, "The goals of a succession package should be twofold: avoid unnecessary rediscovery of what went before and enable integration into the company/tribe."
This is a document of brutal honesty. So, sure, list project status for everything that is underway. But "most important, give a gut feel for whether tasks will actually complete on time and why or why not," recommends Harwell Thrasher, author of "Boiling the IT Frog: How to Make Your Business Information Technology Wildly Successful Without Having to Learn Anything Technical." He adds, "Also [include] a budget overview, with hints on where the slack is hidden (I hid mine in training)."
Make a decent index if the document is extensive. "Near-term issues are most important for the next person and can easily get lost in a data dump if not pointed out," says legal counsel Krys Corbett. Most people will not go through the whole data dump, so it's important to highlight the takeaways.
The devil in the details
When you get to specifics, include your daily, weekly, and monthly tasks, including the processes that helped you better run the shop.
Document the critical details to the best of your ability, says business analyst Randall Arnold. "Assume nothing. Cover every step and requirement." In particular, make sure "do this" instructions include the necessary prerequisites. What has to be done first? In what order?
For example, when mainframe developer Mark left his job, "for system modifications, I wrote a document which included for each one what it does, how it's implemented, when is it implemented, dependencies, and how to implement when a new level of the operating system is built."
You're apt to take your own organization process for granted, but it's a good idea to document that, too. Paul Reinke, formerly a manager at Booz Allen Hamilton, disciplined himself into organizing his documentation with plain-English labels such as client names, project names (with subfolders by billing code and personnel records and performance reviews by employee name), and so on. "I also use an indexing system provided by the company to tag the data in the files," he adds. "All are located on shared drives accessible through administrative permission. So the company and my successor retains everything it needs to get at."
What assets do you rely on? What are the login or access details? Where are they kept? Tutorials for recurrent tasks are valuable. So is a password locker with every possible login. Include a list of vendor contacts, and itemize who to call to help with unusual situations (the company's legal contact, SEO specialists, and so on).
If you can, give the new hire access to your work mailbox. All kinds of details are buried there that no documentation can cover, says Internet activist Hanan Cohen. "I did that in the last jobs I left, and I know it was very helpful. Delete HR stuff beforehand, of course."
A handover guide and template for government contractors from International Medical Corps can help you get started—in a Mad Libs fashion.
Most documentation tells your replacement how things are supposed to work. But don't forget to include the way they really do. Don't be coy in the name of being "professional." You want to know about the people who never respond despite repeated entreaties, the computer system that seems to go down every weekend, the marketing person who always has "oh, just one more thing" 20 minutes before deadline.
Which brings us to the hardest part of the handoff: people.
Tell 'em about the people issues
"My favorite thing to get or give is a cast of characters," says Neary. "Here are the people you will have relationships with and why."
Explain how decisions are made and who has the most influence in that process, adds Abadesi. "Finding that out piecemeal or by trial and error can be exhausting and deflating," she says.
Provide a summary of all the players: employees, fellow managers, customers, and users, says Thrasher. For each player, include a general idea of pros and cons, strengths and weaknesses, trustworthiness, and things to watch out for. While the new staff develops its own relationships, the new person can begin with a set of assumptions that help interpret future interactions.
Don't interpret that as a negative; it's just useful information. For example, if you know Melanie works from Prague and her time zone can slow down email correspondence, you can save your replacement the pain of that particular learning experience.
One way to ease the transition is to take care of things before you go. Before Catt went on maternity leave, she pushed strongly on who should do which tasks ("management had a hand-wavy plan that I didn't agree with"). She also took the time to do her team's annual evaluations early, as her temporary replacement wouldn't be qualified to offer judgment or advice.
Work together with the replacement
In the best of situations, you have an opportunity to give the new person mentoring and personal training. "Offer to have someone shadow you in your final week," suggests Vela. "So much comes up during the day that won't even occur to you to put in the file."
"I always appreciated when I started a new role, I had the chance to shadow someone, to observe a peer use all the tools and run through all the priorities so I understood the context for our metrics and goals," says Abadesi.
When you recognize that it's time for you to leave, give some attention to who should take over. Make introductions. "When I knew it was just a matter of when, I slowly removed myself from client interaction by introducing my direct report employee to the client as the 'lead technical staff' or some such title to get the client to accept working with that person as a proxy for me," Reinke says. "By the time I left, the client had been working with them on a daily basis, and I had trained the direct report in how to manage the client by advising during the learning curve."
Be available to help your replacement after you leave—to a point. It's fine to answer questions by phone or email and provide a friendly ear, but set limits or you'll find yourself providing free consulting.
One more thing
If you conduct job interviews, asking about transitions is a good interview question. One online acquaintance had a manager who asked, "How will your current team be affected by your departure if you came to work here?"
"He'd get a lot of braggy answers of people trying to hype up their own accomplishments and how great they were by saying their old team would be screwed without them, that they did most of the really hard work, etc.
"Better answers focused on, 'They'll miss my specialization in X, but I've written documentation that covers some of that, plus Y and Z, so my replacement should be able to hit the ground running' and things like that.
"I thought it was a savvy question because the 'right' answer is counterintuitive, at least in the moment. That manager recognized that if a candidate was leaving their current team in a lurch, then when the time came for them to leave our team, they'd be likely to do the same."
Finally, move on and don't look back
Despite your effort to create a useful, detailed transition plan, don't be disappointed if nobody follows it. Management may make promises about hiring new staff or replacing outdated tools or your replacement may decide he has a "better way," but they may not follow through.
One tech professional says that in his last position, he wrote step-by-step instructions, but "unfortunately, the manager I was under also left, so both my replacement and the new manager decided to scrap everything. A few months later, they realized that they had no idea what they were doing and asked for my instructions (which I happened to keep a copy of)."
For your own sanity, adopt the attitude that you did what you could to ease the next person's burden—and now it's up to them.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.