This is a guest post by Jonathan Siddharth, CEO of Turing. Read more about Jonathan at the bottom of the post, and check out the Turning blog here.
My last company, Rover, would have failed if it weren’t for the fact that we became highly skilled at working with remote distributed talent, or, as I like to call them, boundaryless teams. While our company was based in Palo Alto, the likes of Google, Facebook, Apple and other huge companies were sucking up all the developer talent in the area. We didn’t have the resources or hiring skills to compete.Luckily we learned how to identify, vet, hire, onboard and manage remote engineers and this became one of the keys to our success. After I sold Rover, I realized that there were talented engineers all over the world that could be matched with world class jobs. It became my mission to find these people and help them secure Silicon Valley caliber opportunities no matter where in the world they live.
One of the most critical things we do when helping a company bring a new remote developer into the fold is to help them manage a successful remote onboarding process. In this article I'm going to share our secrets so you can put them to work for your company.
Here’s a Quick Summary
At my company, we boil our onboarding best-practices down to three specific areas:
- Business context: what the company does, what its priorities are when everyone is working, and what it takes to succeed here.
- People context: Make sure your new hire knows whom to talk to about what. That they know who their manager is and have an assigned buddy to help them navigate your company.
- Checkpoints: Establish a check-in and review process that includes reviews at 30, 60, and 90-days to make course corrections and to ensure the onboarding process has been successful.
The Onboarding Process
Once your company has decided to hire remote developers, you must develop a structured process to effectively onboard them, get them ramped up, and make sure they’re well-integrated into your team. At my company, Turing, we specialize in hiring remote engineers and getting them up and running for our clients. To help you make your remote hiring a success, I’m going to share our list of best practices with you.
The Three Dimensions of Successful Remote Onboarding
When I think of onboarding, I look at the process along three primary dimensions. The first is making sure they have the right business context. The second is making sure they have the proper “people context.” And the third is to make sure that you have the right checkpoints in place to verify that the new hire is ramping up at the rate you expect them to.
First, let's talk about the business context. When preparing a company to onboard new software engineers, I want them to provide their new employees with vital information. These include:
- A short description of what the company does and what product they are building
- The mission & core values of the company
- What is the strategy to accomplish this mission
- The high-level quarterly OKRs or goals for the business
- The org chart
- Significant examples of projects and how they connect
Communicating this information makes certain your new additions will have the right kind of business context about what's essential to succeed at your company.
We also make sure that the company sets the right kind of communication expectations concerning time zones. It is imperative to establish working hours, so the entire team is clear about the hours during which the developer will be available and when they will be working. Instituting a working time-zone specific schedule is of the utmost importance when working with remote talent. You want the developer and your team to be calibrated on the time window during which everyone on the engineering team is going to be available and reachable.Red our Ultimate Guide to Team Effectiveness
In terms of the people context, one of the most important things you could share is your company's org chart. You can also use high-level visualizations that show all the different projects in the company. The goal is to convey how those projects are connected, who's driving those projects, and who are the people in those different projects. Giving a developer this high-level spatial awareness of all the different projects that might be going on in a remote company is very important.
During onboarding, we also ask our clients to tell us who are the four people in your company that this new developer has to speak with in the first month to get fully ramped up.
Make sure that the developer has an assigned buddy and knows who that person is. Having a buddy for the first three months is incredibly helpful. A buddy is a person that the developer can ask questions about the company when they don’t know who or where to go to get answers.
It's also helpful for the new person you're bringing on board to know who their manager is. While I realize this should be obvious when someone is remote, this isn’t always the case. It’s good to be explicit by specifically letting the developer know, for example, who will be doing their weekly one-on-one, who makes sure that weekly one-on-ones happen, and how you're going to evaluate their performance.
New engineers should also know when performance reviews will happen. What's the cadence? What's the format? And essentially, the answer to the question, what does it take to succeed as software developers in this organization? You want the person that you're onboarding to have a good idea of what to expect.
And third, in terms of successfully checking how well this person has ramped up, you want to do 30, 60, and 90-day check-ins with the person that you're onboarding. You want to let the person know who will be doing that check-in and what you will evaluate during that point. These check-points give you a valuable opportunity to course-correct in case something hasn't gone according to plan.
Where things go wrong
In our experience, the people dimension is incredibly important and frequently overlooked by companies that haven't yet established robust remote employee onboarding practices. Companies tend to assume that the manager is the one who provides much of this detail. Many times this is news to the manager! I can't emphasize enough how important it is to have an established protocol regarding an onboarding schedule for connecting new employees with the right people on your team.
Bonus: Beyond Basic Onboarding
There’s an orthogonal addition to onboarding, which I didn't even touch upon that I would call legal onboarding in terms of compliance. You’ll save yourself and your company from future headaches if you make sure that any new hire has completed any forms and that you’re aware of any regulations specific to that person or the country where they reside. Also, decide if your company needs any confidentiality or IP assignment agreements. If this expertise is outside the skills within your organization, it’s a good idea to invest in the services of a company that specializes in navigating what can be tricky territory. At Turing, we like remote.com for this service.
As part of our communications onboarding process, we also deal with the somewhat mundane details of provisioning the new hire with all the technology that the team uses. This practice should include setting up the developer's email and ensuring they have access to the company's Github account, Slack channels, Trello, Jira, Google Docs, Zoom, and any other mission-critical software you expect the developer to use as part of their workflow. Think through security, access privileges, mailing lists, and anything else in the company workflow that is needed for developers to operate efficiently.
Another part of setting your new hire up for success includes making sure they know about staff meetings, company-wide meetings that this person has to attend, and critical Slack channel subscriptions. Also, communicate to your developer what your company culture looks like and what’s unique about your company. By making sure that all these types of nuts and bolts are tight enough, your new hire will be more confident in their interactions with their team, and they’ll integrate more fully into your company from day one.
One of the biggest challenges you’ll typically face is developing and maintaining company culture when a large portion of your company is remote. Perhaps the best method to be sure people understand your culture is to make it clear what your company’s core values are. For example, a Turing, we have three core values. The first is to move fast. The second is continuous improvement. And the third is a relentless focus on long-term customer success.
- Know your company's core values and make sure you communicate them clearly to the person that you're onboarding.
Finally, it’s crucial to make sure that any new hire has access to all the tools they need and that they’re confident in their use of those tools. It doesn’t hurt to check to verify that your new hire is familiar with the tools you use and to train them if they’re not. If your company requires a very high degree of proficiency using specific tools for certain positions, be sure to demand and vet for that skill before making an important hire.
Turing’s Onboarding Checklist:
We believe in a rigorous and regimented approach to onboarding. That’s why we use a well-developed checklist to make sure that we always adhere to our best practices. Here’s our process.
- Name / Website
- What does the company do?
- Company description and key objectives
- Usual working hours / TimeZone?
- 8 AM - 5 PM MST
- # of employees (all local or some remote?)
- Local = ?
- Remore = 4
- What’s the company’s main business focus right now? Key goals/OKRs to share?
- 4-5 weeks out to an open beta test
- Complete product.
- Company Org chart (key people/stakeholders related to what you are working on)
- Name - Founder / CEO
- Name - CTO
- Name - Fullstack Dev
- Name - Intern
- Who is your manager?
- Who is your Onboarding Buddy (the go-to person for questions, help, etc.)
- Other key people you’ll be interacting with:
- Name - tasks and as a resource
- Name - UX
- Name - if no one else is available
Product Development Overview
- Technology stack
- Main communication? Email/ Slack?
- Main project mgmt? JIRA/Trello? Other?
- Other tools must download/use?
- Google Calendar
- Any mailing lists should def be added to?
- Any slack channels dev should be added to?
- Meeting cadence?
- Is there a daily standup? Live/text/other?
- Zoom - 15 minutes
- Other key recurring meetings?
- Sprint Planning?
- Other (i.e., all-hands, etc.)?
- 2 Week Trial Period Expectations?
- Sprint Planning?
- Expected overlap hours
- 8 AM - 2 PM MST / 3 PM - 9 PM WAT
- Goals for the first three days
- Look into source code
- Getting acquainted
- Reviewing UI and SASS
- Goals for the end of first 2-weeks
- What are other ways the developer can become involved in the company?
Onboarding Checklist (check off if done during the call)
** Add in any other things that need to be provided to the Developer, or list from client’s custom onboarding notes **
- Project Mgmt
- Added to all needed mailing lists, slack channels, etc.
- 1:1 setup with a manager - Thursday @ 9 AM MST
- Name of the first contact
- Phone number
- Name of the second contact
- Phone Number
- Name of the third contact
- Phone number
I hope you find this article helpful!
About Jonathan Siddharth
Jonathan is the CEO and Co-Founder of Turing.com. Turing is an automated platform that lets companies "push a button" to hire and manage remote developers. Turing uses data science to automatically source, vet, match, and manage remote developers from all over the world. Turing has 160K developers on the platform from almost every country in the world. Turing's mission is to help every remote-first tech company build boundaryless teams.
Before starting Turing, Jonathan was an Entrepreneur in Residence at Foundation Capital. Following the successful sale of his first AI company, Rover, that he co-founded while still at Stanford. In his spare time, Jonathan likes helping early-stage entrepreneurs build and scale companies. Follow him on twitter @jonsidd.