We Grew a Dedicated React Team From 3 to 12 in Singapore — the 7 Handover Rules That Stopped Us Losing 4 Months

Growing a dedicated team is not a recruitment problem. The hard part starts the day people arrive, and the cost lands on exactly the engineers who were productive before. Here are the seven rules we now apply, in order — the first one prevents more damage than the other six combined.

We have taken a dedicated React team from three engineers to twelve twice. The first time it cost roughly four months of output that nobody had budgeted for. The second time, over the same nine-month window, there was no visible dip.

Nothing changed about the quality of the people we hired. What changed is that we stopped treating growth as a recruitment schedule and started treating it as a knowledge transfer problem with a hard capacity limit.

Why teams lose months while adding people

The mechanism is well known and still routinely ignored. Every new engineer consumes senior time before producing anything, and that time comes out of delivery. If the arrival rate exceeds the rate at which the team can absorb questions, throughput falls even as headcount rises.

What surprised us the first time was where the cost landed. It did not land on the new joiners, who were busy and reasonably happy. It landed on the two most experienced engineers, who became a helpdesk, stopped shipping, and — in one case — left within eleven months. The knowledge loss from that departure was larger than everything the five new hires had added.

Rule 1 — Cap the growth rate before you cap anything else

The rule we use: at most one new engineer per two existing engineers per quarter, and never more than three joiners at once regardless of team size.

From three engineers, that permits one joiner in the first quarter, then two, then three — reaching nine by the end of month nine and twelve shortly after. It is slower than a spreadsheet suggests and faster than what actually happened when we ignored it.

The rule frequently conflicts with commercial pressure, and the argument against it is always the same: we need the capacity now. The answer is that hiring four people into a team of four does not produce capacity now; it produces a quarter of near-zero output followed by a team that has forgotten how it used to work.

Rule 2 — Write down decisions, not code

Documentation efforts during scaling almost always aim at the wrong target. Someone proposes documenting the codebase; three weeks later the documentation is wrong, and everyone concludes documentation does not work.

Code is self-documenting in the only sense that matters: it is the authoritative statement of what the system does. What it cannot tell you is why. Why this state management approach and not the obvious alternative. Why this API boundary sits here. Why this piece of code that looks wrong is deliberate and must not be tidied.

A decision record is short — context, options considered, choice, date, half a page at most. Ours are written by whoever made the decision, at the time, and they are the only artefact whose value increases as the team grows. New joiners stop asking the same six questions because the answers exist, and the two senior engineers get their afternoons back.

Rule 3 — Start every joiner on a real defect, paired

The standard onboarding — a week of reading, a starter task in an isolated corner — optimises for the joiner’s comfort and teaches almost nothing about the system.

We now start people on a real defect, in production code, paired with an experienced engineer, on day two. Not a new feature: a defect. A defect forces you to read existing code, follow it, form a hypothesis about a system you do not understand, and be wrong in front of someone who can correct you.

The pairing is what makes it work rather than merely stressful. It is expensive — two engineers on one problem for two or three days — and it is cheaper than three weeks of a new joiner producing plausible code in the wrong shape.

Rule 4 — Make the second hire teach the third

Left alone, all onboarding flows to the same one or two people, and the load compounds exactly when it should be spreading.

The rule is mechanical: whoever joined most recently and has passed three months onboards the next person. Not the most senior engineer — the most recent one.

Two effects, both larger than expected. The recent joiner remembers what was confusing, because they were confused by it eight weeks ago; a five-year veteran has genuinely forgotten. And teaching is the fastest way to consolidate partial knowledge, so the exercise does more for the teacher than for the student.

There is a limit: the recent joiner handles orientation, conventions, tooling and the shape of the codebase. Architecture questions still route to the seniors. But that is maybe a fifth of onboarding time rather than all of it.

Rule 5 — Split ownership before the team feels too big

Everyone knows a team of twelve is too large for one standup. Almost nobody splits at the right moment, because at seven or eight it still feels fine.

It is not fine; it is about to stop being fine, and by the time it obviously is not, the team has already split informally along whatever lines the work happened to create. Splitting deliberately at seven or eight lets you draw the boundary along code ownership rather than accepting one that emerged by accident — and accidental boundaries almost always run through the most contested part of the codebase.

The signal to watch is not headcount. It is the standup: when it runs past fifteen minutes and most people are not listening to most of it, you are late.

Rule 6 — Protect the two people everyone asks

In every growing team, two people end up answering most of the questions. Nobody decides this; it emerges from who is helpful and who happens to know.

Measure it before you manage it. Look at who is mentioned in threads and who reviews the most changes. On our first attempt, two engineers out of eight were involved in roughly seventy per cent of all review conversations. Neither had complained, and both were quietly drowning.

Two protections, both cheap. Give each of them one uninterrupted half-day per week, calendar-blocked and respected. And state explicitly that answering questions is part of their job rather than an interruption to it — because otherwise they measure themselves on shipped features, conclude they are underperforming, and start looking elsewhere.

That second point is not a morale nicety. It is the specific mechanism by which we lost an engineer whose replacement cost more than the whole scaling exercise had saved.

Rule 7 — Watch two numbers and stop when they move

Team growth needs a stop condition, and “we reached the headcount plan” is not one.

The first number is time from opening a pull request to merging it. It measures whether review capacity has kept up with production capacity. When it doubles, you have added producers without adding reviewers, and adding more people makes it worse rather than better.

The second is the proportion of changes touching code the author did not write. Early on this should be high — new people should be everywhere. If it collapses, the team has silently partitioned into private territories, and you now have three small teams pretending to be one.

The three mistakes we made the first time

Hiring to a headcount plan rather than to an absorption rate. The plan said twelve by year end. We hired to the plan, and the plan did not know how many questions four people ask.

Documenting the codebase instead of the decisions. Two weeks of effort, stale within a month, and it convinced the team that documentation was a waste — which made the decision records a harder sell later.

Assuming the senior engineers would say something. They did not. They absorbed it, worked longer, and one of them resigned with a perfectly polite explanation that had nothing to do with the real cause.

The same pattern shows up in other markets with local variations. Colleagues at HireDeveloper.ae find that Dubai teams hit the review-capacity ceiling earlier because of how quickly headcount is approved there, while the team at JapanDev reports that in Tokyo the constraint arrives from the other direction — hiring is slow enough that absorption is rarely the binding limit. If you are still deciding the shape of the product the team will build, our guides on how to build a marketplace app in Singapore and how to build an e-commerce platform cover the scoping decisions that determine how large the team needs to be at all.

Frequently asked questions