These are the activities you can safely assign to a software engineer who is leaving the Company

It’s natural for those leaving their job to have their mind in the future. Although they need to work until the last day, it’s your responsibility as a leader to play safe and limit the activities you assign to them.

These are the activities you can safely assign to a software engineer who is leaving the Company

The last thing I'd like to see happening in my team is a developer implementing a change after their farewell lunch.

Even the most professional workers diminish their performance during their last days at the company. Their focus is already on the future, which unavoidably raises the chances of making mistakes. Your role as team leader is to maximize each member's contribution until they leave without incurring unnecessary risks.

You must carefully choose the activities you assign to them during the notice period, prioritizing the team's future.

What would you do in their place?

When I leave a company, my rule is not to accept anything new after presenting my resignation letter. The notice period in the countries where I've lived is short (2–4 weeks). That's enough for handing over my topics, organizing my documentation, and giving a few knowledge transfer sessions.

I use those weeks to make sure they won't miss me (or curse any of my close relatives).

As a leader, I would expect the same from any collaborator. Many companies release their employees from the notice period to avoid having people with presumably low levels of compromise at the office.

However, the notice period in some countries is more extended (10-12 weeks). In such cases, the cost of releasing the employee is high, so they should continue contributing to your team.

Activities you can safely assign

As a general rule, these activities should be:

  • Short so that they can complete them
  • Independent, so they don't create any dependency upon the leaving collaborator
  • Low-risk/Low-exposition, so some mistakes are accepted
  • Instructive, so the rest of the team can absorb some of their knowledge

Some examples are:

  • Knowledge transfer sessions, including both handing over their activities and any other particular knowledge the collaborator could share
  • Documentation, which is often left behind when implementing projects.
  • Short demands in collaboration with other team members
  • Collecting emails containing agreements or discussions sustained with other areas that serve to justify decisions and cover the team in the future.
  • Repetitive activities at the bottom of the priority list, which the employee can do at their own pace without relevant impact.

Conclusion

When the notice period is short, I'd prefer to release the employee right after they hand over all their topics.

But if that's not possible, assigning training or low-risk tasks is the way to protect the team's future and guarantee a smooth transition.