How to Onboard Remote Team Members at a Small Agency

Your remote hire starts Monday. You sent them a link to your GitHub repo and a Slack invite. You're ready.

Then they show up. They can't access the database. Nobody told them the team ritual of standup at 10am.

They don't know who to ask about the client password. They're drowning while everyone else thinks they should be ramp ed up by day three.

Remote onboarding is harder than office onboarding because you can't just walk someone over to a senior dev and say "teach them." Everything has to be documented, intentional, and explicit.

This post covers a checklist that ensures remote hires actually get set up properly.

Before They Start

Send a welcome package. Don't wait until day one. A week before they start, send them: Welcome email, first week schedule, list of tools they'll need, company handbook, their manager's phone number.

Set up their workspace. Create their GitHub account. Create their Figma account. Add them to Slack. Create their email. Have all this done before they log in.

Assign a buddy. Pick someone on your team who's good at helping. This person will answer the new hire's questions, check in daily, and make sure they're not stuck. This can't be the CEO - it needs to be someone who has time.

Create an onboarding document. A single document that covers: First week schedule, how to get set up, where all the important information is, who to contact for what. They'll reference this obsessively.

First Day

Warm introduction call. Have their manager (or CEO if you're small) do a 30-minute call. Talk about the role, the team, what success looks like. Make them feel welcome. It's cheesy but it matters.

Slack channel for them. Create a private Slack channel for them and their buddy. Questions, updates, anything goes. This is low-friction communication.

Handbook and culture. Send them your company handbook if you have one. If you don't, write a simple one-pager covering: Company values, how you work, core principles, communication norms.

Async first recording. Record a 15-minute video of a senior person walking through how the team works. Code style, how you handle pull requests, deployment process, communication rhythms. They can rewatch this as needed.

First Week Structure

Day 1: Onboarding focus. No work assignments yet. Just setup. Can they access everything? Do the tools work? Are all the accounts created?

Day 2: Environment setup. Getting their local development environment running. This is usually painful and takes a full day. Have someone available to help.

Day 3: First tiny task. Something so small they can't fail. Fix a typo. Update documentation. Something with a clear definition of done.

Day 4-5: Small feature or bug. Something a bit bigger but still contained. They pair program with their buddy for part of it. They do the rest solo.

End of week: Check-in. How are they feeling? What's confusing? What went well? Make adjustments for week two.

Tool Access Checklist

Before they start working, they need:

Code:

GitHub/GitLab/Bitbucket access
SSH keys configured
Able to pull, branch, and push
Local dev environment running
Able to run tests locally
CI/CD pipeline visible and working

Communication:

Slack access with appropriate channels
Email account set up
Google Meet/Zoom account added
Calendar shared

Docs:

Access to your wiki (Notion, Confluence, etc)
README documentation for projects
Architecture decision records
Team processes and conventions

Operational:

Time tracking access if required
Project management tool (Huddle, Jira, Linear, Asana, etc)
VPN access if needed
Password manager with shared credentials
Client access (if needed for their role)

Training Topics by Day

Day 1:

How to communicate (async vs sync)
Slack norms (channels, response time expectations)
When to ask questions vs Google
Who to contact for what

Day 2:

Codebase walkthrough
Code style and conventions
Pull request process
Deployment process

Day 3:

How the team works (standups, rituals, meetings)
Current projects and priorities
How to read the project management tool
How decisions get made

Day 4:

Product/business overview
Client relationships if applicable
Company financials and goals
Career path and growth expectations

Day 5:

Feedback on first week
Clarify any confusion
Set expectations for week two
Fun team activity if possible

The Buddy System

Assign a buddy who is:

Responsive (they actually answer questions)
Patient (they don't make you feel bad for not knowing)
Detail-oriented (they notice gaps in documentation)
Available (not swamped with their own work)

The buddy's job:

Answer questions for the first two weeks
Do a daily 15-minute check-in call
Pair program on the first real task
Flag any confusion to the manager
Write down questions so the team can improve onboarding for next hire

Documentation That Actually Helps

Your onboarding only works if your documentation is good. Create:

README.md for every project:

What this project does
How to get running locally
Important environment variables
How to run tests
How to deploy
Key architecture decisions
Who to contact if something breaks

Team wiki page:

How code reviews work
How we handle merge conflicts
How we do standups
How we handle outages
Communication norms
Where all the documentation lives

Architecture decision records (ADRs): Document major decisions. "Why did we choose PostgreSQL over MongoDB?" Having this written down prevents the new hire from asking why and wasting a senior person's time.

Common Mistakes

Assuming they know your stack. You use Postgres and Node and Tailwind. They might have used MongoDB and Python and Bootstrap. Don't assume. Teach.

Making them productive too fast. Week one should be setup and learning. Week two should be small tasks. Week three should be first real contribution. Don't expect them to ship code on day two.

Forgetting the culture stuff. Document how you work together. When do people take breaks? How do you handle conflicts? When are people expected online? The work stuff is easy. The culture stuff is what makes remote work feel isolated.

No single source of truth. Information scattered across Slack messages, Wiki pages, Google Docs. Make one canonical document: "Here's where everything you need is."

Buddy too busy to actually buddy. If the buddy is pulled in five directions, they can't help. Explicitly block their calendar for new hire support.

The First Thirty Days

Week 2-3: They should be working on small features independently with async code review. Still asking lots of questions. That's normal.

Week 3-4: They should be shipping features with minimal oversight. Still asking questions but on bigger topics, not small implementation details.

Week 4: Do a full thirty-day check-in. How are they actually doing? What's been hard? What could be better? Listen carefully. Fix the broken parts of your onboarding.

Frequently Asked Questions

How long does onboarding usually take? Four weeks to feel comfortable. Eight weeks to be truly productive. Three months to feel like part of the team.

Should we pair program during onboarding? Yes, but not all the time. Day one task: pair program together. Day three task: they do it with async support. Day five: they do it solo. Mix it.

What if something in onboarding is broken and nobody has fixed it? Document it. Use that documentation to update your onboarding process. Your new hires are doing you a favor by finding the gaps.

Do we need a formal onboarding program? Not formal. But written down. Repeatable. Checked before every new hire starts.

How do we handle time zone differences in onboarding? Record everything. They can watch training videos on their schedule. Schedule overlap time (even if it's just 2-3 hours) for the first two weeks.

What if the hire is struggling? Have a conversation. Is it them, or is it your onboarding? Most struggling new hires are actually struggling because onboarding is bad, not because they're bad.

Should the CEO do the onboarding? Not exclusively. But the CEO should do the welcome call and the thirty-day check-in. It signals that you care about people.

Remote onboarding takes more effort than office onboarding. But if you get it right, remote hires actually ramp faster because everything is documented. Nobody's relying on overhearing things or osmosis.

Everything is explicit. That's an advantage when you set it up well.