Versapay: Digital Payments Mobile Strategy

We used to onboard our new team members the same way as other organizations. Now, we dedicate nearly a full week for onboarding, where every single hour of the day is scheduled and planned towards training. The result of this effort was honestly unbelievable.

How We Onboard Our Remote Engineering and Product Management Team

We used to onboard our new team members the same way as other organizations. We made sure they got their laptop, set up their email, had badge access, talked about benefits, etc. That took about half a day, and the rest was meeting with their team, then they were on their own.

Now, we dedicate nearly a full week for onboarding, where every single hour of the day is scheduled and planned towards training. Instead of throwing our team right into work, we invest in their training. The result of this effort was honestly unbelievable.

The short-term impact was immediately noticeable. Every new team member was ready to go on the fifth day. They had fewer questions and made a bigger impact on project work faster. The longer-term impact was even more substantial. We’ve noticed a stark difference in our team members that were onboarded our old way vs. the new way.

What’s interesting is that at the end of the training, our employees will usually remark about how amazing the onboarding was and how they had little to no onboarding at previous companies.

Here are two quotes that stand out from our new hires who just finished onboarding.

"Honestly, I loved the mix between docs, recorded sessions and meetings. It was great to meet the CEO and have a chance to talk with him about our core beliefs."

"The onboarding was a lot different than my last company, and that’s a good thing. It was great to get a real picture of what we’re building, and the team behind it. I really appreciated how organized and structured the process was from start to finish."

Yes, a little humblebrag there, but I really believe that being intentional about onboarding is the core of our growth.

So, at a high-level, here are our principles.

Every hour of the day should be planned and scheduled before the new hire joins

This means that by the time they open their email for the first time, their calendar is already full.

In this schedule, we cover the following topics:

Workspace logistics and operations onboarding (where most onboarding starts and stops)

 — Provide access to all the tools they’ll be using for communication, productivity, project management, etc. It’s also important that our team sets this up prior to them visiting. All they have to do is log in.

Get to know the culture of the company, and ask questions

 — This is why we created the "Foxbox Way," which is our culture handbook. It details exactly what the culture of our company is. We give them this document and give them a dedicated time on the calendar to discuss what questions they have about our culture and how we operate.

Project management/product management works (video)

 — We run a tight ship on our projects. We don’t like to leave anything up to guessing, and we give each new hire a detailed view on how we manage projects and deliver software, and what we expect from them. We provide them with a pre-recorded video about how it works. We find a video works great in situations where details don’t change much. It makes sure we don’t miss anything in a live onboarding.

 — Every new hire gets a buddy they can ask questions to. Not entirely a novel idea, but we’ve found by actually telling them, "This is your buddy," instead of, “Ask anyone a question, we’re a lovely group of people,” new hires are more likely to speak up and get their questions answered.

 — Facebook used to have a policy where new engineers would make a code commit to their public website on the first day. This allowed their engineers to get familiar with the coding environment, and also make them feel like part of the team on day one. We have a similar concept with our “core app” that is internal to us. We introduce them to the app and have them work on a planned backlog of new features.

Coding standards/pair programming sessions

 — For our engineers, we walk them through our defined coding standards, and also schedule a single pair programming session with one of our developers to get familiar on how we do things.

We used to assume that if our developers worked in an Agile environment, that they were familiar with point estimation, sprint planning, and retros. They usually were, but they weren’t familiar with how we do it, which is the most important.

So, when we put together the calendar, we try not to make any assumptions on their exact knowledge. If we assume, then the new hire might be too afraid to ask simple questions and reveal their lack of knowledge on a topic that everyone assumed they know.

We solve this by putting it on the calendar and "re-training" them on the core of how it works. It’s quick but super effective.

The Culture Handbook is the core of onboarding

A big reason we invested a lot of time in our culture handbook, "

," is because we didn’t want our new hires to guess what our culture is like.

They should know exactly how we communicate, how we talk to our clients, and how we work. They should know the story of how the company was founded and how they fit into our story. Instead of explaining this in a one-on-one meeting, we define everything in a document, and it’s the second meeting of the first day for a new hire.

We schedule the meetings so they get exposure to different team members.

Our CEO, Rob Volk presents the Foxbox Way.

Our Head of Product Management presents the PM onboarding process

And our VP of Engineering presents the engineering onboarding meeting. We also schedule follow-ups with them every day to see how they are feeling. Even though this isn’t necessarily on the calendar, we make sure that we answer any questions during the on-boarding directly.

This process alone has made our team members more productive and effective. I highly recommend that your team creates one as well. Don’t leave your culture up for guessing.

Every person gets a personalized schedule

If they are an engineer, they get the engineering onboarding. If they’re a PM, they get the PM onboarding.

I would estimate that 50% of onboarding is the same across the board, but we make sure the other 50% is unique to their role.

Also, the actual number of days of training depends on the role. Engineers tend to have the longest on-boarding since there are many tools and processes that they need to be familiar with.

But, what we also do is make sure we personalize it to them as well. Even if we hire two engineers with the same background and some role, we will incorporate special meetings we think they could add value to. For example, we had one engineer who likes to write blogs, so we connected him with our marketing team during onboarding to make him feel comfortable pitching blog posts he wants to write or needs assistance in writing.

In Notion, we create a general onboarding document for each role type, but we also create a new onboarding document for each person. That will dictate the calendar invites being sent out.

The question "Have you met Kelsey yet?" should mostly never happen

With our old onboarding process, which was essentially HR/Logistics onboarding, new hires would often only meet people that were on their project. This ultimately meant they didn’t meet a lot of people on our team who were potentially useful resources for them.

So, in some situations, our engineers would have a challenge that they struggled with and didn’t know there was someone in the company who’d already solved that same problem before. This sometimes led to weeks of productivity losses before someone stepped in and said, "Have you met Kelsey yet? She could solve this problem for you in minutes."

During onboarding, we show them our organizational chart, and the breakdown of members per project, even the projects not relevant to them.

One of the main comments with the developers during our 1:1’s is that they are not aware of what is happening on other projects, and so our hope is that by showing them early what everyone else is working on, it will give them more context of where they can be helpful.

We do this to show them where they fit within the organization, but how the rest of the company is laid out. During our monthly town hall meeting, we also make sure that we present our newcomers, and announce them on our #general slack channel.

By being intentional about our onboarding process and scheduling meetings beforehand, we introduced new hires to anyone that had a direct impact on their role, and resources they most likely will need down the road. By setting up a video call with the relevant resources during onboarding week, they were able to establish an early connection.

We recently moved to Notion for our "wiki"-style knowledge base and are absolutely in love with it. Notion is one of the first things we give our new hires access to. It’s a massive upgrade from our ad-hoc Google Docs storing of documents.

The biggest benefit of using Notion is that it’s really easy to find things and link to other documents we’re working on. With the navigation on the left, the new hire gets a complete picture of their onboarding and other things they should be looking at.

They can look at notes from previous town hall meetings, status meetings, etc., right away.

For onboarding, we like to list out each activity per day, as the screenshot shows. Bullet points work great, and we link to any documents or media relevant to their onboarding process. This way, the new hire knows exactly what they need to be doing, with little to no help from our team.

No extra work during onboarding until they "graduate"

We are very careful not to assign them project work, even if the project is waiting for them. We’ve made that mistake in the past, and it’s never turned out to be a good idea. We take our time with onboarding because we know the impact is worth it.

So, if you’re going to create an onboarding process, it makes a lot of sense to protect their time and not overload them with client or project work. Let them onboard, and then put them to work.

The week long onboarding process might seem excessive, but it works phenomenally well

I don’t think we’ll ever look back from this process.

Now that I’ve seen the short-term impacts on employee happiness and the long-term impact on productivity, this onboarding is one of the best decisions we’ve made.

onboarding

1 post tagged with “onboarding”

How We Onboard Our Remote Engineering and Product Management Team