By Priya Shankar, Head of Product at Glue
Hiring a new developer is expensive. But the real cost is not the recruiting fee or the salary. It is the months of ramp-up before that developer is truly productive. If you want to reduce developer onboarding time, you need to stop thinking about onboarding as orientation and start treating it as a structured path to codebase fluency.
Most engineering organizations accept that it takes 3 to 6 months for a new developer to become fully productive. That timeline has been treated as an inevitability for so long that few teams question it. But a significant chunk of that time is wasted on problems that are solvable.
This post breaks down why onboarding takes so long, identifies the biggest bottleneck most teams overlook, and provides a framework for getting new developers productive in six weeks instead of six months.
Why Onboarding Takes So Long
Developer onboarding is not one problem. It is a collection of problems that stack on top of each other.
Tooling and access setup. Getting a development environment running, obtaining the right permissions, configuring local builds. This should take hours but often takes days. Incomplete or outdated setup documentation is the usual culprit.
Process and culture learning. How does the team work? What are the communication norms? How do PRs get reviewed? What does the deployment process look like? This is important but relatively quick to absorb for experienced developers.
Domain knowledge. Understanding the business, the users, and the problem space. This takes time but follows a predictable learning curve, especially if the company has good product documentation.
Codebase comprehension. This is the big one. Understanding the code: how it is structured, why decisions were made, where the important logic lives, and how systems interact. This is where months disappear.
According to research from Jellyfish, 63% of newly onboarded developers feel they were undertrained for their role. That is not a reflection of their ability. It is a reflection of how poorly most organizations handle knowledge transfer.
The financial stakes are high. Cortex estimates the total cost of onboarding a new developer, including lost productivity during the ramp period, at approximately $240,000. When onboarding drags on for six months, you are paying senior-engineer salaries for junior-level output over a very long window.
The Codebase Problem
Of all the onboarding challenges, codebase comprehension is the least structured and the most time-consuming. And it is the area where most organizations provide the least support.
Think about how a new developer typically learns the codebase today. They read whatever documentation exists (usually incomplete and partially outdated). They look at recent pull requests. They ask teammates questions, lots of questions. They pick up small bug fixes and try to trace the code. They piece things together slowly, through trial and error.
This process depends almost entirely on tribal knowledge: information that lives in people's heads rather than in any accessible system. When the engineer who built a module is available and patient, knowledge transfers. When that engineer is busy, on vacation, or has left the company, the new developer is on their own.
The Stripe Developer Coefficient report found that developers spend an average of 17 hours per week on maintenance tasks, including understanding and working with existing code. For a new developer who lacks context, that number is even higher.
The codebase problem is not that code is inherently hard to understand. It is that the context needed to understand code, the decisions behind it, the relationships between components, the history of how it evolved, is scattered or missing entirely.
6-Week Onboarding Framework
Reducing onboarding from six months to six weeks requires a structured approach that front-loads codebase understanding instead of leaving it to organic discovery. Here is a week-by-week framework.
Week 1: Environment and Orientation Get the development environment running on day one. This means maintaining setup documentation that is tested regularly (ideally automated). Cover team processes, communication tools, and the deployment pipeline. Assign an onboarding buddy who is explicitly allocated time for this role, not just a name on a document.
Week 2: Architecture Overview and Guided Exploration Walk through the system architecture at a high level. Not every service and module, but the major components, how they interact, and where the boundaries are. Pair this with guided code exploration: the buddy walks through two or three key code paths that represent the most common types of work the new developer will do. For best practices on structuring this phase, see our guide on developer onboarding best practices.
Week 3: First Meaningful Contribution The new developer should ship something real by the end of week three. Not a typo fix. A small feature or bug fix that requires understanding a real part of the system. The goal is not the output; it is the learning that happens through doing real work with real code review feedback.
Week 4: Broadening Context Expand beyond the initial area. The developer works on tasks that touch different parts of the system. They attend architecture discussions. They start reviewing other engineers' PRs, which is one of the fastest ways to learn a codebase because you see how others approach problems and receive context through the review comments.
Week 5: Independent Ownership The developer takes ownership of a moderately complex piece of work with less hand-holding. The buddy is still available, but the developer is expected to navigate the codebase more independently, ask targeted questions, and propose solutions before asking for answers.
Week 6: Full Integration By week six, the developer should be operating at a functional level within the team. Not at full velocity, that takes longer, but capable of picking up standard work items, participating in planning, and contributing to code reviews. They have enough context to be dangerous (in a good way).
This framework works because it replaces passive learning with active, structured engagement. Each week builds on the previous one, and there is a clear progression from guided to independent work.
Measuring Onboarding Success
If you do not measure onboarding, you cannot improve it. But what should you measure?
Time to first commit. How quickly does the new developer get code merged? This measures setup efficiency and initial onboarding support. Target: within the first week.
Time to first solo PR. When does the developer submit a pull request without pair programming or heavy guidance? This measures initial codebase familiarity. Target: by week three.
Review participation. When does the developer start reviewing others' code? Active reviewing signals that the developer understands enough of the system to evaluate changes. Target: by week four.
Sprint velocity ramp. Track the developer's story point completion over their first 8-12 weeks relative to team average. You should see a clear upward curve. If velocity plateaus early, that signals an onboarding gap.
Self-reported confidence. Ask the new developer to rate their confidence with the codebase on a simple scale at the end of each week. This subjective measure often surfaces problems that quantitative metrics miss.
For engineering leaders managing multiple teams, onboarding metrics become a window into organizational health. If one team consistently onboards faster than another, there are lessons to transfer. If onboarding times are increasing over time, that may signal growing codebase complexity or knowledge concentration risk.
Glue helps reduce developer onboarding time by giving new engineers an AI-powered way to understand unfamiliar codebases. Instead of relying solely on tribal knowledge and buddy availability, new developers can explore how the system works, understand the reasoning behind architectural decisions, and build context independently. This does not replace human mentorship, but it fills the gaps when the buddy is busy and the documentation is stale.
The six-month onboarding timeline is not inevitable. It is the result of unstructured processes, missing documentation, and over-reliance on tribal knowledge transfer. With a deliberate framework, the right tooling, and consistent measurement, six weeks is an achievable target. Your new hires will be happier. Your existing team will spend less time answering the same questions repeatedly. And your engineering organization will scale without the productivity tax of prolonged ramp-up periods.
FAQ
How long should developer onboarding take?
A reasonable target for full onboarding is 6 to 8 weeks, with the developer making meaningful contributions by week three. The common industry benchmark of 3 to 6 months reflects the reality of unstructured onboarding rather than an inherent requirement. Teams with strong documentation, structured onboarding programs, and tools that aid codebase comprehension consistently onboard faster.
How do you speed up developer onboarding?
Focus on the biggest bottleneck: codebase comprehension. Automate environment setup so it takes hours instead of days. Provide architecture walkthroughs early in the process. Assign dedicated onboarding buddies with protected time. Structure the first six weeks with clear milestones, progressing from guided exploration to independent ownership. Supplement human mentorship with tools that help new developers build context on their own.
What is a reasonable time-to-productivity for new devs?
A new developer should be contributing meaningfully (small features, bug fixes, code reviews) within three weeks and operating at roughly 70-80% of team-average velocity within six to eight weeks. Full productivity, where the developer is as effective as a tenured team member, typically takes three to four months even with strong onboarding. The goal is not to eliminate ramp-up time entirely but to compress the early phases where progress is slowest.