How Long Until a New Engineer Is Productive? What the Ramp-Up Data Says and How to Cut It
New-hire ramp-up can be measured. DX data puts time to a tenth merged pull request between 33 and 91 days depending on the dataset and group, and Gallup finds only 12% of employees strongly agree their organization onboards well. Here is what the numbers say, what to prepare before day one, and how to cut the time.
How Long Does a New Engineer Take to Become Productive?
Longer than most plans assume, and it can be measured. DX, a developer analytics vendor, analyzed data from six multinational enterprises and found that new hires who used AI tools daily reached their tenth merged pull request in 49 days, against 91 days for peers who did not use AI. A later DX analysis put the average time to tenth pull request at 33 days across its dataset of 400 companies, down from 39 days in the fourth quarter of 2025.
Read these as a vendor measuring its own customers, and treat the tenth pull request as one yardstick, not a verdict. The useful point is that ramp-up is a number: you can record it for your own team and compare the next hire against it.
Key Takeaways
- Time to tenth merged pull request: 49 days with daily AI use against 91 days without, at six enterprises (DX, September 2025)
- Average time to tenth pull request across DX's dataset: 33 days in April 2026, down from 39 days in the fourth quarter of 2025
- These are vendor-measured and one yardstick among several
Why Is Onboarding Usually Poor?
Gallup reports that only 12% of employees strongly agree their organization does a great job onboarding new employees. The figure is for the general workforce, not engineers, but anyone who has joined a team and waited days for repository access will recognize the pattern.
Four practical things decide how fast an engineer gets going: access to the repository, tracker and environments, a working local setup, enough domain context to read the code, and a first task small enough to finish. Each one has an owner on your side, and each one is usually decided late.
What Should You Prepare Before Day One?
Do the preparation before the engineer starts, because every item you leave open is a day of idle time. Engineers can typically start within one to two weeks of first contact; a full team usually takes two to four weeks. The earlier the start, the more the checklist below matters, because there is less time to improvise.
| Item | What to have ready | Done when |
|---|---|---|
| Counterpart | One named person with allocated hours for questions and review | That person has the time blocked in their calendar |
| Access | Repository, tracker, chat, CI and staging accounts, with the owner of each named | You have logged in as the new user and each login works |
| Local setup | A written setup guide and a script or container where possible | Someone has run it on a clean machine and it builds |
| Domain context | A one-page glossary and an architecture tour | A new reader can explain the core flow back to you |
| First tasks | Three small, real tasks with clear acceptance criteria | Each task is estimated at no more than a few days |
| Definition of done | Review rules, test expectations and release steps | They are written down and linked from the tracker |
What Should the First Four Weeks Look Like?
Keep the sequence simple. In the first week, give domain context before code: an architecture tour, the definition of done, and a first small pull request. In the second week, review the size and turnaround of that first change, hold a short daily check on what is blocking the engineer, and agree the criteria for judging the first stretch in writing.
In weeks three and four, the engineer should own a meaningful task from start to finish. Close the month with a written review against the criteria you set. Our first 30 days onboarding playbook covers the narrative in detail, and the nearshore ramp-up timeline covers the stretch from contract to first sprint.
Is the Tenth Pull Request a Fair Yardstick?
It is a convenient one, not a complete one. Pull request counts reward small changes and can be gamed, and they say nothing about whether the right work got done. Use them alongside other signals.
Better to track a small set: time to first merged pull request, review turnaround on the new engineer's changes, the size of those changes, and whether the engineer can finish a task without a rescue. Record the same numbers for each new hire so the comparison is fair.
Key Takeaways
- Time to first merged pull request
- Review turnaround on the new engineer's changes
- Pull request size and rework
- Whether tasks finish without rescue from a senior engineer
How Does a Two-Week Paid Trial Help De-Risk Ramp-Up?
A trial turns the first stretch into a decision with a deadline. StepTo runs a two-week paid trial before the 3-month minimum of its staff augmentation starts, and a developer who is not the right fit is replaced free within 30 days. See the staff augmentation page and the engagement process for the terms.
The trial is only useful if you set success criteria in writing on day one: which tasks, what quality bar, what review turnaround. Without them, the trial ends in an opinion instead of a decision.
Which Metrics Should You Track in Month One?
Pick four and record them weekly. Time to first merged pull request, review turnaround, the number of unplanned questions that blocked work, and the share of tasks finished against the estimate. If a number is flat after two weeks, the cause is usually in the checklist above rather than in the engineer.
If you would like this checklist applied to your own repository and team, send us the stack and the start date on our contact page and we will walk through it with you.
What Is the Cheapest Way to Cut Ramp-Up Time?
Prepare before the engineer arrives. Access, a working local setup, a named counterpart and three small first tasks remove most of the idle time, and written trial criteria turn the first two weeks into a clear decision. Record the same few numbers for every new hire and you will know your own ramp-up time instead of a vendor's average.
Building a team in Eastern Europe?
StepTo builds dedicated nearshore engineering teams in Belgrade, Serbia. Engineers start in 2-4 weeks, with a two-week paid trial and from $4,500 per developer per month.
