We’ve all been there.
New badge. New laptop. New Slack channels. New faces in a gallery of tiny squares. And somewhere in your inbox or HR portal: your Onboarding Plan.
On paper, the purpose of that plan is straightforward:
“Enable you to get started with the real work as soon as possible, so you can start delivering the results expected from you.”
In reality, the quality of that experience varies wildly.
I’ve seen onboarding plans that last two weeks, others that stretch to three months, and a lot that hover around that one-month mark. I’ve also seen everything from world-class, thoughtful onboarding experiences to completely chaotic, copy-pasted plans that feel like someone dumped a wiki on your head and wished you good luck.
And right in the middle of this mess sits a key character: the Onboarding Buddy.
This article is about both: the onboarding plan and the buddy, and how they can either set you up for a strong, compounding career… or quietly sabotage you before you ever get a fair shot.
1. What Onboarding Is Supposed to Do
In theory, onboarding is simple.
You join a company. Over a defined period—two weeks, a month, maybe longer—you:
Learn essential company policies and processes: HR, payroll, benefits, and internal tools.
Learn how the company thinks about security, compliance, and privacy.
Get access to the systems, apps, repos, and environments you need.
Meet key people:
Your manager and skip-level.
Your team and stakeholders.
Partners in other orgs you’ll depend on.
Get introduced to your technical domain:
The network, infra, or services you’ll be responsible for.
The tools, dashboards, and automation pipelines in use.
The on-call model, incident process, and standards.
At the end of the onboarding window, the idea is that you’re:
Set up technically (laptop, VPN, repos, tools).
Clear on expectations (what good looks like in this role).
Safe to start doing real work without causing damage.
From that point on, the company treats you, rightly or wrongly, more like a “regular” engineer than “the new hire.”
Layered on top of all this is the probation period, usually around 3 to 6 months. This is the window when:
The company evaluates if they made the right hiring decision.
You evaluate if you made the right choice joining them.
Onboarding is supposed to be your runway into that period, not a random sequence of meetings you sleepwalk through.
That’s the theory.
2. How Onboarding Actually Goes Wrong (All the Fuck-Ups You’ve Seen)
In practice, onboarding often fails in predictable, painful ways.
Let’s walk through some of them.
2.1 Generic plans that don’t fit your reality
Many companies build one-size-fits-all onboarding plans:
Same checklist for the backend engineer, the network engineer, and the UX designer.
Same videos, same docs, same mandatory training.
Maybe a couple of team-specific meetings stapled at the end.
They’re often:
Outdated: pointing to wikis no one maintains, tools no one uses anymore.
Overly generic: lots of “our values” and almost no “how we actually operate this network.”
Incomplete: nothing about the actual systems you’ll own, the architecture, or the real “gotchas” in production.
You finish your onboarding, tick all the boxes, and still don’t know:
How config changes are rolled out.
What the incident process really looks like at 3 AM.
Where the real source-of-truth is (and what’s just tribal knowledge).
2.2 Onboarding buddies who don’t have time, or don’t care
In a good world, your Onboarding Buddy is:
Your main point of contact for anything related to onboarding.
The person who walks you through how things are actually done.
The one who helps translate “docs” into “reality.”
In the real world, I’ve seen buddies who:
Are overloaded with their own projects and on-call.
Weren’t asked if they have capacity; just voluntold.
Don’t see mentorship as part of their job.
Show up to one or two meetings and then vanish.
You end up in a weird place:
Officially, you have a buddy.
Practically, you’re alone.
This completely defeats the purpose of a buddy in the first place.
Let me say this bluntly:
If you are not willing to dedicate time to truly helping the new hire with things like explaining things in real detail, sharing resources, shadowing their first tasks, and ensuring they’re safe and effective, you should decline the assignment as an onboarding buddy. Period. And don't be an idiot!
It’s better to say “no” than to do it badly and quietly damage someone’s ramps and confidence.
2.3 Tenure and skill ≠ good onboarding
Companies often assign buddies based on:
Tenure: “They’ve been here for years; they’ll know everything.”
Seniority: “They’re a principal; they’ll be perfect.”
Skillset: “They know the tech stack well; that’s what matters.”
But being:
Senior,
Tenured,
Highly skilled,
does not automatically make you good at enabling a new hire.
I’ve seen brilliant people:
Overwhelm new hires with details and no structure.
Skip crucial basics because “that’s obvious.”
Fail to explain why things are done a certain way.
Provide zero psychological safety for questions.
The result: the new hire is technically impressed but practically lost.
2.4 Access and tooling hell
Another classic onboarding failure: you can’t actually do anything.
You spend weeks:
Waiting for VPN access, admin rights, or jump host credentials.
Filing tickets for access to monitoring tools, config management systems, and repos.
Getting blocked by approvals from teams you’ve never met.
You sit in “intro meetings” while:
Your accounts aren’t ready.
Your dev environment doesn’t build.
Your lab access is still “in progress.”
Meanwhile, the clock is ticking:
Your onboarding plan is ending.
Your manager is starting to ask, “So what are you working on?”
The probation period is silently counting down.
2.5 No clear definition of success
Too often, onboarding plans focus on activities rather than outcomes.
You complete:
27 trainings
18 meetings
5 shadow sessions
But no one can answer:
“What should you be able to do independently by the end of onboarding?”
“How will we know onboarding was successful?”
“What will you be judged on in the first 3–6 months?”
So you finish your onboarding plan with a certificate and no clear idea of what you’re expected to deliver.
That’s how you end up with:
New hires surprised by negative feedback at mid-probation.
Managers frustrated that “they’re not moving fast enough.”
Quiet resentment on both sides.
2.6 Remote and hybrid onboarding magnifies everything
All of these issues become worse in remote/hybrid setups:
You can’t “bump into” your buddy or manager.
You can’t overhear useful context in the office.
Every question feels like an interruption in someone’s calendar.
If the onboarding plan is weak and the buddy is absent, remote new hires quickly slide into:
Isolation.
Impostor syndrome.
Fear of asking “too many questions.”
And that leads to a dangerous behavior: pretending you understand more than you do, just to avoid bothering people, which is how mistakes slip into production.
Onboarding is often treated as administrative overhead. That’s a mistake.
3.1 For the new hire’s career
Those first few months:
Shape how people perceive you for years.
Establish your reputation: “sharp and proactive” vs “slow and unsure.”
Create or erode your confidence.
If onboarding is weak:
You start behind.
You struggle to deliver meaningful work early.
You feel like you’re always catching up.
And remember: there’s usually a probation period, often ~6 months.
After your onboarding plan concludes, usually after a month, the company will start evaluating you like any other engineer. You’re “one of us” now.
You’ll be expected to:
Deliver results.
Own tasks.
Show impact.
If you weren’t properly enabled, if your onboarding plan and buddy failed you, that evaluation may say more about the company’s process than about your actual potential. But your career doesn’t care: a failed probation is still a scar you have to explain.
3.2 For the business
Bad onboarding hurts the company too:
Longer ramp times to productivity.
Higher attrition within the first year (“this place is chaos, I’m out”).
Increased risk of incidents caused by poorly supported new hires.
Managers wasting cycles on re-explaining basics that should be documented and embedded in onboarding.
Damaged employer brand: word travels fast in engineering communities.
Onboarding is one of the highest-leverage processes in any technical org. Done well, it creates a pipeline of effective engineers. Poorly done, it burns time, money, and people.
4. When Onboarding Goes Right: What “Good” Looks Like
Now, the positive side: when companies take onboarding seriously, the difference is night and day.
Good onboarding usually includes:
A role-specific plan:
Not just “company 101,” but “here’s how we operate networks here.”
Clear modules: architecture, workflows, tools, on-call, and incident handling.
A first 30/60/90-day roadmap:
“By day 30, you should be able to do X with guidance.”
“By day 60, you should be contributing to Y.”
“By day 90, you should be independently owning Z.”
Solid documentation:
Updated wikis and runbooks, curated for new hires.
“Read this first” paths instead of dumping the whole knowledge base.
A present, engaged buddy:
Someone who has time reserved for you.
Regular check-ins, not just “ping me if you need anything.”
Guided tours of systems and code, not endless slide decks.
Real, scoped starter projects:
Small but meaningful tasks that touch the real stack.
Shadowing on changes and incidents before flying solo.
Early wins that build confidence and trust.
When this happens:
New hires ramp quickly and safely.
Teams feel the benefit of an extra engineer, not the burden.
Managers get signal early about fit and strengths.
The culture signals: “We invest in our people.”
5. The Onboarding Buddy: If You Can’t Do It Right, Don’t Do It
Let’s talk directly to buddies for a second.
If you are asked to be an onboarding buddy, understand what you’re signing up for:
You are not a passive “name on a slide.”
You are not just there for social niceties.
You are the main interface between the new hire and how the job actually works.
That means:
You explain systems patiently, with context.
You share docs, diagrams, and your own notes.
You invite the new hire to shadow you:
Watching you troubleshoot.
Watching you deploy changes.
Watching you navigate internal processes.
You review their early work and give real and honest feedback.
You help them avoid landmines:
Dangerous commands.
Sensitive systems.
Political pitfalls.
If you can’t or won’t do those things because:
You’re overloaded, or
You don’t enjoy mentoring, or
You simply don’t want to invest the time,
Then you should decline the buddy assignment!
That’s not selfish. It’s honest and much better than faking it and leaving the new hire unsupported.
6. For New Hires: How to Survive (and Win) Despite Imperfect Onboarding
Now, let’s talk to you, the new hire.
You cannot fully control the quality of the onboarding plan or your buddy. But you can control how you move through it.
Here’s the mindset:
“Even if everything isn’t perfect, I will extract as much value as possible from this window, so that when onboarding ends, I’m as ready as I can be.”
Some practical moves:
Own your learning path.
Don’t just passively follow the checklist.
Ask: “What do I need to be able to do by the end of this month?”
Backward-plan: what do I need to read, see, and practice to get there?
Make your buddy work for you (politely).
Propose structured sessions:
“Can we walk through the architecture?”
“Can we review a recent incident together?”
“Can I shadow you for a change you’re making?”
Come prepared with questions; don’t show up empty.
Take notes as your life depends on it.
Build your own “New Hire Handbook”: links, commands, gotchas, diagrams.
You’ll need it later, and it’s a seed for better docs for the next person.
Push for real tasks early.
Ask your manager: “What’s a small, real thing I can own in the next 2–3 weeks?”
It doesn’t have to be glamorous; it has to be real.
Clarify expectations explicitly.
Ask in plain language:
“How will my performance be evaluated after onboarding?”
“What would ‘meeting expectations’ look like by month 3?”
Watch for gaps and name them.
If you’re missing access, ask early and often.
If docs are outdated, say so and propose updates.
Remember: once onboarding ends, the company will treat you almost like a tenured engineer. They won’t always calibrate for the fact that you’re still new. The probation clock is ticking.
Your job is to leave as few gaps as possible behind you.
7. For Managers and Organizations: Build Onboarding Like It Matters (Because It Does)
If you’re a manager, team lead, or someone who influences onboarding, here’s the hard truth:
The quality of your onboarding is one of the clearest signals of your engineering culture.
If you want high-performing teams and strong careers, invest here.
Some actionable ideas:
Design role-specific onboarding plans.
Base them on real tasks and outcomes, not just generic corporate content.
Include architecture, workflows, tools, on-call, and incident management.
Define clear milestones for 30/60/90 days.
Coordinate with your new hires:
“By day 30, you should be comfortable doing A with guidance.”
“By day 60, you should own B.”
“By day 90, you should be independently driving C.”
Choose buddies intentionally.
Don’t assign buddies solely on tenure or seniority.
Pick people who:
Can explain.
Care about mentoring.
Have bandwidth.
Recognize and reward good buddies; it’s real work.
Time-box and protect buddy time.
Make “onboarding buddy” a recognized deliverable, not invisible extra work.
Adjust workloads accordingly.
Continuously improve the onboarding content.
After each new hire:
Ask: “What was missing? What was outdated? What was confusing?”
Update the docs and checklists.
Treat onboarding as a product, with feedback loops.
Connect onboarding to probation fairly.
If onboarding was weak, own that in performance discussions.
Don’t penalize new hires for gaps they were never given a chance to fill.
Done well, onboarding becomes a competitive advantage: new hires ramp fast, feel supported, and start delivering value without burning out or causing accidental harm.
8. Closing: Onboarding Is the First Real Test
Onboarding is not just an HR process. It’s the first real test of:
How seriously a company takes its people.
How disciplined an engineering culture is.
How much a team respects the reality of learning curves.
For you, as a new hire, it’s your first test too.
You won’t learn everything in a month. You won’t receive perfect information. You won’t have every question answered with the depth you’d like.
But you can decide to treat onboarding as your project, not just something happening to you.
Because once that plan ends, the company will look at you not as “the new person” but as “our engineer.” Your probation period will continue, and people will start judging you by the impact you have.
If you move through onboarding deliberately, pushing for clarity, seeking real work, documenting what you learn, and making good use of your buddy, you give yourself the best chance to impress when it counts.
And if you’re on the other side, manager, buddy, team, it’s on you to ensure that the new engineer doesn’t fail because you didn’t give them a fair runway.
Bad onboarding wastes careers and money.
Great onboarding compounds talent and trust.
You’ve “been there, done that.” The next time you’re involved in onboarding, on either side of the table, make sure you do it like it actually matters.
Because it does.
Leonardo Furtado