Leaving a Job on Good Terms

Once you have accepted a new offer, how should you spend your notice period in your current job? Furiously busy to finish projects or gazing out the window?

There is another alternative to the opposites of detached boredom and trying to fit everything in. Rather than try to do everything yourself, probably an impossible mission, or ignoring work, you can try to ensure that everything that needs to be done is properly handed over. The aim here is to ensure that there is a minimum of disruption when you leave; in effect that you are not missed sorely after your departure.

In the US, notice periods can be extremely short. There can be only a matter of weeks or days to complete a handover, given the shortness of the period and the availability of colleagues. In Europe things tend to stretch out a little longer, with a month the typical notice period. Those in management roles tend to have a notice period of two months, but it can stretch up to six for director level positions. Assume for the purpose of this post that one full month is what is available.

It also may depend on the company that you are transitioning to. If it is a competitor in the same industry, be prepared to be escorted off the property immediately after you hand in your notice, especially if there is any chance that you could bring trade secrets or clients with you. The latter is less likely for software engineers, but there may be a worry that you may take proprietary knowledge.

This is going to be a two-part post. The first will give some reasons why a good handover is in your own interests. The second will give a list of some of the things that you should consider doing when leaving a job.

Why Should I Care About a Smooth Transition?

Admittedly there will be a strong feeling that the things for which you are responsible are no longer your problem. It may be difficult to find the motivation to keep going and to make sure that there is not a complete disaster when you leave. Here are a couple of small reasons to try to keep yourself interested.

It’s a Small World

In IT especially, we tend to meet the same faces in different companies over the years. Imagine that you meet an ex-colleague from a company that you left abruptly without a handover. What would it have felt or looked like to them? It might have felt like you tossed a live grenade into the office as you left for the last time.

Fast forward to the new company several years later. This former colleague arrived at your new company before you and surprises you by introducing themselves on your first day. They remember you clearly but not for the many good things you did, only for the final act.

You will see it in their eyes that they recall the exact circumstances of how you departed. Will this affect their opinion of you, of the trust they put in you? Probably, and it is not the best way to start in a new company. You may have been lucky to have passed through the interview process despite their opinion about you.

Flip that over to the alternative - that you left in good terms having completed an acceptable handover and left no problems for your former colleagues to find later on. When you meet these colleagues later in your career, they will be open to trusting you right from the start, and if asked about you during the interview screening process are more likely to give a favourable response.

Professional Pride

Unless you are working as a contractor, employed to complete a single or time bound project, you are likely to always be in the midst of one or more projects that you are heavily involved in. There is never a perfect time to leave a software engineering job, when all bugs carefully fixed, code reviews complete and the system purring along nicely in production. There will always be open problems.

It’s true, not everyone has obsessive compulsive feelings that make them want to leave with everything just so, but it is nice to leave things squarely tidied away. I call this professional pride.

Software does not last forever. The code written yesterday has a life expectancy, and it is usually shorter than the engineer that wrote it thinks. We try to give our code the best chance it can have to last: writing clean, well-tested code, documenting the design decisions, documenting support procedures, building continuous integration pipelines to ensure it still builds, and other techniques. There is an underlying desire to make our creations last as long as they can.

When you are leaving a job, it is too late to start thinking about the longevity of your code; the quality methods in the previous paragraph need to be considered and implemented as you write code, not as you leave the building. But you should maintain the same, high level of quality in the remaining work that you complete for your company. Treat it as a matter of pride, that the last modules you build or interact with are handled with a high degree of professionalism.

Karma

Karma is an Eastern belief that basically means “what goes around comes around”. Not scientific but humans tend to recognise the appearance of karma in their lives repeatedly. A good deed one day may lead to a favourable outcome later. Similarly when we act with malice or neglect, a later mishap or piece of bad news may be identified as the justified punishment for the misdeed.

While I find no evidence that there is a manifest spirit blessing and cursing good and evil doers, respectively, I do think that there is something psychological going on that shapes our destiny by our deeds. Do we cause our own karmic punishments without knowing it? Are we more willing to accept good news if we think we deserve good fortune?

If you are lazy or spiteful once, this is unlikely to cause any noticeable bad luck on your part. But if you continuously do things this way then there is a likelihood that you will garner no support or favour from your colleagues. Bad things will happen and no one will step up to help. Your behaviour dictates how people respond and react to you.

Behaviour defines us. How we act is what allows our co-workers to form opinions of us, but it also shapes our own self-image. If you slack off in your last few weeks in a job, not maintaining the same standards as you had throughout, this is going against you normal behaviours. I have no doubt that when people see karmic justice it is because they recognised some sort of behaviour that was out of person for them and they sought out the punishment to link to that act.

So whether you believe in karma or not, try to keep your behaviour at the same standard. Whether from a karmic punishment or a feeling of regret or shame, don’t bring that baggage with you into your next position.

Key Person Risk

When there is only one person in a company that can do a task or perform a business function, this is usually termed a key person risk. I’ve taken part in several Risk Self Assessments centred on the IT department and this often gets raised. It happens when just one person that knows how to do something important. The mitigations to put in place are things like writing support documentation, cross training, and recruitment.

While it might feel nice to be a “key person”, the one that is always called upon to fix a particular issue, this is not a good place to be in reality. One danger is that you get stuck with the job. Another is that you look like you are keeping knowledge to yourself. This may feel like a good way to protect your job, but it is also selfish and can hurt your company. Don’t try to hold your company to ransom.

A better strategy, I believe, is to be a key person for entirely different reasons. Rather than someone with specific knowledge for a single system, be known as someone that can solve any problem, who is open to consulting and helping peers when surprises arise. And when you fix problems, ensure that you don’t just fix the problem and move on; you should train a colleague, showing them how to investigate and fix the issue or similar ones should they arise in the future.

Even better, after the initial incident response, take an active part in the root cause analysis for the problem. Try to suggest a permanent fix, whether it is a code change, additional monitoring or a new procedure. Be known as someone that leaves things better every time they work on a system or service.

Again, as with code quality, it may be too late to begin this attitude during your period of notice. But you do have the opportunity to do a small-scale risk assessment. Being good at sharing information and not becoming a key person requires an attitude change and also the right culture. If you have not been this type of person in the past, make a commitment to yourself to change when you begin your new job.