Before Day 1: Pre-Onboarding Checklist

The most common onboarding failure: the developer shows up on Day 1 and can’t do anything because the access isn’t ready. This is a management failure, not a developer failure, and it immediately signals to the developer that the company is disorganised.

Access to set up before Day 1:

• GitHub/GitLab organisation access with appropriate repository permissions
• Slack/Teams invite with channels they need (dev, product, general — not every channel)
• Jira/Linear access with the current sprint board visible
• Figma access for design files (view access minimum)
• Staging/development environment credentials and setup instructions
• Company email if you’re using Google Workspace or Microsoft 365
• Any cloud platform access (AWS/GCP/Azure console, limited permissions)

Documentation to send before Day 1:

• Architecture overview (even a rough diagram beats no diagram)
• Tech stack document: what technologies, what versions, what patterns are used
• Local development setup instructions — these should be so clear that anyone can follow them
• Code style guide / ESLint config / linting rules
• Definition of done for tickets
• Team norms: meeting schedule, async communication expectations, response time norms

Week 1: Context, Access, and First Contribution

Day 1 agenda (synchronous — schedule a video call):

1. Welcome and introductions (15 min) — who does what, team culture, how the product serves users
2. Product walkthrough (20 min) — demo the product as a user would experience it
3. Architecture walkthrough (30 min) — explain the system design, key components, data flows
4. Open questions (15 min) — let the developer ask everything they want to know
5. First ticket briefing (15 min) — assign a small, well-defined starter task

The first ticket strategy: The first ticket should be small (4–8 hours), well-specified, and genuinely useful — not a “get familiar with the codebase” task. Examples: fix a minor UI bug, add a small UI component, write a missing test for an existing function. The goal is a merged PR by day 5. This gives the developer a confidence-building win and gives you a preview of their work style.

What NOT to do in Week 1: Don’t assign the developer to a major feature immediately. Don’t expect full velocity. Don’t wait until Week 2 for the first 1:1. Don’t leave them with no one to ask questions.

Days 8–30: Ramp-Up and First Real Ownership

By Day 10, the developer should understand the codebase well enough to navigate independently. By Day 20, they should own at least one ticket from start to finish — from reading the spec, to implementation, to tests, to PR review, to deployment. By Day 30, they should be contributing at approximately 50–60% of the velocity you’d expect from a fully ramped developer.

Structure for this period:

• Bi-weekly 30-minute 1:1 with their primary manager — not a status update, but a conversation about blockers, learning, and how they’re finding the work
• Code reviews should be detailed in this period — detailed review comments are a teaching tool, not criticism
• Include them in design discussions and planning sessions — context that develops from being in the room is irreplaceable
• Set explicit expectations: “By Day 30, I expect you to be able to take any ticket from our sprint backlog and execute it independently”

Days 31–90: Full Velocity and Performance Review

By Day 60, a good developer should be fully ramped — taking tickets independently, contributing to code reviews, raising architectural concerns, and proactively asking questions rather than waiting for direction. By Day 90, they should be contributing to planning.

The 90-day review: Schedule a formal 30-minute performance review at Day 90. Topics: what has gone well, what has been challenging, what the developer needs from you to improve, and mutual goal-setting for the next 6 months. This is also the moment to address any concerns before they compound.

The 7 Onboarding Mistakes That Destroy Early Performance

1. No documentation. “Just explore the codebase” wastes 2 weeks of a developer’s time that could be spent building. Document the architecture before you hire.
2. Broken local dev setup. If setup instructions haven’t been tested in 6 months, they probably don’t work. Test them before Day 1.
3. No dedicated contact for questions. Remote developers need someone they can ask questions without feeling like they’re bothering the whole team. Designate a buddy.
4. Overwhelm with too many tools at once. Introduce tools incrementally — first the code and deployment, then the project management, then the communication channels. Not everything on Day 1.
5. No clear deliverable for the first week. “Get familiar with everything” is not a goal. Assign a specific, achievable first ticket.
6. Skipping the product walkthrough. Developers who understand the product build better solutions. A 20-minute product demo on Day 1 improves code quality for months.
7. No 30-day check-in. Problems in the first 30 days are fixable if caught early. Left unaddressed, they compound into performance issues that result in replacement.

Async Onboarding: Making It Work Across Timezones

When your developer is in a different timezone, synchronous onboarding must be designed around the overlap window rather than assumed. Practical adjustments:

• Record the Day 1 walkthrough videos (product demo, architecture tour) and send them the night before so the developer can watch before your first live call — maximising the quality of your overlap time
• Use Loom for architectural explanations — a recorded walkthrough is referenceable forever
• Over-document decisions: write in Notion/Confluence why architectural choices were made, not just what they are
• Establish an explicit async check-in rhythm: end-of-day Slack update from the developer summarising what was done, what’s blocked, what’s planned for tomorrow
• Make the first 1:1 a video call regardless of timezone — text-only communication in the first week is insufficient for building the working relationship