The 30-60-90-120 Day Engineering Ramp-Up Model
Most offshore engineering ramps fail in a specific and avoidable way: they have no end. The team shadows, contributes to tickets, gradually takes on more, and eighteen months later still routes every consequential decision onshore. Nobody decided this would happen. It happened because no date was ever set on which something would change hands.
A ramp model fixes that by making each stage bounded, with a defined exit condition and a named transfer at the end. The specific windows matter less than the fact that they close. What follows is a four stage model that works for a small senior team, with what to expect and what to measure in each.
The most important element is at day 120: a real system, transferred on a named date, with the approval gate removed. Everything before it exists to make that transfer safe.
Key points
- The purpose of a ramp is to reach a transfer, not to reach competence
- Each stage needs a defined exit condition, or it will extend indefinitely
- Measure readiness in the first 30 days, not output
- The 120 day transfer should be scheduled before the team starts
- Escalation rate is the metric that tells you whether the ramp is real
Days 1 to 30: environment, context and the first contribution
The first month is about removing obstacles, not producing output. The most common failure in this window is entirely logistical: access, environments, credentials and tooling arrive late, and the team spends three weeks unable to run the system it was hired to work on. This is avoidable and it costs a disproportionate amount, because it also sets the tone for how seriously the arrangement is taken.
The goal by day 30 is narrow and concrete: every engineer can build, run and test the system locally, has shipped at least one small change to production, and understands what the product does and who uses it. That last item is routinely skipped in favour of technical onboarding, and it is the one that determines whether the team can make good decisions later.
Do not measure delivery in this window. Measuring output at day 30 produces a team optimising for visible activity at exactly the point when it should be building understanding.
- Every engineer can build, run and test the system independently
- At least one production change shipped per engineer
- Product context delivered: what it does, who uses it, what matters to them
- Escalation path and decision boundary explained and written down
- Named onshore counterpart identified for each engineer
Days 31 to 60: real work, supervised
The second month is the first real test. The team takes on genuine roadmap work with review, and the objective is to discover where its judgement is sound and where it is not. That requires giving it work with enough ambiguity to reveal the difference.
The mistake here is assigning work that is too well specified. A team given precise instructions will complete them successfully and teach you nothing about whether it can be trusted with more. Give it problems with a stated outcome and an open approach, then review the approach rather than only the result.
By day 60 you should be able to name specific areas where the team decides well and specific areas where it does not. If you cannot, the work was too prescribed and the ramp has not actually started.
Days 61 to 90: reducing the review
The third month is where authority begins to move, deliberately and visibly. Review intensity should decrease in the areas identified as strong at day 60, and stay in place where it is not. Doing this explicitly matters more than doing it gradually, because the team needs to know that the boundary has moved.
This is the window where escalation rate should start falling, and it is the first point at which the metric means anything. If escalation is flat through month three, something structural is wrong: usually the review was never actually reduced, or the team was not given work with enough ambiguity to need to decide anything.
The other purpose of this window is to expose the team to failure conditions. Incidents, production issues and things going wrong are where judgement is genuinely formed, and a team that has never handled an incident cannot be handed ownership responsibly.
Days 91 to 120: the transfer
The fourth month exists for one purpose, which is to complete a transfer that was scheduled before the team started. A real system, a named date, and the removal of the onshore approval gate.
Choosing the system matters. It should be consequential enough that ownership means something and contained enough that a mistake is recoverable. Transferring something trivial teaches everyone that the transfer was symbolic; transferring something critical too early creates an incident that sets the arrangement back two quarters.
Removing the approval gate is the part most often quietly skipped. Transferring responsibility while retaining sign off gives the team accountability without authority, which is worse than the previous arrangement because it now owns outcomes it cannot control.
| Window | Objective | What to measure | Failure signal |
|---|---|---|---|
| Days 1 to 30 | Environment, context, first change | Readiness milestones only | Access and environments still incomplete |
| Days 31 to 60 | Real work under review | Where judgement is sound | Work too specified to reveal anything |
| Days 61 to 90 | Reduce review, expose to failure | Escalation rate begins falling | Escalation flat; review never actually reduced |
| Days 91 to 120 | Transfer a real system | Transfer completed, gate removed | Transfer slips or gate retained |
| Beyond 120 | Widen ownership | Escalation trend, systems owned | Ownership count static after two quarters |
The failure signal column is the useful part. Each one is visible at the boundary, which is the point at which it is still cheap to correct.
What each window should look like in practice
The chart below shows the shape to expect. Output rises slowly and then accelerates; escalation stays high and then falls sharply once authority moves. A ramp where output rises but escalation does not fall is producing a productive team that will never own anything.
Contribution to steady state output by window
Planning assumption rather than measured research. A senior heavy team with a lead already in place typically runs faster; complex regulated domains run slower.
The failure modes at each boundary
Ramps rarely fail catastrophically. They fail by extension, where each stage runs slightly long, no boundary is enforced, and after a year the team is competent, productive and still not trusted with a decision.
- Day 30: environments still incomplete, which means the ramp has not started and the clock should be reset honestly rather than absorbed
- Day 60: all work was too specified to reveal judgement, so you have learned nothing about readiness
- Day 90: review intensity unchanged, usually because nobody was willing to be the person who reduced it
- Day 120: transfer date slips, and once it slips without a new date it will slip again
- Day 120: transfer completed but the approval gate retained, which is the most common and most damaging outcome
- Beyond 120: ownership count static for two quarters, meaning the transfer programme stopped
Adapting the model
The windows are a default rather than a rule. What must be preserved is that each stage has an exit condition and that a transfer is scheduled before the team starts.
Senior heavy team, lead already in place
A team where the lead was hired first and the seniority mix is heavy can compress to roughly 90 days, because judgement is present from the start.
Mixed team, new domain
The full 120 days, which is the right default for most first teams in a new domain.
Regulated or safety critical domain
Extend to 150 or 180 days, but extend the windows explicitly rather than allowing them to drift. An extended plan is fine; an undefined one is not.
Schedule the transfer first
Whatever the length, put the transfer date in the plan before the team starts. This single decision separates ramps that end from ramps that do not.
A ramp without a transfer date is not a ramp,It is an indefinite onboarding, and it will continue for as long as nobody forces the question. Pick the system and the date before the first engineer starts, and treat slipping it as a decision that requires a new date rather than as a delay.
Frequently asked questions
Is 120 days realistic for a new offshore team?
For a small senior team with the lead hired first, yes, and some compress to 90. For a larger mixed team in a complex domain, 150 to 180 days is more realistic. What matters is that the plan is explicit rather than that it is short.
What should we measure in the first 30 days?
Readiness only: environment access, build and test capability, product context delivered, first production change shipped. Measuring delivery output in this window produces activity theatre and tells you nothing about whether the team will be able to own anything.
What if the team is not ready at day 120?
Set a new date and name what has to change, rather than allowing the transfer to become indefinite. A transfer that slips once with a clear reason and a new date is normal. A transfer that slips without a new date will not happen.
How do we choose the system to transfer?
Consequential enough that ownership is meaningful, contained enough that a mistake is recoverable. Something with real users and real consequences but not the highest risk system you run. Transferring something trivial signals that the transfer is symbolic.
Should the onshore team keep review rights after transfer?
Not as an approval gate. Advisory review and consultation are healthy; a gate that can block a change is not a transfer. Retaining the gate gives the team accountability without authority, which is a worse position than before.
What is the single best predictor of a successful ramp?
Whether the pod lead was hired first. A team whose lead arrived last is a group of individuals selected by someone who will not work with them, and it takes considerably longer to become a team that can own anything.
How does escalation rate behave during a ramp?
It stays high through the first two months, which is correct, and should begin falling in month three as review is reduced. If it is still flat at day 90, the review intensity was never actually lowered, and that needs addressing before the transfer.
Does the model work for a team of three or four people?
Yes, and it usually runs faster. Small senior teams reach the transfer point sooner because there is less coordination overhead and judgement is concentrated. The stages and exit conditions remain the same; only the elapsed time compresses.
Sources & further reading
- NASSCOM — https://nasscom.in/
- Deloitte — https://www.deloitte.com/
- McKinsey & Company — https://www.mckinsey.com/
- Everest Group — https://www.everestgrp.com/
Ramp with a plan, not a hope
Hexominds runs a structured 30-60-90-120 day ramp with named transfer dates, so a new team owns something real by month four.