A 30-60-90 Day Onboarding Checklist That Actually Works
The 30-60-90 day plan is a useful framework that has been turned to mush by overuse. Almost every version you'll find online lists the same vague milestones - "meet the team," "understand the product," "contribute meaningfully." Those aren't milestones, they're aspirations. A new hire who's "met the team" can still be three months in and uncertain about whether they're succeeding.
The version below is the one we use ourselves, structured around concrete deliverables and manager checkpoints. It's opinionated about what should be true at each milestone, which is the whole point - vague plans don't surface problems early, specific ones do.
The principle: each milestone is a deliverable, not a feeling
The most common onboarding failure isn't that new hires don't try hard enough or that managers don't care. It's that nobody can clearly answer "is this person on track?" until month four, by which point recovering from a bad fit is expensive for both sides.
The fix is to define each milestone as a thing that either exists or doesn't. "Has shipped a small change to production by day 14" is a milestone. "Is feeling settled in" is not. The first one tells you something; the second tells you nothing.
Days 1-7: the setup week
The goal of week one is removing every obstacle that would prevent the new hire from doing real work. Not learning the codebase, not understanding the strategy - just operational readiness.
By end of day 1: all accounts provisioned, laptop configured, working calendar visibility into the team's recurring meetings, Slack joined, password manager set up. If any of these slip past day 1, escalate immediately - they're entirely predictable and there's no excuse for them to be unfinished.
By end of day 3: codebase cloned and running locally (or equivalent for non-engineering roles), one walkthrough with their manager covering team mission and the next quarter's priorities, lunch (or virtual coffee) with three different teammates.
By end of day 7: one small, low-risk thing shipped or completed. For an engineer, a typo fix or small bug. For a marketer, a draft blog post or a competitor analysis doc. For a salesperson, a complete read-through of three recent customer calls with notes. The goal is the experience of having produced something useful, on this team, within the first week. The psychological effect of that is enormous.
Manager checkpoint at end of week 1: 30-minute 1:1. Three questions:
- What surprised you, good or bad?
- What's still unclear that you wish were obvious?
- What's blocking you from doing real work next week?
Days 8-30: getting useful
The goal of the first month is to make the new hire functional - not expert, not yet productive at full speed, but able to handle the bread-and-butter work of the role without constant supervision.
Concrete deliverables by day 30:
- At least three things shipped or completed independently (small to medium scope)
- One thing presented or written up for the broader team - a doc, a demo, a session note. This forces externalization of what they've learned.
- A "what I would change after one month" doc - the new hire's perspective on what's confusing, broken, or surprising about your processes. A practice popularized by several remote-first companies - the insights are unrecoverable later, once the new hire normalizes to the existing way of doing things.
- Met 1:1 with at least one peer in every other function they'll need to work with (engineering ↔ design, sales ↔ CS, etc.)
Manager checkpoint at day 30: 1-hour structured review. Not "how are you doing" - actual feedback in both directions. The manager brings:
- Two specific things the new hire is doing well
- One specific thing they need to start doing differently
- An honest take on whether they're on track for the 90-day mark
The new hire brings:
- The "what I would change" doc
- What's energizing them about the role so far
- What they're worried about
Days 31-60: owning something
By the end of month two, the new hire should own at least one piece of recurring work end-to-end. Not just "contribute to" - own it, including the parts that aren't fun.
Examples by role:
- Engineer: Owner of a specific feature area or service. On-call rotation if applicable. Has done at least one code review per week on someone else's work.
- Designer: Lead designer on at least one in-flight project. Has run at least one critique session.
- Marketer: Owner of at least one channel or content stream. Has shipped at least one substantive piece (campaign, post, video) that's gone live.
- Salesperson: Carrying a quota or pipeline target, with weekly forecasting accountability. At least one closed deal or substantially advanced opportunity.
- Product manager: Owner of at least one product area. Has run at least one customer call independently.
The pattern: the new hire is no longer being handed tasks; they're being held accountable for outcomes in a specific domain.
Manager checkpoint at day 60: Same structure as the 30-day review, plus one new question: "What would have to be true for the next 30 days to be your best month here?" This question surfaces missing support, missing access, missing decisions - the things you can still fix before the 90-day mark.
Days 61-90: independent contribution
By day 90, the new hire should be operating as a regular member of the team, not a special case. The visible markers:
- They contribute to team strategy discussions, not just execution. They have an informed opinion about why the team is doing what it's doing.
- Other people on the team route work and questions to them, not just through them.
- They've identified at least one thing the team should stop doing or start doing differently, and have made the case for it.
- They've been on at least one cross-functional initiative as a meaningful contributor.
- Their work product is being shipped without their manager pre-reviewing every piece of it.
None of these are checkbox items. They're observations you make about how the person operates - which is exactly why setting them as explicit milestones is valuable. They make it possible to notice when someone isn't hitting them by day 90, while there's still time to course-correct.
Manager checkpoint at day 90: The most important review of the onboarding sequence. The honest version of this conversation is one of three:
- "You're crushing it. Here's what your next six months look like."
- "You're on track. Here are the two specific areas to focus on next quarter."
- "This isn't working. Here's why, and here's what we'd need to see change in the next 30 days, or we should both reconsider this fit."
The third conversation is the one most managers avoid having, and it's the most important one in the whole framework. Honest 90-day feedback - even when it's hard - is far better for both sides than a 9-month exit that everyone could see coming.
What this whole structure protects against
Three specific failure modes:
Drift. Without milestones, weeks pass and nobody can articulate what changed. A specific deliverable structure forces a weekly question: "Are we still on track for the next milestone, or not?"
The polite four-month conversation. When the first explicit feedback comes at the four-month mark, it's usually because the manager has been hoping the problem would resolve itself. By that point the gap is too big and the time to fix it has passed. Earlier checkpoints prevent this by normalizing direct feedback from week one.
Lost perspective. The new-hire view of your processes is a one-time, expiring asset. The 30-day "what would I change" doc captures it before it's gone. Skip this and you'll never get that perspective back.
The investment in running this kind of structured onboarding is real - probably 5 hours of manager time spread over the first three months, plus the deliberate thinking to define role-specific milestones up front. The cost of not doing it is much higher. New hire mis-fits caught at month nine are commonly estimated by SHRM at 1-3x annual salary in total cost. The 5 hours of structured onboarding is, by any measure, the cheapest insurance you can buy.
Sources & Further Reading
- GitLab Handbook: General onboarding - one of the most extensive public examples
- SHRM: The cost of a bad hire
- Harvard Business Review: Onboarding Isn't Enough
- Will Larson: Onboarding engineers
- GitLab blog: Remote onboarding at scale