How To Leave A Team (Gracefully)

Hi there!

Most things that have a beginning, also have an end. While there are some things for which this statement doesn’t hold true, e.g. the natural numbers, there are a lot of things for whit it does. Foremost, the time at our disposal.

One takes over a specific role such as a Backend Engineer, performs accordingly, and at some point it’s time to leave. For the purpose of this post, the reason is irrelevant as long as it’s foreseeable. One might be going to leave the company, retire, or simply switching teams within a company. It should go without saying that managing one’s farewell is as much a part of one’s professional obligations as writing and reviewing code or documentation. Whatever the reason, no matter how bad a team’s mood might be.

When And How To Start The Process

As soon as possible. As soon as you know you’re going to leave, plan for it accordingly. Start collecting issues and tasks that might end up as loose ends and tend to your documentation with even more care. Not only will it make it easier for your team to handle your departure, but this will also create goodwill for the time that precedes your farewell.

The Proclamation And The Fallout

Once you tell your team you’re leaving, there will be mixed reactions. Some people will be sad. Some will be angry, yet not necessarily at you specifically. And some people won’t realize the news until a few days before you actually leave. I think it’s important to clarify your intent to handle this as smoothly and professionally as possible. Make this message as explicit as possible. Even if you’re in a GTFO scenario where you just can’t stand some decision some part of your company made, or even one of your teammates. Keeping things professional is just part of being a professional.

Attitude Matters

Leaving with a demeanor of “not my problem anymore” is not just unprofessional. I think it’s just plain stupid and - even worse - illogical. Just as the time you spend at the beginning of a new role, it’s your attitude that matters most when you’re about to leave. I don’t say you should hug everyone on your way out, pandemic or not, but don’t hold grudges. For some people that’s more difficult that for others, but it should be doable in most cases. If it’s not, it might be wise to talk to one’s supervisor and HR department about a mutually-agreed early termination of one’s work contract.

So stay friendly if you can, stay polite if you can’t, and prepare your team for a time after your farewell. Look forward to your next job, your retirement, or sabbatical, but stay focused on the tasks at hand. If needed, find comfort in the fact that all will be over soon.

Preparing Your Team

In the best-case scenario, in which your bus count is larger than one, this is easy. Just end what you’re doing right now and pick up those cleanup tasks that never get a high enough priority to get done. Such tasks can actually feel very satisfying and completing them will earn you a lot of goodwill with your soon-to-be ex-colleagues.

But you’ll probably not work in such an environment. There’s probably a part of your work that nobody else knows a lot about. It’s that part you need to cover first and foremost as this is the part of work for which you’re currently irreplaceable. It’s now - more than ever - your job to make yourself replaceable.

Enabling Questions

You want your colleagues to know and understand what you know and understand, or at least as much of it as possible in the time given. And the earlier questions start coming, the more successful you will be. Simply standing in front of a whiteboard or giving a talk remotely won’t be enough to enable your colleagues to take over your projects and systems. It will be too much information for your colleagues to remember. And the problems you’re solving might be so complex that it’s just impossible to make your colleagues understand the problem and its solution that way.

Understanding Technical Problems

What works quite well, in my experience, is to first make your colleagues understand the difficult problems you’re solving, at least roughly. It might be keeping some old systems in sync. Or to access an external API that’s quirky as hell. Make them understand the problem, not only remember it, and the most important task is achieved. This is a process and will take some weeks to accomplish. Use any and all means necessary: Documentation, Code, Live-Demos, you name it. Then it’s time to…

WTFM

If you’ve started early, by the time you proclaim your upcoming departure, you’ve already written a lot of documentation. If not, it’s time to start now. After gaining a first rough understanding of the problems you’re handling, your colleagues will likely consult documentation. They will find and point out inconsistencies, missing information, etc. You will fix all that and simultaneously, you’ll foster a deeper understanding of the problems.

The Code

After a while, it’s time for your colleagues to dive into the critical code you wrote and maintained. There will be things that are missing, quirky, or just plain wrong. Asking about these problems will cause your colleagues to gain knowledge, which is exactly what you’re aiming at! If there’s time, and there should be, fix some bugs together. After all, it’s in failures that a system reveal their structure. Then, implement some smaller business requirements. Doing three or four tickets this way should spawn plenty of questions. Also, answering them will spawn follow-up questions. If that happens, you know it’s working. When good questions keep coming, you know have your audience’s full attention.

Tie Up Loose Ends

In addition to prepare your teammates for a time without you, finish your most important work. If you can’t, because preparing your coworkers takes so much time, finish as much of the solution’s design as you can and write a design document for your colleagues. There’s plenty of resources on the Internet about them, so if you don’t already have a preferred structure, pick one from the Internet you deem fitting and write one for all your “loose ends”. As always, it’s important to make your colleagues understand the problems foremost, and then your suggested solution. State constraints, benefits, open problems, etc.

Ends Are Beginnings

Do you remember the time when you startet out in your current team? And maybe the ones before? Great! Use that and think about what helped or would have helped you back then. In the end, taking over another one’s tasks is comparable to entering a new team: People are expected to solve problems about which they don’t now a lot, yet.

Why Give A Damn?

As you might now by know, I deem it important to give a damn, i.e. to put effort into making your departure as painless for your team as possible. “But why?”, you might ask. For several Reasons…

1. Altruism: Coworkers are People. Treat them as you want to be treated.
2. Selfishness: You’ll probably be held in high regards when you do it well. The Software world is a tiny place. A current coworker might end up being your next team lead or engineering manager.
3. Professionalism: Give a damn because you’re the gal or guy who gives a damn.
4. Practice: Your code will be examined. And chances are this is the most thorough code review you’ve ever gotten in that team. Simply because your current teammates might be more invested in it than ever.