Toolkit

When you hear the term onboarding, you may think about acquainting an employee with a new role or project. But in fact, it’s common in software development to onboard a team of employees onto a software product, such as a suite of digital tools. And just as it’s important for organizations to maintain best practices and norms when onboarding individuals, it’s equally as crucial when onboarding teams onto products. 

At Nava, where we help our government partners build modern digital services that people trust, we often onboard government teams onto new software products. That’s why we spoke to eight internal and external experts—working across state and federal delivery environments—about onboarding best practices. Their recommendations are compiled here, and they can help your organization standardize its process of onboarding teams onto a product. 

Helpful terms: 

Onboarder: This is the team conducting the onboarding. It will often include engineers who can give technical guidance on software products. 

Onboardee: The team that is being onboarded onto a software product. 

Plan for every phase of onboarding

Onboarding generally has three phases—awareness, active onboarding, and ongoing support. How onboarders approach the earlier phases can have a large impact on the level of effort required for later phases. 

Awareness

Awareness has to do with how onboardees learn about the onboarding process and the resources available to help complete it. If you’re onboarding a small group of onboardees, this stage might involve directly engaging with onboardees to make them aware of onboarding. If your project involves a large group of onboardees, you’ll likely need to put more effort into making onboardees aware of onboarding services and giving them access to the necessary tools. 

Pro tip 1: Make sure your onboarding documentation is public so that onboardees in the future can establish a baseline understanding of the process. 

Pro tip 2: You should begin to plan for scaling in this phase. For more information, see the “Plan for scaling early” section.

Active onboarding

This is the phase we often think of when we hear onboarding. In active onboarding, you’ll provide onboardees with documentation, checklists, orientation sessions, and other tools. In order to set the onboardees and onboarders up for success, you should: 

• Create a plan for task management and handling requests.

• Create a plan for protecting the onboarder’s time. 

• Ensure that the onboardees can integrate updates and maintain their code.

Pro tip: It’s helpful to establish a clear definition of when active onboarding is complete. If you don’t, the transition to the next phase can be unclear. 

Ongoing support

Once a team is onboarded onto a software product, the relationship between onboarder and onboardee does not end—the onboardee will need ongoing maintenance and support. Teams in this phase may need to revisit active onboarding periodically, or they may need access to a tool or service they hadn’t requested before.  

Pro tip: Ticketing systems like Jira are great for managing requests from onboardees.  

Throughout the process

During every phase of onboarding, it’s crucial to set up feedback loops so that onboardees can share their successes and pain points with you. This might take the form of surveys or interviews. 

It can also be helpful to define key messages and repeat them throughout the onboarding process. This can help create alignment among onboarders and onboardees. For example, you might distill your talking points into 3-5 value propositions for your software product. This will help your product team ensure their offerings align with your value propositions, and it can help orient onboardees. You could begin each onboarding session by saying, “Our services provide you with A, B, C, and D, and today we are going to talk about B.” This helps onboardees keep track of where they are in the process. 

Decide which onboarding model to follow

There are two main onboarding models—the concierge model, where an individual or team stewards onboardees through the onboarding process, and a self-service model, where onboardees follow documentation to onboard themselves. Most likely, you’ll decide to use a combination of both models. 

Regardless of which model you choose, be wary of proceeding without any model. If you create the onboarding process ad hoc for each new onboardee, it will be more difficult to scale the onboarding process and you may need to perform more maintenance in the future. 

Define your goals

There are two common goals involved in onboarding: 1. To provision teams with a new software product and 2. To ensure that new teams understand and follow best practices. You should determine whether your process seeks to achieve one or both of these goals. Here are some sub-goals you might associate with each goal:

Provisioning a new software product

• The product is being used in production

• The onboardees have the right access to systems

• The onboardees are aware of tools and services available and understand their value

• The onboardees understand how to use the product appropriately

Best Practices

• A gating mechanism is in place to ensure the onboardees follow best practices

• The onboardees have documentation that defines best practices

In addition to defining your goals, you should understand what success looks like for you and your onboardees. For example, you might define success around how quickly the onboardees can complete essential processes or tasks using the software product. Defining success will help you determine when onboarding is complete. 

Plan for scaling by creating a content management plan

Planning to scale your onboarding program early can prevent major issues down the line. A great way to do this is to make a plan for how you’ll manage onboarding documentation. Here are some content management tips to set the program up for success as it scales:

• Establish a shared language and structure among onboarders so that documentation is consistent. Ensure that the shared language and structure align with user needs, and perform usability testing if necessary. 

• Establish norms for the information architecture of documentation.

• Establish 3-5 key user considerations for onboarders to keep in mind as they write documentation. This helps the team focus on meeting onboardees’ needs. 

• If possible, limit edit access to content to avoid unintentional duplication/editing. 

• Establish a regular cadence of updating documentation. 

• Do research into what platform is the best option for you to house documentation. This can prevent having to migrate large amounts of content later on. 

Conclusion

When onboarding teams onto software products, it’s crucial to plan ahead in order to avoid issues down the line. By planning for every phase of onboarding, determining which onboarding style fits the project’s needs, establishing goals, and planning for content management, you’ll be ready to onboard teams and scale the project when the time comes. 

Special thanks to Norah Eldredge, Daniella DeVera, Ed Mullen, Monica Catunda, and Makaela Stephens, who contributed to the research in this article.