Most engineering organisations have not designed developer onboarding. They have outsourced it to whichever senior engineer happens to sit near the new hire.
The new developer eventually becomes productive. But the organisation has not built an onboarding system. It has borrowed one from its most experienced engineers, one question at a time.
Your best engineers are not your onboarding system. They are your most expensive knowledge-transfer mechanism. This piece is about what to do instead.
A new developer joins the team. Someone gives them access to the repository, points them at the documentation, and tells them which senior engineer to ask if they get stuck.
Some months later, the team congratulates itself on how quickly the new developer has ramped up. And in a narrow sense, that is what happened.
But look at what actually happened underneath. The new developer learned the system by asking questions of the people who already understood it. Your senior engineers stopped what they were doing dozens, then hundreds of times, to explain architecture, deployment mechanics, coding conventions, historical decisions, and all the reasoning that never made it into the documentation.
The developer eventually became productive. But the organisation did not build an onboarding system. It borrowed one from its most experienced engineers, one question at a time. Your best engineers are not your onboarding system. They are your most expensive knowledge-transfer mechanism.
Most engineering onboarding, when you diagram it honestly, looks like this: new developer → question → senior engineer → answer → new developer continues.
That is a pattern, not a system. And in most teams, it depends on four fragile things happening in sequence for each of the hundred small questions a new developer has to resolve in their first months, whether the person who knows the answer is available at that moment. Whether the new developer knows enough to ask the right question in the first place. Whether the senior engineer explains the reasoning behind the answer, not just the answer itself. Whether either party remembers to write it down for the next person who arrives with the same question.
In practice, the answer to at least one of those four is usually no. The result is a slow, uneven ramp assembled out of interruptions, most of it never captured, most of it dependent on human availability.
That is not an onboarding system. It is your senior engineers’ calendars being consumed by a knowledge transfer function nobody officially assigned them.
The instinct, when leaders recognise the problem, is to invest in documentation. Documentation helps. It is part of the knowledge base an organisation needs. But it is not the same thing as an onboarding system.
Documentation is a static artefact. An onboarding system is the process that turns the knowledge base into capability, in the head of a specific engineer, in a defined period of time, in a way you can trust.
Good documentation supports onboarding. It does not replace it. The reason most organisations still see six-month ramps despite investing in reference material is that the ramp is not being slowed by missing reference material. It is being slowed by the absence of a structured pathway that inducts a new engineer into the system through progressively harder use of it, with feedback at every step.
Documentation is the raw material. The onboarding system is what turns it into an engineer.
Most training focuses on technical knowledge in the general case. Java. Git. SQL. REST. Cloud fundamentals. Testing patterns. All useful, all necessary.
But a graduate arriving at your team does not need Java. They need your Java. Your deployment model. Your architecture. The specific conventions your team uses, and the ones they have deliberately rejected. The way your codebase actually handles retries, timeouts, and error propagation. What a good implementation of your team’s patterns looks like, in your codebase.
That is contextual knowledge, and it is where the real ramp gap sits. Generic training does not close it. It cannot, by definition; the knowledge is specific to your systems, and the graduate needs it to make sense of the code they will be reading in week two.
Generic training has a place as a foundation. But treating it as an onboarding solution is what leaves the reasoning gap wide open, and that gap is what your senior engineers end up filling in real time.
Most engineering onboarding, however it is structured, has two states: training and real work. A graduate goes through training. The graduate is then dropped into real work, where a senior engineer becomes their default resource.
That gap is where the ramp time gets spent. There is no middle.
A properly engineered onboarding programme fills that middle. It looks something like this:
Each step builds the mental model needed for the next step. Skipping the middle two, going straight from theory to real tickets, is the failure mode that stretches the ramp out to months. The graduate is capable of the last step. They have not been walked through the middle in a way that lets them get there without borrowing senior engineer time.
Most developer onboarding programmes measure the wrong thing. They ask whether the graduate completed the modules, passed the assessment, attended all the sessions. That is the same category error DORA’s engineering-performance research has been flagging for a decade: measuring throughput instead of capability.
Those are throughput metrics for the training programme. None of them tells you whether the engineer coming out of the programme can do work they could not do before.
Better test: what work can they now do that they could not do before?
In practice, three signals tell you whether onboarding has actually landed.
They can explain the reasoning behind their own implementation, not just describe what it does. The senior engineers reviewing their pull requests are commenting on edge cases and design, not teaching them the basics of your patterns. They start spotting problems in other people’s code that a senior would also have spotted.
If those three are happening in the first three months, onboarding is working. If they are not, extending the ramp will not get them there. The programme itself is what needs redesigning.
Engineering leaders often start this conversation by asking how to reduce a six-month ramp to a shorter one. That is the wrong end of the problem.
Time to productivity is an outcome of the onboarding system. It is not the system itself. Trying to compress it directly, without changing the programme underneath, produces one of two failure modes. Either you compress the timeline superficially and end up with graduates who look ready but are not. Or you keep the same programme and accept the same ramp with a bit more discipline about the reporting.
The useful question is not how to reduce the ramp. It is why the graduate needs it in the first place. Which almost always leads back to the diagnosis in the earlier sections that the onboarding system is really a series of senior-engineer interruptions dressed up as a programme.
Address that, and the ramp shortens. Try to address the ramp directly, and you will move the reporting, not the reality.
The punchline of a properly engineered developer onboarding programme is not that new developers become useful faster. That is a symptom. The punchline is that your senior engineers stop being the default answer to every question a new developer has.
Not because their expertise becomes less valuable. Quite the opposite. Because their expertise has been captured, structured, and made reusable so it is available to the whole team in a form that does not require interrupting them.
That is what proper engineering onboarding actually looks like. Not a training module. Not a documentation portal. A system that inherits senior engineers’ reasoning and delivers it to new developers in a shape they can act on.
If your best engineers are still the single point of contact for every new developer’s first-month questions, you do not have an onboarding system. You have an expensive knowledge-transfer arrangement. It is solvable, but it needs to be recognised for what it is before it gets solved.
The instinct at this point is to build more training. Better instinct: build inheritance. The programmes that materially move the ramp are the ones designed to move senior engineers’ reasoning out of their heads and into a shape a graduate can absorb without interrupting them. Every conversation the programme absorbs is a conversation your senior engineers get back.
For more than thirty years, Mallon Associates has built developer onboarding programmes for financial services engineering teams by capturing the reasoning that lives in senior engineers, and structuring it into training the rest of the team can inherit.
Explore Alwyn Tan’s eighteen-year case study to see how the capability developed from his early career at a Tier-1 bank into the wider engineering journey that followed.
Every engagement starts with a conversation.
Talk to us about building an onboarding system rather than borrowing one.
Is asking senior engineers questions not just normal onboarding?
Some of it is unavoidable and useful. The problem is that in most teams the same questions get asked repeatedly across every new hire, and the answer lives only in a senior engineer’s head. That is not knowledge transfer; it is repeated interruption. A well-designed onboarding programme absorbs the repeated questions so senior engineers spend their time on the ones only they can answer.
Documentation is part of the knowledge base an organisation needs. It is not the same thing as an onboarding system. An onboarding system is the process that turns the knowledge base into capability in the head of a specific engineer, in a defined period of time. Good documentation supports it; it does not replace it.
There is no universal answer, and the honest one is that it depends on the technology stack, the team’s onboarding design, and the graduate. Our own observation across financial services engineering environments is that graduate ramps often sit around six months when the ramp is left to informal osmosis, and can compress meaningfully when onboarding is designed around the specific technology stack. That is our practitioner experience rather than an industry benchmark.
Both, and lateral hires often have it worse. They arrive with existing competence and hit the same contextual-knowledge gap silently, more likely to be assumed productive too early, and less likely to ask basic questions because they feel they should already know.
The measurement most engineering leaders care about is delivery output over the graduate’s first year, plus the recovered time of the senior engineers whose calendars used to be consumed by repeated interruption. A graduate who becomes productive earlier contributes more delivery output in year one; the compounding effect across a cohort, combined with the senior time no longer being spent as human documentation, is where the ROI actually sits.
We start by capturing the reasoning that lives in senior engineers, using technical writers whose job is to ask the questions that expose that reasoning. That capture becomes the raw material for structured training built around the systems the graduate will actually be reading. The graduate meets the codebase in the training environment, not an approximation of it, and progresses through a supervised middle stage rather than being dropped from theory directly into real work.
