How long does it take a new engineering team to reach full productivity? The ramp-up cost nobody budgets for

A newly assembled development team takes, on average, anywhere from several weeks to about five months to reach its real delivery pace — not the day it starts writing code, but the day it stops losing time understanding the system, the business, and the very people it has to coordinate with. Available research on professional roles in general puts that stretch at up to 20 weeks (Rollag, Parise & Cross, MIT Sloan Management Review, 2005). For a whole team — not a single person — the same problem repeats, multiplied by every new person who has to be integrated at once.

That ramp-up time almost never shows up in a commercial proposal or a project timeline. It gets paid for in weeks of lower output, code that has to be reviewed twice, and decisions that take longer than expected — not because the team is bad, but because it doesn't know the terrain yet. Most of what's written about this is aimed at HR — onboarding checklists, 30-60-90 day plans — not at the company that has to decide, before signing, which hiring model minimizes that cost.

What exactly is ramp-up time for a development team?

Ramp-up is the time curve between a team joining a project and the moment its output — delivered code, decisions made, problems solved — stops being limited by what it still doesn't know. It has three layers that get learned in parallel, not one: the code (architecture, conventions, inherited technical debt), the business (what problem the system solves, who uses it, what constraints aren't written down anywhere), and the team itself (how each person coordinates, who's good at what, what tacit agreements already exist). A team starting from zero has to solve all three layers at the same time it's already expected to deliver.

How long does it actually take a new team to reach its real pace?

The most cited study on this is by Kevin Rollag, Salvatore Parise, and Rob Cross, published in MIT Sloan Management Review in 2005: they found that time to reach full productivity in a professional role can run up to 20 weeks — nearly five months — and even longer in higher-responsibility roles. That number describes one person joining a team that already works. When what's being assembled is the whole team — several people coordinating with each other for the first time, with nobody on the other side who already knows the terrain — there isn't a single learning curve: there are as many as there are people, overlapping.

Google reached a similar conclusion through a different path. In an internal study by its own People Analytics team, a simple change to the onboarding process — a checklist sent to the manager at exactly the right moment, before the new hire started — cut time to full productivity by a full month, 25% faster than the previous process (Google re:Work, “A data-driven approach to optimizing employee onboarding”). The number matters for what it implies in reverse: if a better-structured process saves a full month, it's because without that structure, ramp-up was already eating that month on its own.

Why doesn't adding people shorten a late project?

The classic answer is Brooks's Law: adding programmers to a software project that's already late makes it later (Fred Brooks, The Mythical Man-Month, 1975). The reason isn't that new people aren't useful — it's that, during the ramp-up stretch, they consume time from the team that's already delivering: someone has to explain the system, review the new arrival's code, answer the same questions more than once. The team's capacity drops before it rises.

Why does the cost grow faster than intuition suggests?

Brooks also lays out the mathematical reason: the number of possible communication channels among n people is n×(n-1)/2. With 5 people there are 10 channels; with 10 people, 45. Every person who joins doesn't just have to learn the project — they also multiply the number of conversations needed to keep everyone aligned. It's the same reason, in a different form, why a team that already knows each other arrives with that problem already solved: the channels already exist, nobody has to open them all again.

Why does this cost almost never show up in a project budget?

Because it doesn't look like a separate line item: it dissolves into the first few sprints, where it gets mistaken for “slow to get going” instead of being named for what it is. Most of what exists on onboarding is written for HR — aimed at a single role joining a structure that already works — not at the question a company actually has to answer before hiring: of the models available for adding development capacity, which one minimizes this specific cost, not the hourly cost?

Does a squad that already worked together still have ramp-up time?

Yes — no amount of shared history eliminates the part of ramp-up that depends on the specific project: that company's specific code, its particular business, its unwritten constraints. Nobody avoids that, not even a team with years together. What a squad that already worked together does eliminate is the other half of the problem: internal coordination. It doesn't have to discover along the way who's good at what, how each person prefers to work, or what happens when someone disagrees — that part is already resolved before the project starts, and it's exactly the part an ad hoc team has to rebuild from zero, even if every individual person is senior.

At Zenit, Kaizen shrinks the other half of ramp-up — the business half, not the team half — by documenting the project's real context before the match: what exists, what's missing, what constraints aren't written down anywhere. The squad still has to learn that company's specific code, but it doesn't start blind, and it isn't rebuilding its own internal coordination at the same time.

Ramp-up time never hits zero — not with the best squad, not with the best onboarding process. But there's a real difference between paying it once, on the business side the team doesn't know yet, and paying it twice: once for the business, and again for a team that doesn't know itself either.