19 May 20267 min read
Every engagement starts underwater. You pay a full rate for output that is partial, and simultaneously your own people spend time that produces nothing shippable. The engagement becomes worth having at the point where accumulated value overtakes accumulated cost, and that point is a date you can estimate rather than a feeling you eventually have.
Teams that never estimate it make two predictable mistakes: they sign engagements too short to ever clear the ramp, and they judge people during the period when nobody could look good.
What ramp actually consists of
- Access: accounts, repositories, environments, tool seats, VPN, the staging data. Pure waste when it is not ready, and entirely preventable.
- Codebase: how the system is laid out, what the conventions are, which parts are load-bearing and which are abandoned.
- Domain: what the business does, what the words mean, why the odd rule exists that nobody has ever written down.
- Process: how work is specified, reviewed, tested and released, and what the definition of done contains.
- Relationships: who to ask about what, and how much detail that person wants in a question.
Only the first is administrative. The other four are knowledge transfer, and knowledge transfer costs time from the people who hold the knowledge, which is why ramp is expensive on your side as well as theirs.
Modelling break-even without inventing numbers
You do not need precision, you need shape. Here is the arithmetic, using round hypothetical figures chosen because they divide easily and not because they represent any market.
Suppose the engagement costs 10 units a week. Suppose that in week one the work produced is worth 2 units, and that this climbs to a steady 14 units a week by the time context is established. Suppose your own team loses the equivalent of 3 units a week supporting the onboarding, falling to 1 once it settles. Put those four assumptions in a spreadsheet, week by week, with a cumulative column, and read off the week where cumulative value crosses cumulative cost.
Change one assumption at a time and watch the date move. What you learn is not the date, which is fictional, but the sensitivity: for most engagements the break-even point is far more sensitive to how quickly the ramp curve rises than to the rate. That single observation is worth the exercise, and it reorders what you should negotiate.
What shortens the ramp
Almost everything that shortens it is on your side of the table, which is uncomfortable but useful, because it means it is under your control.
- Every credential and environment ready before day one, tested by someone who is not the person granting them.
- A first task chosen deliberately: real, shippable, narrow, touching the parts of the system they will live in, and reviewable in a day.
- A written definition of done, so the first review is a comparison against a checklist rather than a negotiation about taste.
- A named person on your side with time genuinely allocated for questions during overlap hours, rather than a person who has this on top of a full week.
- Documentation that is bad but existing, which beats excellent documentation that is planned.
What lengthens it is the mirror image: access requests that take a fortnight, an undocumented domain guarded by one busy person, a first task so large that nothing is reviewed for three weeks, and a review culture where the standard is unwritten and revealed one comment at a time.
Continuity is a cost term
Every time a person is replaced, the ramp curve resets for that seat, and your side pays the knowledge-transfer cost again. This is why staff turnover at a provider matters commercially and not just sentimentally, and it is why rotating people between clients to smooth utilisation is a saving for the provider that is paid for by the client.
Ask, during selection, how long people typically stay on one engagement, and what happens when someone leaves. The answer is a direct input to your break-even model, because an engagement that resets its ramp twice a year may never clear it.
The economics of a trial period
Trials are sensible and both sides should want one. But a trial measures whatever period it covers, and if that period is entirely inside the ramp, it measures onboarding, not capability. A trial too short reliably produces one of two wrong answers: rejecting someone who was about to become good, or accepting someone on the strength of a well-chosen starter task.
The fix is to define what the trial is for. If it is to test whether the working relationship functions, communication, question quality, responsiveness, honesty about blockers, then two or three weeks is genuinely enough, because those signals appear immediately. If it is to test delivery capability, it needs to run past the point where context stops being the limiting factor.
Reviewing the model once it is real
At the end of the first quarter, replace the assumptions with what happened: what was actually delivered and accepted, how much of your team's time it consumed, and where the curve actually flattened. Keep the file.
That single document turns the next engagement from a guess into an estimate, tells you whether an extension is worth more than a new engagement elsewhere, and answers the question that otherwise gets answered by whoever speaks most confidently in the meeting: is this working, and by how much.