30-60-90 onboarding framework: How we cut remote ramp time by 40%

General
1

Two years ago, I inherited an engineering team at a Fortune 500 financial services company where remote new hires were taking 6 months to reach full productivity. Not kidding—six full months before they could independently own features.

The problem? We had zero onboarding structure. We relied on osmosis, hallway conversations, and “just ask if you have questions.” When we went remote, that model collapsed.

Here’s how we rebuilt onboarding from the ground up and cut ramp time to 3.5 months.

The 30-60-90 Framework

We structured onboarding around clear milestones with explicit success criteria:

Days 1-30: Environment, Culture, First Commits

Goals:

  • Complete dev environment setup
  • Ship first code (even if it’s just documentation updates)
  • Understand team norms and communication patterns
  • Meet cross-functional partners (product, design, QA)

Success criteria:

  • :white_check_mark: All tools installed and configured
  • :white_check_mark: At least 3 merged PRs (can be small fixes, docs, tests)
  • :white_check_mark: Completed “shadowing week” with buddy
  • :white_check_mark: Can explain our deployment process

Support structure:

  • Daily 5-minute check-ins with manager (just “are you blocked?”)
  • Weekly 1:1 with assigned buddy (peer who started 6-12 months ago)
  • Access to async video library covering architecture, tools, team practices

Days 31-60: Feature Ownership, Code Reviews, Architecture

Goals:

  • Own a small-to-medium feature end-to-end
  • Participate actively in code reviews (both giving and receiving)
  • Deep-dive into 2-3 key system components
  • Start attending on-call shadowing

Success criteria:

  • :white_check_mark: Shipped at least one feature independently
  • :white_check_mark: Given substantive code review feedback to teammates
  • :white_check_mark: Can explain architecture of 2-3 core systems
  • :white_check_mark: Completed on-call shadowing rotation

Support structure:

  • Weekly 1:1s with manager (tactical + career development)
  • Bi-weekly 1:1s with buddy (now more peer-to-peer)
  • Assigned “deep-dive” sessions with senior engineers

Days 61-90: Cross-Team Collaboration, On-Call, Mentoring

Goals:

  • Lead a cross-team initiative or feature
  • Take on-call shifts with backup support
  • Start mentoring newer hires
  • Contribute to architecture discussions

Success criteria:

  • :white_check_mark: Led feature involving 2+ teams
  • :white_check_mark: Completed first on-call rotation
  • :white_check_mark: Mentored at least one newer hire
  • :white_check_mark: Proposed architectural improvement or attended architecture review

Support structure:

  • Bi-weekly manager 1:1s (more strategic)
  • Buddy transitions to peer relationship
  • Day 75 skip-level with senior leader

The Key Innovation: Async Video Library + Live Cohorts

We created an async video library that new hires can watch on their own schedule:

  • Architecture walkthroughs (15-20 minutes each): Senior engineers explaining key systems
  • Tool tutorials: How to use our observability stack, CI/CD pipeline, etc.
  • “Day in the life” videos: Different roles showing their typical workflows
  • Troubleshooting guides: Common setup issues and how to fix them

But we pair this with live weekly cohort sessions—all new hires who started the same month meet together with a senior engineer. This creates peer bonding and surfaces common questions.

The Results

  • Ramp time dropped from 6 months to 3.5 months (40% reduction)
  • Retention improved: 88% of new hires stayed 1+ year (vs. 72% before)
  • Unexpected benefit: First-generation college grads and career-switchers reported feeling “set up to succeed” instead of “thrown in the deep end”

The structure actually increased psychological safety. People knew what success looked like at each stage.

What I’m Still Figuring Out

Senior hire adaptation: Some senior engineers (especially from FAANG) chafe at the structure. They want to “just explore.” But our data shows even they ramp faster with the framework. Should we create a “senior track” that’s less prescriptive?

Scaling with growth: When we’re hiring 5+ engineers per month, maintaining the cohort model gets hard. How do you keep this personal at scale?

Measuring success: We use “time to first feature shipped” but it’s imperfect. Feature complexity varies. What metrics actually predict long-term success?

What’s Working For You?

For engineering leaders managing remote teams: What onboarding frameworks have you found effective? Where do you see this breaking down?

2

This framework resonates so deeply with what we built at our EdTech startup. The 30-60-90 structure with explicit success criteria is game-changing for remote teams.

One addition that’s worked incredibly well for us: Reverse mentoring

We add a twist at the 60-day mark—new hires are asked to teach the existing team something new. Could be:

  • A technique from their previous company
  • A new tool or library they discovered
  • A fresh perspective on a problem we’ve been stuck on

This does two things:

  1. Psychological safety boost: New hires feel valuable immediately, not just “learning mode”
  2. Combats groupthink: Fresh eyes see things we’ve normalized

Last quarter, a new engineer from Netflix taught us about chaos engineering. We’d dismissed it as “too advanced” but her explanation made it accessible. Now it’s part of our reliability strategy.

The cohort approach is absolutely critical. We tried 1:1 onboarding and people felt isolated. Cohorts create peer support—new hires Slack each other when stuck before bothering the team. Reduces burden on senior engineers.

My question: How do you adapt this for senior vs. junior hires?

We’ve struggled here. Senior engineers (Staff+) sometimes resist the structure. They’re used to autonomy. But junior engineers need the scaffolding.

We’re experimenting with “Choose Your Own Adventure” onboarding:

  • Core framework is mandatory for everyone (security, compliance, deployment)
  • Technical depth is self-paced based on experience level
  • Senior hires can skip basics but must complete architecture deep-dives

Still iterating on this. Would love to hear how others handle the seniority spectrum.

3

Product leader here, and honestly, the product team could learn from this engineering framework.

Our PM onboarding is similarly chaotic:

  • Read 47 product docs scattered across Notion, Google Docs, and Confluence
  • Sit in on customer calls (but which customers? Why these segments?)
  • “Shadow” other PMs (but what are we looking for?)

New PMs take 3-4 months to ship their first feature. And like you mentioned with engineering, we’re not measuring what matters.

Question: How do you involve cross-functional partners in engineering onboarding?

Our engineers and PMs operate in silos during onboarding. Engineers learn the technical stack. PMs learn the product strategy. They don’t intersect until they’re assigned to work together.

But the best eng-PM partnerships happen when both understand the other’s world.

Suggestion: Joint onboarding sessions for eng + PM cohorts

What if engineers starting in March and PMs starting in March had shared sessions on:

  • Customer pain points and how the product addresses them
  • Technical architecture and why it’s designed this way
  • Business metrics we’re optimizing for
  • How a feature goes from idea → shipped

This could reduce the translation gap that slows down every project.

The 30-60-90 framework is brilliant because it’s teachable. I can take this to our Head of People and say “look, Luis at a Fortune 500 cut ramp time by 40%. Here’s the playbook.”

That’s way more compelling than “we should do better onboarding.”