Time for some brutal honesty about failure.
During my startup’s final year (before we ran out of runway and shut down), we hired three remote engineers. All three left within 60 days. Not because the company was failing - they quit before the end. They left because our onboarding was a disaster.
I learned more from that failure than from any success. Now, leading design systems at a much healthier company, I’ve helped build an onboarding program that actually works. Here’s what went wrong, and what I learned.
What Went Catastrophically Wrong
Our startup onboarding “process” was basically:
Day 1:
- “Here’s your laptop, here’s GitHub access, here’s Slack”
- “The codebase is in this repo, docs are… somewhere?”
- “Just ask questions if you’re stuck!”
Day 2-60:
- New engineer struggles alone
- Asks questions in Slack, waits hours for answers
- Gets thrown into production bugs immediately
- Has no idea what the product strategy is
- Never meets anyone except their direct manager
- Feels lost, frustrated, isolated
- Quits
We thought we were being “empowering” by giving them autonomy. We were actually being neglectful.
The wake-up call came when Engineer #3 quit and sent me a message: “I learned more about your product from your website than from the two weeks working there. I felt like I was bothering people every time I asked a question. This isn’t what I signed up for.”
That hurt. But it was true.
The Core Mistake: Treating Onboarding as an HR Checklist
I thought onboarding was: Get them access, tell them what to build, done.
What I learned: Remote onboarding is an engineering problem, not an HR checkbox.
When someone joins remotely, they have ZERO context. In an office, they can overhear conversations, see how people work, absorb culture through proximity. Remote? They get none of that unless you design for it.
You’re asking someone to integrate into:
- Your technical systems (codebase, tools, architecture)
- Your team dynamics (who knows what, how decisions get made)
- Your product context (why are we building this, who are our users)
- Your culture and norms (how do we communicate, what’s the vibe)
Doing this remotely requires intentional design. We had zero design.
What Actually Works: The New Approach
At my current company, we’ve built an onboarding program that has 90%+ retention and gets people to full productivity 40% faster. Here’s the structure:
Pre-Day-1 (The Week Before)
- Welcome package shipped to their home (company swag, handwritten note from team)
- Environment setup guide (video walkthrough, not just text docs)
- “Getting to Know Us” video: Team intros, product demo, company values
- Notion page with everything they’ll need Day 1
Goal: They should feel welcomed and prepared, not anxious.
Week 1: Immersion + Connection
- Day 1: Welcome call with whole team (cameras on, everyone introduces themselves)
- Days 1-5: Pair programming every single day with their “onboarding buddy”
- No solo work yet - everything is collaborative
- Meet key people across functions (product, design, customer success)
- Complete structured “treasure hunt” through the codebase
Goal: Build relationships and understand the landscape.
Week 2: First Contribution
- Tackle a “good first issue” (pre-selected, well-documented)
- Submit first PR by end of week
- Heavy code review mentorship (we over-explain everything)
- Start attending team ceremonies (standups, retros)
Goal: Ship something real with heavy support.
Week 3: Growing Independence
- Take on a small feature end-to-end
- Less hand-holding, but buddy still available
- Give their first code review to someone else
- Present work in team demo
Goal: Build confidence and autonomy.
Week 4: Full Team Member
- Join on-call rotation (as shadow first)
- Take on regular work from backlog
- Start mentoring the next new hire
Goal: They’re a contributing team member, not “the new person.”
The Key Elements That Make It Work
1. The Buddy System
Every new hire gets a peer mentor (NOT their manager - a peer). This person is their go-to for everything: technical questions, cultural questions, “is this normal” questions.
We compensate buddies for this (it’s real work). And we train them on how to be good mentors.
2. Async Video Library
We have a library of Loom videos showing:
- How to run the app locally
- How our deploy process works
- Common debugging workflows
- Architecture walkthroughs
New hires can watch these at 2am if they want. No waiting for someone to explain.
3. Progressive Complexity
We don’t throw people into the deep end. First PRs are simple. We gradually increase complexity as confidence grows.
At my failed startup, we gave new engineers our hardest bugs on Day 3. Terrible idea.
4. Daily Feedback Loops
First two weeks, onboarding buddy checks in every single day: “What went well? What was confusing? What do you need?”
We catch problems early instead of discovering someone quit because they were struggling in silence.
The Metrics We Track
- Time to first PR (target: Day 3-5)
- Time to first independent feature (target: Day 14)
- Time to full productivity (target: Day 30)
- 90-day retention (target: 95%+)
- New hire satisfaction score (target: 9+/10)
We hit these targets consistently now. At the startup, we hit none of them.
What I’m Still Figuring Out
Honestly? I don’t have it all figured out:
-
Senior vs Junior: Should onboarding be different for senior engineers? We treat everyone the same now, but I wonder if seniors feel it’s too hand-holdy.
-
Cross-functional onboarding: How much should engineers learn about design and product? We’re trying to increase this but not sure how much is too much.
-
Cultural integration: We’re good at technical onboarding, still learning how to help people feel like they “belong” remotely.
Every person is different. Some need more support, some need more space. We’re learning to adapt.
The Confession
Here’s what I really learned from that startup failure: People don’t quit jobs, they quit feeling lost and unsupported.
Those three engineers who left? They weren’t wrong to leave. We failed them. I failed them. We hired them and then left them to figure it out alone.
Remote work makes isolation the default. Good onboarding is how you fight that. It requires time, intention, and design. We didn’t invest in any of that at the startup.
Now I know better. And our retention numbers show it.
What’s worked for your remote onboarding? What mistakes did you make? I’m still learning.