Leaving a Job Part Two

So you are leaving your job as a software engineer and want to leave a lasting impression of professionalism; how exactly does one do that?

In this series of posts, I have discussed elements of furthering your career as software engineer. At some stage you will have to change company to take the next steps, either because you have outgrown your current company or perhaps want to go in a different direction. Last time, in Leaving a Job on Good Terms we covered the reasons for making an effort to leave a good impression when you leave. We continue this topic now with some things to consider.

What To Do in a Notice Period

It all depends on the position you have, the seniority level and the projects that are in progress when you hand in your notice. The time will flow by quickly so dedicate an hour to come up with a plan about what needs to be handed over. Here are few things to think about.

Direct Reports

If you are in a leadership position, the change may have a serious impact on the staff that report directly to you. They are going to have questions about what your departure is going to mean for them, and part of your time should be dedicated to finding out the answers to their questions. Choices include the team breaking up and each member going to join a different team, finding another suitable leader to take your place or promoting one of the team members to take your place.

If the team is going to break up then you will need to work with your own manager to ensure that each member gets allocated to a team that will be suited to them and give them opportunity to grow and learn. Don’t assume that your manager knows the skills and weaknesses of each team member as well as you do; it is important that you represent them in any discussion about their future, having talked first directly with your reports to find out about their ambitions.

The more you know your team and their career aspirations, the better you will be able to help with this. Regular communication is the best way for this, so hopefully that has been how you have managed them in the past. But it’s never too late. Make sure that you sit down with them individually as soon as possible after announcing your departure.

Often it makes more sense to keep the remnants of a team together, especially if they are responsible for a key software product or service. The desire may be to keep the pace and quality of development as close as possible to when you were in charge. A key responsibility of a leader is to groom one or more team members to fill the leadership role. Do you have such a person in mind?

This is not something that can be achieved in a short period of time, rather it has to be done by gradually giving more responsibility to the person in question. Each time they take ownership of a decision, it moves them one step closer to taking on a leadership role. But it needs to be a slow and steady tactic, first focusing on giving them responsibility for the software and then increase it to being a leader, making decisions about the direction that the team takes. If you are only thinking of who might be best suited after you have handed in your notice, it will be too late for a proper succession.

Software developers like to constantly learn and experience new things, I find. Leave them working in the same technology for too long and they can become frustrated or bored. Depending on the size of your organisation, you may have a colleague at your level that would love a change of scenery that they would get from taking over your position. If there are no likely candidates from within you own team, cast the net wider to see if any of your peers would suit. The aim is to try to find a good fit so that your direct reports will undergo the least stress and continue to deliver.

Responsibilities

Do you have a run book for for what you do every day? If someone was to take any of your daily tasks from you, have you documented what the procedure or process is? Most of us would answer that with a “No”. We just do what we know we have to do and just get on with it.

There is some sense, however, in having some documentation about how to do the things you do every day. Writing code is just writing code, you might say. But that’s not strictly true. Before you can write a single line of code you need tooling, access to source code repositories, knowledge of the build tooling and at least a rudimentary understanding of the continuous build setup. Does your organisation have this documented?

Consider a new employee joining your company or team. Can you give them minimal instructions, pointing to documented wikis or blogs, for example, on how to get set up? Or will you or a team mate have to sit down with them to explain everything one step at a time? Some combination of the two is probably best, but it makes sense to allow them to follow the process using quality instructions rather than have someone sitting with them all the time.

When you leave your company, will you take the knowledge of what your responsibilities are with you? It would be great to be able to talk to your boss and team and to tell them that you have documented all the things you do each day, month and year. All they have to do is to assign each task to someone. But most of us have not put enough forethought into things to have done this.

Completing this before you leave may be too much to consider doing during your notice period, but you should at least try to come up with a list of all the activities that you have responsibility for. It is up to you to ensure that there is someone that is assigned to each to take over from you. You will need to bring the list up with your boss and get them to assign someone if you cannot.

Then you need to perform an adequate handover. That means meeting individuals or groups and running them through what needs to be done. Depending on the audience it will become clear where additional notes or documentation is needed. Try to do this early on in your notice period so that there is adequate time for handing it all over and answering any questions that arise.

Remaining projects

As you approach the end of your time in a company, it is important to let those on any projects you are involved in know that you are leaving. Project managers need to make requests to make sure that they keep the project staffed. Also it is simply polite to break the news personally to people rather than let them hear on the grapevine.

Spend some time identifying areas of the project for which you are the principle engineer. Is there a design task that you are best suited for? Is there a technology that you are most experienced in? There could be an impact if these things are not completed before your departure date.

Once identified, either work out a plan to hand the work over to another colleague or discuss with your line manager and your boss to see if there is adequate time to complete the work before your final day.

Conclusion

It is probably going to be difficult to close off everything before the end of a notice period. Try to focus on the activities, processes or projects for which you are the most senior decision maker. List all for these items in order of priority. Add your direct reports to the list.

Bring this to your boss and and co-workers and ask for volunteers to receive a handover from you. Do this early, and schedule the meetings so that there is adequate time afterwards for follow up questions. Make sure that you direct reports know what is going to happen after you leave.

If everything goes well, all your responsibilities will be distributed, everything will be documented, and if issues do arise, the remaining staff will have the skills, knowledge and tools to solve them. You can leave the job knowing you have done everything possible to leave a lasting positive impression on your peers.