Scaling Engineering Teams: Taking the Exprovia Engineering Team from 7 to 20

At 7 engineers an organization runs on shared context. Nobody documents the deploy process because everyone has done it, and questions get answered by turning around. That holds until the constraint stops being skill and becomes capacity: the work the company can take on is bounded by the number of people who can do it, and each additional person costs the existing team time before returning any. I owned that growth from the delivery side at Exprovia - hiring, onboarding, and the mentoring structure underneath both. It ran across my 17 months there: I joined in March 2025 as a web development intern, moved to full-stack developer in May 2025, to associate project manager in August 2025, and to project manager in January 2026. The team I was scaling was the one I had been hired into as its most junior engineer.

This one had no alert to point at. The signal was structural: demand the current team could not absorb, and no mechanism for adding people that did not degrade the people already there. I knew it was real because the cost showed up in the wrong place - senior engineers' calendars filling with the same explanations, delivered ad hoc, to each new arrival. What forced the decision was simple: too little time and too much work. Sprints needed more than one person assigned to the same deadline to hit it, and that pressure was only going to grow.

I looked first at what actually limits how fast a team absorbs people, and it is not the job posting. In a 7-person team the operating knowledge lives in heads: which service fails in which way, why a client environment is configured the way it is, who to ask. Every hire draws that knowledge out through a senior engineer's time. So the real ceiling on hiring speed is context-transfer throughput, and hiring past that ceiling produces a larger team that moves slower.

The tempting shortcut was hiring senior-only to skip the onboarding cost. I ruled it out because it misreads the bottleneck: a senior engineer arrives with skill but without our context, and context is what the transfer is made of. It also concentrates every seat on the scarcest part of the market. Contract augmentation had the same defect in another shape - it rents capacity without accumulating knowledge in the organization, so you pay again for the same context next engagement. Both optimize time-to-seat-filled. The number that mattered was time-to-independent-contributor.

I treated mentoring as part of the senior role rather than a favor, which means I deliberately spent shipping capacity to buy onboarding capacity. In the near term that reads as a loss: the most productive engineers wrote less code so that new engineers reached independence sooner. I also chose the order deliberately: onboarding before a formal hiring pipeline, because the company was not hiring often enough yet for a repeatable pipeline process to be worth building. Both choices trade visible short-term output for slope - a team that absorbs the next hire more cheaply than it absorbed the last.

Onboarding flows came first: a defined path from first day to first contribution, so the answers seniors had been giving ad hoc were given once, in a form that outlived the conversation. Developer mentoring and coaching followed as an ongoing structure rather than a first-week event, because the questions that matter arrive after the first month. A formal hiring pipeline was not part of the build: the company was still small enough that hiring happened case by case, not at the volume that would make a repeatable pipeline process worth the investment. The team scaled from 7 to 20 on the onboarding-and-mentoring structure, built in that order.

Engineering team scaled from 7 to 20. The number is a headcount, and headcount by itself is not an achievement - an organization can add people steadily and get slower doing it. What the structure existed to protect was the rate at which a new engineer becomes independent - so that adding the next engineer did not cost the team more than adding the last.

Onboarding is a system with an owner, not a week on somebody's calendar. The test of an onboarding system is whether it still works when its author is unavailable. The second lesson is that mentoring sits inside the definition of a senior role. Left voluntary, it is the first thing cut - at exactly the point the team is growing fastest and can least afford it. A formal hiring pipeline was never part of this structure, and that was the correct order, not a gap: a pipeline only pays for itself once hiring is happening regularly, and this team was not there yet.