Onboarding is one aspect of the employee experience that often gets overlooked, especially for early-stage startups that have no official HR function. Why? Founders care deeply about recruiting the best people, and setting them up for success, so it’s not that onboarding doesn’t matter to them. It’s because of recency bias.
Last week, another group of Startup Engineers joined us at Commit. In 2021, we’re aiming to onboard more than 1000, so this process is something we think a lot about.
People only go through onboarding once, and at that moment, they probably feel the least comfortable taking charge and making major changes to internal company processes. Once they’ve found their footing and developed trust that their opinions will be taken seriously, they barely remember all the friction points and awkward moments of onboarding.
We’ve pulled together a list of best practices for onboarding engineers remotely, compiled from our experiences at Commit. We’ve also solicited thoughts from engineering leaders with best-in-class remote onboarding programs – Simon Stanlake has led engineering teams as CTO at Hootsuite and VP Engineering at Procurify, while Alexandra Sunderland has led engineering teams as Engineering Manager at Fellow.
Make a plan for every day
If you’re reading this post, you’re probably a CTO, founder, VP Eng, or Tech Lead. It’s probably impossible to imagine a time when your calendar wasn’t jam-packed. Flip back in your calendar to the first couple weeks at your company, and you’ll notice there’s likely a lot more blank space and open time.
Even the most motivated and driven new hire has an empty calendar for the first few days. Create a daily plan with scheduled meetings and tasks to help ease your first hire into the flow of work at your company.
At Commit, we schedule twice daily touchpoints with direct managers – 20 minutes to start the morning off connecting as human beings, and 30 minutes at the end of the day to answer questions and address blockers.
Alexandra Sunderland sends an email to new hires before they join with details on who they’ll meet, how to join meetings, and what to expect from the first week. We have an onboarding calendar at Commit that all new hires subscribe to with pre-populated calendar invites.
Simon Stanlake has built an onboarding calendar that pulls from different functional areas. Every new cohort spends an hour with the CTO, VP Product and VP Engineering to ask questions about the product and software, as well as about them as individuals. Engineers also meet leaders in sales, support, and marketing to learn more about the customer, and gain context on the priorities and OKRs of other departments. This calendar is part of an overarching “flight plan” that highlights the role, who new hires need to connect with, what meetings they’ll attend and how they should prepare, overall values and expectations, and what success looks like in the first month and first quarter.
Startups hire self-starters, so don’t feel like you need to schedule every minute. It’s good to give your new hires time to read and digest company material, get pulled into impromptu meetings to learn, and jump on “parking lot” ideas that no one else has had a chance to implement. But make sure you’re scheduling something every day for the first couple weeks.
Assign an onboarding buddy
The newest hire at Fellow is paired up with the second newest hire as their onboarding buddy. This tactic is actually for the second newest hire’s benefit – once you’ve been at a startup for a few weeks, attention on how you’re settling in tends to wane. But a few weeks of experience is still not very much! Having a team building position as an onboarding buddy reinforces that this new-ish hire does have valuable knowledge and is a core part of the startup’s team.
Simon Stanlake built Procurify’s onboarding buddy systems around career development paths. Engineers who have expressed the desire to grow as leaders and managers become onboarding buddies, as this gives them the chance to develop their teaching skills.
Create psychological safety
Your goal for your two-week onboarding period should be to establish trust and create an environment where your newest team member feels comfortable asking questions – not about pulling as many lines of code as possible out of your newest hire.
In a remote workplace, it’s harder to preserve the concept of “struggling together”. In an office, it’s easy to listen in on conversations, overhear a group of engineers or product leaders working on a problem, and this normalizes the work (and not always linear path) of problem solving. In a remote work environment, team members only see what’s in slack and miss the side conversations and zoom calls where problem solving takes place, which can make it easy to feel like no one else is hitting setbacks or having to work around dead ends.
At Fellow, Alexandra Sunderland has instituted a creative rule that flips peer support on its head. When experienced engineers are debugging code or solving a customer problem, they pull in the newest engineering hire to help them solve it, not the most experienced. That new hire realizes that more tenured developers also struggle, and they learn how Fellow approaches problem solving generally, as well as what Fellow-specific systems and queries to use.
When Simon Stanlake is helping prep team leaders for their onboarding talks, he makes sure they’re ready to talk about mistakes they’ve made in their career and in this role. This humanizes them, and reinforces that failure is acceptable when it leads to learning.
Reward early wins
One of the most frustrating parts of joining a new company is the feeling that you’re not contributing. The team at Fellow uses their software (a collaborative platform for team meetings, 1:1s, action items, and notes) to host their onboarding checklist. Rather than putting steps in a wiki, they create a template in Fellow where new hires check off all their onboarding action items (ie. set up your dev environment, get a ticket off Jira, create a PR, merge the PR). This provides a sense of accomplishment beyond just the quantity of code that a new hire is pushing. And as a bonus, this checklist tells managers and onboarding buddies where the new hire is getting stuck without forcing them to be a micromanager.
Simon Stanlake sets a goal of having engineers deploy code on day 1, so every new hire logs off feeling accomplished and with tangible proof that they’ve contributed to their new team.
Learn as you go
The last step of onboarding should always be soliciting feedback on what felt awkward, uncomfortable, or missing. Every new hire comes with their own experiences from prior roles. While onboarding is still fresh, encourage them to be honest and proactive about making the onboarding experience better for everyone who has yet to join.
At Commit, one of our engineers who joined in February (Thomas Choo) dedicated his HOP (a hackathon we host during onboarding to get engineers in a problem-solving mindset) to improve the developer experience when getting set up to contribute to building Commit’s platform. Thomas identified a problem and solved it. Every engineer who’s joined Commit since has had a better experience because of it.
Sarah Marion leads Founder Partnerships at Commit. She’s spent her career collaborating with early stage founders as they solve valuable problems.