All Aboard!: Tips for effective IT onboarding and handover

17 Oct 2023 All Aboard!: Tips for effective IT onboarding and handover

Almost every job in existence requires some kind of onboarding process when someone new joins the team. In the IT industry this can involve bringing technical skills up to the level required, getting familiar with processes in place, or getting access to the tools and resources required to do the job. As a consultant there are also complicating factors which may involve integrating into a client’s infrastructure.

Depending on the team structure, there may be times when colleagues are not immediately available to help with this process. Alternately, it may be a complete handover from someone who is permanently leaving the role, in which case any information that is not transferred during handover could be lost forever.

During your career you may have come across people within an organisation who seem to be the sole expert on a particular system. If you need to know anything about that system, you’ll pretty much be immediately directed to go and ask them about it.

This is a particularly heavy risk for an organisation to carry and should be avoided wherever possible. In this post I’m going to talk about key areas to consider when onboarding new people to a system and how to improve the effectiveness of those working in support of it.

Documentation

I believe documentation is the single most important component in the onboarding process. It is great to have someone to talk through and explain the responsibilities of the job, but it is incredibly difficult to impart all that knowledge in person. Things will inevitably be forgotten, miscommunicated, or lack necessary details. It is also difficult to absorb and retain information passed on verbally.

If your team does not currently have centralised onboarding documentation, I encourage you to create it immediately, preferably in a document store like Confluence or Google Docs. It will make the job easier for people already in the team, as it will create consistency and identify knowledge gaps between team members.

There is also the great advantage that once a document repository has been created, it is always available. The same cannot be said for the lead developer who happens to be on leave at the exact time disaster hits the production application!

If you do not have a document repository, and are ready to onboard a new team member now, have them create the initial set of documentation. This will work as a record of all the information that HAS BEEN passed on, and by it’s absence, all the information that NEEDS TO BE imparted.

The new team member will inevitably have questions. Some questions are difficult to ask during an introductory meeting, as you never know what you don’t know. So have someone document these questions as they arise, creating a knowledge base that can be referred to in the future.

Access

Security is extremely important in IT, and it follows that most people won’t have access to the resources they need when joining a new team. Here are a few areas that may require granting of permissions for the new team member:

• Cloud Services (AWS, Azure, Google Cloud)
• Chat platforms and channels (Slack, Email groups)
• Code Source Control (GitHub, GitLab)
• Network Access (VPN)
• Application Access (Admin accounts)
• Shared Documents (Google Drive, Dropbox)

It is also critical to be clear about who is responsible for maintaining this access. A regular audit of who has access to what can avoid potential security breaches.

Contacts

Knowing who to talk to in different situations is very important. A list of key contacts and stakeholders can help streamline the flow of information. You may be able to go back to the source of the handover, but not if you have taken over from someone leaving the organisation. It really helps to have a bit of a safety net in place if possible.

Important points of contact and situations to consider are:

• Business stakeholders – who is the product owner and who is responsible for setting priorities?
• Change management for deployments and updates – include information about the process for notifications and approvals.
• Original developers and devops contacts – this may not always be possible, but you should at least have someone with the required level of system knowledge who can answer questions.
• Escalation points for incidents – who needs to know, and is it time of day dependent?
• Technical Support contacts for on-call rosters – when someone finds a problem, who is the first (and second) point of contact?

Technical Information

This should generally be covered in the Documentation section, but it is worth noting a few specifics. Depending on the maturity of the system, and how it was previously managed, some of these may not be implemented, but probably should be:

• Data backups and restoration procedures.
• The full release and potential rollback process.
• Preferred maintenance windows for high availability systems.
• Out of hours support – the more people who know how to support the system, the less burden is placed on individuals.
• Service level agreements (SLAs).
• Development environment setup – a junior developer should be able to get up and running early, so they can poke around and learn by doing.
• Staging & production environment setup (DevOps) – can the system be built from scratch if required?
• Security audits and patching – automate notifications of potential security issues in dependencies.

But Wait, There’s More!

Onboarding and handover of important systems within an organisation is a tricky but important process. Whilst this post isn’t necessarily a comprehensive list of considerations, it should at least help you on the path to high confidence in being able to handle your job. Then, when the inevitable new problem arises, you’re more likely to have a course of action available to you, or at the very least, somewhere you can go for help. Tailor the process to suit your specific needs, and be sure to regularly review and update it to keep it current.

Good luck!