Your first day at a new job should feel exciting and welcoming, not frustrating and isolating. But that’s getting harder to achieve with the rise of remote work. It can be a challenge to get to know people, and if you get stuck, you can’t just turn to the person next to you for help.
Especially in a distributed setting, your onboarding process determines whether a new engineer ramps up quickly — and it even sets the tone for their longterm success. In this article, we’re sharing six tips you can use to build a great onboarding process and make your engineering team more cohesive and productive as a result.
1. Avoid access hurdles
One of the major pitfalls to getting started on day one is not having the right access, permissions, and logins. Solving these problems becomes much harder when your team is distributed, and the IT person may not even be in the same timezone. It’s critical to give a new engineer all the access credentials, instructions, and guides they need before they arrive. Send this info to their personal email address in addition to their corporate one, just in case.
Here are some of the most common access points to consider:
- Email / GSuite
- Project management software
- Wiki
- Slack channels (make sure the default slack channels are set up correctly — it can also be helpful to have a Slack channel specifically for onboarding)
- Git repo & CI/CD pipeline
- Metrics dashboards and logs
2. Make expectations crystal clear
Unclear expectations can be really detrimental, leaving new employees feeling frustrated and discouraged. It’s important to thoughtfully document what you want a new engineer to accomplish in their first day, first week, and first few months on the job.
For example, on the first day, are they expected to attend meetings? Set up their repos and sign up for accounts? Complete their compliance training? Give them a checklist so that they can feel accomplished when they log off. And make sure that they’re meeting with their manager on day 1 or 2 to get the critical context around these expectations.
3. Don’t be shy
Remote teams can be isolating. While an introduction via Slack is a great starting point, it only goes so far toward making personal connections. To lessen the intimidation factor, ask your team to set up one-on-ones (don’t make it the new engineer’s responsibility). The new person should also meet the other stakeholders they’ll interface with often, such as PMs and engineers on collaborating teams.
Injecting a little fun into someone’s first day can break the ice. When we have someone join the team at Cortex, we’ll do a team activity or small social event in the morning right before standup. This gets the new engineer feeling at ease and welcome before their day has officially begun.
4. Give them a small win on day zero
Ideally, new engineers will feel empowered from the moment they start working on the team. At Cortex, we pair new hires with someone experienced in order to release something really small on their very first day.
Even though this will just be a tiny change, it’s a forcing factor for getting their dev environment set up and all of the kinks worked out with their access and permissions. Plus, along the way they’re learning about the repo. And there’s really nothing like shipping code right away to boost an engineer’s confidence and comfort level.
5. Overshare on context
How do you help a new engineer get up to speed fast on a codebase? One way to cover a lot of ground quickly is to hold walkthrough sessions, where 1-2 teammates explain an area of expertise. You might have one session on your high-level architecture, for instance, and another that’s a deep dive on a particular service or library. To get the most out of your team’s time, record and reuse these sessions.
When someone’s new, a lot of the details in these walkthroughs will go over their heads. And that’s ok. The important thing is that now they have a starting point to ask questions. Encourage them to post those questions in the team channel instead of DMing, since there may be multiple people who can help.
6. Create a living hub for docs and resources
If your team is remote and distributed across timezones, your documentation may be the only way to ensure new engineers always have somewhere to turn if they get blocked. Here are some of the resources that can be most essential:
- Employee handbook
- Onboarding document (we recommend making this a template that eng managers can reuse)
- Team process (meetings, Slack channels, ownership)
- DevOps processes
- Setup guides
- Troubleshooting guides
- Logs
- Runbooks
- Dashboards
- On-call rotation
- Service dependencies
Organizing and exposing this information can be a challenge, but it’s critical to onboard new engineers and avoid tribal knowledge.
That’s why we built a Service Catalog to organize the context, links, and docs you need about a service at your fingertips. Cortex integrates with all your tooling and infrastructure to pull the right information into a single pane of glass, and even visualizes service dependencies and SLOs.
With these six practical tips, you can recreate that ideal first day at the office even when your engineering team is spread across the globe. Cortex is designed to help your team collaborate and share knowledge — in addition to deeply understanding and improving your microservices. To give Cortex a try and test out features like our Service Catalog and Scorecards, sign up for a free demo of here.
