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. [NEEDS INPUT: what forced the hiring decision - signed contract volume, client pipeline, or work the team had to turn down?]

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 held a structured hiring pipeline instead of filling seats on the fastest available candidate. Both choices trade visible short-term output for slope - a team that absorbs the next hire more cheaply than it absorbed the last. [NEEDS INPUT: what share of senior engineers' time was formally allocated to mentoring?]

I built hiring pipelines so evaluating candidates became a repeatable process rather than a series of independent judgment calls made under deadline pressure. Onboarding flows gave 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 ran alongside both as an ongoing structure rather than a first-week event, because the questions that matter arrive after the first month. The team scaled from 7 to 20 on that structure. [NEEDS INPUT: in what order were the pipelines, onboarding flows, and mentoring structure actually built?]

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. [NEEDS INPUT: was time-to-independent-contributor tracked, and did it hold across the growth?] [NEEDS INPUT: retention or attrition rate across the growth from 7 to 20?]

Onboarding is a system with an owner, not a week on somebody's calendar. The test of a hiring pipeline is whether it still works when its author is unavailable. [NEEDS INPUT: are the hiring and onboarding processes documented and run by others now, or still owned by me?] 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.