16 September 20257 min read
Nobody budgets for the ramp. The contract starts on the first of the month, the rate is agreed, and the assumption underneath the plan is that useful work begins that morning. It does not, and the gap between that assumption and reality is where a surprising share of the money goes.
This is not a complaint about outsourcing. A new employee has the same ramp, and usually a longer one. The difference is that nobody expects an employee to be productive in week one, and everybody expects it of someone they are paying by the day. That expectation makes the first two weeks worse, not better.
The ramp is real, and it is not free
Someone joining an unfamiliar codebase has to learn three separate things: how the system works, how your team works, and what you actually want. The first is the fastest, because it is written down in the code. The second and third are almost never written down anywhere, and that is what makes remote onboarding harder than the co-located version.
In an office, the third category leaks. You overhear the argument about the release process, you notice that the person who cares about test coverage sits two desks away, you learn that nobody touches the billing service without asking first. None of that reaches someone working from Beirut unless you put it somewhere deliberately.
Plan for it. A reasonable working assumption for a mid-level engineer joining a system of ordinary complexity is a first week that produces little, a second week that produces something small and real, and a first month that ends with them shipping without supervision on well-understood work. If you have not left room for that, the plan is wrong and the person will pay for it.
Week zero: what should exist before they start
The single highest-return thing you can do is move the boring blockers to before the start date rather than after it. Every hour spent waiting for an account is billed at the same rate as an hour spent writing code.
- Every account created and tested by someone else: repository, CI, ticket tracker, chat, staging, error tracking, whatever else the work touches.
- A README that gets the project running locally, verified in the last month by someone who followed it literally rather than from memory.
- A named person who is responsible for answering their questions, with that responsibility acknowledged out loud rather than assumed.
- A first ticket, chosen in advance, small and genuinely useful.
- The signed paperwork done: contract, IP assignment, and the data processing agreement if they will touch anything personal.
None of this is difficult. It is simply work that only gets done if someone owns it, and it is almost always owned by nobody, which is why the first week so often disappears into access requests.
The first task should be small, real and shippable
The instinct is to start with reading: here is the codebase, spend a few days getting familiar. This is a bad use of a week. Reading a system without a reason to touch it produces a shallow map that evaporates by the following Monday.
Give them something small that goes to production instead. A visible bug fix, a small endpoint, a piece of copy that has to move through the whole pipeline. The point is not the change. The point is that shipping it forces them through every part of your process at once: local setup, branch conventions, review, CI, deployment, and whoever has to approve it. They will find the parts of your process that are broken, because they are the only person in the building who has not already learned to work around them.
Context comes in layers, not in one document
There is a temptation to write the enormous onboarding document. It rarely survives contact with reality, because it is written once, read once, and out of date within a quarter.
A more durable pattern is layered. A short orientation page that explains what the product does, who uses it, and how money reaches the company. A second layer of architecture notes, ideally living next to the code they describe. A third layer that is not a document at all: the habit of putting the reasoning into tickets and pull requests, so the context arrives attached to the work rather than in a folder nobody opens twice.
The third layer is the one that matters over a year. The first two get someone through the first fortnight.
Assign a person, not a team
"Ask in the channel if you get stuck" sounds welcoming and functions as a wall. A new person will not interrupt eight strangers to ask something they suspect is obvious, so they will spend two hours guessing instead, and the guess will be wrong in a way that costs a day in review.
Name one person as the first point of contact for the first month. Tell them it is part of their job, not a favour, and expect it to cost them a few hours a week. That cost is real and it belongs in your calculation of what the engagement costs, alongside the rate.
The overlap in working hours is what makes this cheap. A question asked at eleven and answered at eleven fifteen costs almost nothing. The same question asked into a gap of a working day costs the rest of the day, and after two or three of those, people stop asking. That is the failure you are preventing.
Part of the team, without pretending they are an employee
Two opposite mistakes here, and both are common. The first is keeping the outsourced person structurally separate: their own channel, their own stand-up, their own backlog. They drift, because they are working from a stale version of the plan, and by the time anyone notices, a fortnight of work needs redoing.
The second is pretending the contractual difference does not exist. It does. They are not on your payroll, they may be working with other clients, their notice period is different, and their access should be scoped to what the work requires rather than to everything. Being honest about that is not exclusion, and treating it as taboo just means nobody plans for the end of the engagement.
The workable position is simple: same backlog, same channel, same definition of done, same review standards, same invitation to disagree in a design discussion. Different contract, different access scope, different expectations about permanence. Nobody is confused by this arrangement except managers who have not said it out loud.
What week two should look like
By the end of the second week you want three things to be true: something they wrote is in production, they have asked at least a few questions that were not trivial, and they have found at least one thing about your setup that is wrong. If all three have happened, the onboarding worked and you can stop managing it closely.
If none of them has happened, do not wait for month two to find out why. The most common cause is not capability. It is that nobody made the first task concrete, so the person spent a fortnight reading, being politely available, and waiting to be told what to do.