Developer Onboarding: A 90-Day Guide to Getting New Engineers Productive (and Keeping Them)

You spent months finding the right developer. You ran the hiring process, checked the references, and made the offer. Then they show up on day one, and most companies treat that day like the finish line.

It’s the opposite.

Developer onboarding is where you find out whether the hire you made was real. A great engineer dropped into a bad onboarding process looks like a mediocre engineer for a long time, sometimes long enough that you start to doubt the hire. A good process gets that same person writing useful code in days and owning real work in weeks. The gap between those two outcomes is mostly you, not them.

I’ve onboarded hundreds of developers in the Philippines over the years at Full Scale, most of them people I’d never met in person, working from a different time zone. That’s the hardest version of this problem, and it taught me the thing most onboarding guides miss. Onboarding is not a checklist problem. It’s a communication and integration problem. The checklist matters, and I’ll give you a full 90-day one below, but the checklist is the easy part. This guide covers both: the practical mechanics of getting someone set up, and the part that actually decides whether they stay.

Why developer onboarding decides whether the hire was worth it

Most teams underrate this, and the data backs that up. Gallup found that only 12% of employees strongly agree their company does a good job onboarding new people. Almost everyone is bad at it, which means doing it well is one of the cheapest competitive advantages available to you.

The payoff is real on both sides. Brandon Hall Group research found that a strong onboarding process improves new-hire retention by 82% and productivity by more than 70%. The cost of the alternative is just as concrete. The Society for Human Resource Management (SHRM) estimates it costs six to nine months of someone’s salary to replace them, and a big share of turnover happens in the first months on the job, before anyone has gotten value out of the hire.

For developers the stakes run higher, because the ramp is longer. Cutting that ramp time is one of the clearest ways to improve developer productivity. A senior engineer doesn’t understand your codebase, your architecture, or your weird deployment quirks on day one no matter how good they are. Every week they spend confused is a week of their salary spent on negative output, plus the time your senior people lose pulling them along. Get onboarding wrong and you pay for the hire twice: once in lost ramp time, and again when they leave because the first ninety days felt like being dropped in the ocean.

There’s a cheaper version of this mistake that I see all the time. Companies hire the cheapest developer they can find, hand them no real onboarding, and act surprised when the person disappears mid-sprint. I call that cheapshoring, and onboarding is exactly where it falls apart. A developer with no context and no support has no reason to stick around, so they don’t.

The three things onboarding actually has to integrate

A new developer has to get good at three different things, and they move at different speeds.

The first is the practical layer: payroll, benefits, equipment, accounts, security access, the employee handbook. This is the administrative setup, and it usually wraps up inside the first week. It’s the part everyone remembers to do because it’s the most visible.

The second is the technical layer: the codebase, the architecture, the build and deploy pipeline, the tools, the conventions your team follows that aren’t written down anywhere. This is the longest of the three. Depending on how complex your system is, real technical fluency can take a few months, which is why the 90-day plan below spends most of its energy here.

The third is the cultural layer: how your team actually works, who to ask about what, when to speak up, how decisions get made. This one is invisible and it’s the one teams skip, especially with remote hires. It’s also the one that decides whether someone feels like part of the team or like an outsider running someone else’s errands. That cultural layer is also how you keep an offshore team engaged well past the first 90 days.

Here’s a reframe that changes the math, especially if you’re hiring through a partner. When you bring on a developer through a staff augmentation model, the practical layer is handled for you. Payroll, benefits, equipment, HR, and the legal employment relationship sit with the partner. That frees you to spend your energy on the two layers that actually decide whether the engagement works: technical integration and cultural integration. The developer joins your team and your process, and you get to focus on making them a real contributor instead of chasing a laptop shipment.

Preboarding: the week before day one

The best onboarding starts before the new developer’s first morning. The week before someone joins is the cheapest time to remove friction, and almost nobody uses it.

On my podcast, Yoni Kozminski, CEO of MultiplyMii, made a point that stuck with me: define the role and its responsibilities before the person ever starts, not after. If you can’t write down what success looks like for this person at thirty, sixty, and ninety days, you’re not ready to onboard them yet. Sort that out first.

Then handle the setup so day one isn’t wasted on IT tickets. A good preboarding week covers three things:

• Hardware and access. Order the machine early. Request every account and permission the developer will need (source control, cloud, monitoring, communication tools) so it’s live on day one, not day five. Configure VPN and two-factor before they log in.
• A documentation package. Send a short architecture overview, a tech stack map with versions, the coding standards, and a guide to how the team communicates. Keep it tight. A two-page overview that gets read beats a fifty-page wiki that doesn’t.
• A day-one plan. Schedule the first day’s meetings in advance and send the calendar invites. A quick fifteen-minute call a day or two before the start date to confirm everything works removes most first-morning panic.

The 90-day developer onboarding plan

Ninety days is the right window to think in. It’s long enough for someone to become genuinely productive and short enough to hold yourself accountable. Here’s the structure I’d run, broken into four phases that each build on the last.

Days 1 to 10: foundation

The goal of the first two weeks is momentum, not output. You want the new developer to commit something small and real fast, because the first commit breaks the fear of touching the system.

Start day one with a real welcome, not a pile of forms. Walk them through the codebase with a tech lead, then hand them a small, pre-selected bug or a documentation fix so they ship a pull request in the first few days. Spend days two and three on the architecture: how the services talk to each other, where the data lives, how a change gets to production. Days four and five go to the local environment, so they can build and run everything themselves.

For the back half of the first two weeks, pair them with a senior developer for a couple of hours a day. Pair programming is the fastest way to move the unwritten knowledge in your senior people’s heads into a new hire’s. The milestone for day ten is simple: a first real feature contribution merged.

Days 11 to 30: integration

Now the new developer shifts from learning to contributing. Hand them one well-defined, low-risk feature to own end to end, from branch to merged pull request. Owning something real teaches your quality standards faster than any document can.

This is also the right time to show them the rest of the org. A short rotation through the front-end, back-end, and infrastructure work helps them understand how their code affects everyone else, and it breaks down the silos that slow teams down. By the end of the first month, a healthy new hire is shipping small features with light supervision and starting to know who’s who.

Days 31 to 60: acceleration

Month two is where an assisted developer becomes an independent one. Expect them to handle a medium-complexity feature on their own, start giving code reviews instead of only receiving them, and join design discussions. They won’t be at full speed yet, and that’s fine. The point is that the training wheels come off.

Keep a real feedback loop going. A weekly one-on-one that covers progress, blockers, and what’s coming is enough, as long as it actually happens. Most onboarding problems in month two are quiet ones, a developer stuck on something they’re embarrassed to ask about, and a standing conversation is how you catch them.

Days 61 to 90: autonomy

By the final month, the new developer should be contributing at close to full capacity, owning a component or service, and leading a feature from design through deployment. A strong signal that onboarding worked is that they start teaching: updating the docs they found confusing, writing a guide, helping the next person who joins. People who teach what they just learned lock it in, and they make your onboarding better for the next hire.

Onboarding a remote or offshore developer (the part everyone gets wrong)

Everything above gets harder when the developer is remote, and harder still when they’re in another country and you’ve never met them. This is the version of onboarding I’ve spent my career on, so here’s where most companies go wrong.

They treat it as a tooling problem and reach for faster provisioning, a slicker internal platform, and quicker access. Those things help, but they’re not what breaks. Software development is about communication more than anything else, and onboarding a distributed developer is mostly a communication and knowledge-transfer exercise. If the knowledge in your senior engineers’ heads can’t reach a new person eight time zones away, no platform saves you.

The worst failure mode in offshore onboarding is the middleman. A lot of offshore firms put a “technical project manager” between you and the actual developers. Every question routes through that one person, and the engineers writing your code hide behind them. You never build a relationship with the people doing the work, and they never feel like they’re on your team, so the first time things get hard, they’re gone.

The fix is to onboard the developer directly onto your team, the same as a local hire. My favorite example is AMC Theatres. The developers we placed with them in the Philippines are treated as full AMC engineers, not contractors held at arm’s length. There’s no middleman in the way, and those developers care about the product the way the in-house team does. That only happens because they were integrated as real teammates from the start.

A few things make remote onboarding work in practice:

• Protect overlap hours. You don’t need a full day of overlap, but you need a few real hours when everyone is online together for standups, pairing, and the quick questions that would take a day to resolve over async messages.
• Make knowledge findable. On my podcast, Greg DeVore, CEO of ScreenSteps and author of Find and Follow, told me that “documentation that gets used gets updated”. The trick is to separate the foundational knowledge a developer needs to understand the system from the step-by-step procedures they follow to do a task, and to write the procedures so they’re used daily. Tribal knowledge that lives only in people’s heads is the single biggest drag on remote onboarding.
• Be deliberate about culture. A remote developer won’t absorb your team’s culture by osmosis the way someone in an office might. You have to build it on purpose. At Full Scale we run a team development program so our distributed teams actually know each other as people, which is what makes them comfortable enough to speak up.

That last point is really about the first of the three skills I think decide a developer’s career now: communication, curiosity, and courage, which I wrote about in Product Driven. Onboarding is the first test of communication, and a developer who’s afraid to say “I don’t understand this” in week one will stay quiet for months. Your job is to make speaking up the easy choice.

The metrics that tell you it’s working

You can’t manage onboarding you don’t measure, so pick a few milestones and track them. These are the ones I’d watch.

Milestone	Target	What it tells you
First commit	~Day 3	They can build, run, and ship through your pipeline
First feature merged	~Day 15	They understand the workflow and your standards
Independent feature	~Day 45	They can work without a senior holding their hand
Full contribution	~Day 90	The hire is paying off

Track code review cycles and bug rates too, so speed doesn’t come at the cost of quality. But don’t let the early metrics fool you into thinking the job is done at day ninety.

The real scoreboard for onboarding is whether the developer is still there, and still good, a year later.

That’s the number I care about most. Our developer retention at Full Scale runs over 93%, in a country where outsourcing and call-center attrition is among the highest of any industry. That retention isn’t an accident or a perk. It’s the compounding result of onboarding people well, integrating them as real teammates, and protecting them from the burnout that pushes good engineers out. Onboarding is where retention is won or lost, and most companies don’t realize they’re playing that game until they’ve already lost it.

How Full Scale onboards developers

This is the model we’ve built the whole company around. When you hire a developer through Full Scale, we handle the entire practical layer: payroll, benefits, equipment, HR, and the legal employment relationship in the Philippines. The Philippines is the third-largest English-speaking country in the world, and our teams communicate with no language barrier, which removes the friction that sinks most offshore onboarding before it starts.

What we don’t do is stand between you and your developers. They join your team, your standups, your codebase, and your process, and you direct their work the same way you would a local hire. A dedicated client success manager helps keep the relationship and the integration healthy, which is a big part of why that retention number holds. The result is a team that feels like your own, not a vendor you have to manage through a middleman. Our developers are also trained on the Product Driven approach and the modern AI toolset, so they show up ready to contribute, not just to take tickets. If you want the longer version of how we think about building these teams, our dedicated development team guide goes deeper.

Done right, onboarding stops being a cost you absorb and becomes the thing that turns a good hire into a long-term member of your team.

Onboard a pre-vetted developer in the Philippines