Why Your Engineering Team Can't Scale
16 March 2026
The default response to a delivery problem in most growing businesses is to hire more engineers. More hands, more output. On paper it makes sense but in practice, it rarely works the way leadership expects and in some cases, it makes the underlying problem considerably worse before anyone realises what has actually gone wrong.
Scaling an engineering team is one of the most misunderstood challenges a growing business faces. The issue almost never comes down to headcount alone. What slows delivery tends to be invisible until the pressure of growth forces it into the open, by which point the cost of fixing it is significantly higher than it would have been six months earlier.
When a business is growing quickly and product delivery starts to slow, the instinct is understandable. The team looks stretched, the roadmap is falling behind, and the obvious lever to pull is recruitment. But adding engineers to a system that is already struggling with complexity, unclear ownership or poor processes does not add capacity in any meaningful way, it adds noise.
New joiners take time to become productive. They ask questions that pull senior engineers away from their own work. They inherit codebases they do not yet understand and make decisions that compound existing problems rather than solve them. In the short term, a team of twenty that is well-structured and working cleanly will consistently out deliver a team of thirty that is not.
Darren Spence, formerly CRO at Smartbox.ai and now Group MD at Northamber, made a version of this point about his own commercial teams throughout his career. When he took over a distressed business that had been struggling under the weight of its own complexity, the answer was not to throw more resource at the problem.
"I don't think anything we did was rocket science. It was just looking through the different aspects of the business and finding some quick wins and some sensible ways of working. I always took a lot of inspiration from Steve Jobs and his whole thing about keeping business simple." - Darren Spence, Group MD, Northamber
The same principle applies directly to engineering. Simplifying what the team is working on, who owns what, and how work moves through the system will release more productive capacity than almost any volume of new hires.
The real bottlenecks in most engineering organisations are structural rather than numerical. Teams that are growing quickly tend to accumulate complexity at a faster rate than they can manage it. Codebases develop without clear owners. Systems that were built for one stage of the business are asked to serve a much larger and more demanding version of it. Release processes that worked at twenty engineers start to buckle at fifty.
Lee Provoost, CTO of Flagstone, described this with real precision during a recent episode of Leaders and Founders. At Flagstone, two separate engineering teams had been working so closely within the same codebase that they were constantly getting in each other's way. The work to separate those systems was not glamorous. But the results were immediate and measurable.
"Two teams were constantly stepping on each other's toes. After the separation, pull requests went through in almost a tenth of the time. The right team was focused on reviewing the right things. One of the big statements on the slide they presented was: it is actually fun to work on this codebase." - Lee Provoost, CTO, Flagstone
When engineering teams are fighting against their own systems and processes rather than building with them, morale drops alongside productivity. The engineers most likely to leave in that environment are the ones with the most options and the institutional knowledge they take with them compounds the problem further.
Most engineering organisations hit predictable points of friction as they grow. The team that worked brilliantly as eight people starts to struggle around fifteen. The processes that held together at thirty people begin to show serious cracks at sixty. These thresholds are not random. They reflect genuine structural shifts in how communication, ownership and decision-making need to work at different scales.
At smaller sizes, a team can coordinate largely through conversation. Everyone knows what everyone else is working on. Problems surface quickly and get resolved informally. As the team grows, that informal coordination model breaks down. Without deliberate investment in structure, the gap left behind fills with confusion, duplicated effort and decisions made without the right context.
Lee made this point directly when discussing Flagstone's own growth phase. The business grew its headcount by roughly a third in a single year, which brought genuine operational challenge alongside the obvious commercial benefit.
"When you go through big times of growth, most high-growth businesses tend to neglect dealing with foundational issues. Things like whether you have the right organisational structure with codebase owners. When you move teams around, you often end up with teams that own systems that may not align with their area of expertise. There are so many basics that companies tend to forget. A lot of companies could get a 20 to 30 percent productivity boost without even touching any new tooling." - Lee Provoost, CTO, Flagstone
A 20-30% improvement in productivity without a single additional hire is not a small number. For a business preparing to scale, or trying to demonstrate operational maturity to investors, that kind of gain carries significant weight.
One of the least discussed costs in a growing engineering organisation is the drag created by unnecessary complexity. Every additional system, every undocumented process, every area of the codebase with no clear owner represents a tax on the productive time of every engineer working near it.
Darren encountered this directly when he took over a business that had inherited a product range of around sixty different items. The sales team could not keep up with it and the technical team was constantly managing incompatibilities. Customers were not happy. The solution was not to manage the complexity better, it was to remove it.
"I tasked my lead technical architect to look at all sixty products and bring it down to five, making sure whatever was in that set, they all coexisted and everything worked together. We gave that product set a name, trained all the sales guys to only sell those five products, and the whole business changed." - Darren Spence, Group MD, Northamber
The parallel in engineering is direct. When a team is maintaining too many systems, working across too many contexts, or supporting products that have drifted far beyond their original design parameters, the answer is rarely to add more people to manage the sprawl. The answer is to reduce the sprawl. Fewer systems, owned clearly, maintained properly, almost always outperform a broader portfolio that nobody fully understands.
None of this is an argument against hiring. At some point, growth does require more engineers and getting the timing right matters. Hiring too late creates bottlenecks that are difficult to unblock quickly. Hiring too early adds cost and complexity before the team has the structure to absorb new people effectively.
The businesses that get this right tend to treat hiring as something that follows structural readiness rather than something that creates it. They invest in codebase ownership, release processes and team structure first. Once those foundations are solid, additional engineers can become productive relatively quickly because they are joining a system that is designed to absorb them.
Darren described a version of this sequencing when talking about Smartbox's expansion into new markets. Rather than placing people on the ground before the commercial groundwork was done, the approach was to build the pipeline first and deploy resource when there was something concrete for that resource to work on.
"As soon as we can see a decent qualified pipeline, then it is the time to deploy resource. You have to think about sequencing. If you hire ahead of that, you are paying for people who do not yet have the right environment to operate in." - Darren Spence, Group MD, Northamber
The logic transfers directly to engineering. Hiring into a team before the structural problems are resolved means paying experienced engineers to work slowly and leave sooner than they should.
Most of what holds engineering teams back from scaling effectively is a leadership problem. The decisions that create structural clarity, that define ownership, that resist the pressure to add complexity when simplicity would serve better, these are leadership decisions. They require someone with the experience to recognise what is happening and the authority to act on it before the organisation is feeling the full cost.
This is one of the reasons why the quality of technical leadership is such a significant factor in how PE-backed businesses perform through periods of growth. A CTO or VP of Engineering who understands how to build teams and systems that scale will deliver far more value than an equivalently sized team led by someone who does not. The difference shows up in delivery speed, in retention, in the ability to attract further talent, and eventually in how the business looks to investors and acquirers.
The businesses that scale their engineering teams most effectively are those that treat structural investment as a prerequisite for headcount growth rather than something to address after the team has already hit its limits. By the time the walls become visible, the cost of addressing them is significantly higher than it needed to be.
If your engineering team is delivering less than the business needs and the instinct is to recruit, it is worth pausing to assess whether the constraint is headcount before committing to the cost and disruption of a hiring process.
An independent technical review can surface where the real bottlenecks sit. Whether that is codebase ownership, release pipeline friction, test coverage gaps, or team structure that has not kept pace with growth. In many cases, addressing those issues directly will unlock more capacity, more quickly, and at lower cost than an equivalent investment in recruitment.
The businesses that scale well do not simply grow their teams. They build the conditions in which growth is possible before they commit to it.
Testimonials
Gathered & Found were able to deliver a great, experienced, culturally right fit for what we were looking for at FreeMarketFX covering a whole range of Service Design, User Experience, Front and Back end Engineers. This enabled us to scale our team capability very quickly, something we would not have been able to do ourselves. The team supplied were heavily motivated and experienced within the Fintech space and have helped deliver some great outcomes. I would definitely recommend the G&F calibration.
Greg Sherwin
CIO & CTO FreeMarketFX
I’ve been partnering with Gathered & Found while working for several companies now and I have systematically been impressed by their responsiveness, flexibility, overall ease to work with, forward thinking and the consistent level of their engineers and consultants. It has been a real pleasure working with them over the last years.
Nicholas Goubert
CPTO, Ocean Technologies Group
Gathered & Found have completely changed how we approach delivering our most critical projects. We usually have to wait 6 weeks for skilled engineers and delivery managers, but with G&F that timeframe has been turned on its head. Not only do they provide incredible consultants that deliver great work, but they find great culture-fits and their team understand exactly what we need for each engagement.
Engineering Director
Global Insurance Firm
As Founders who have never built a mobile app before, Gathered & Found were incredible at taking us through the entire process and making it very understandable from the outset. They supported us with complete app design, user experience and app development, and delivered an incredible product that will completely change our loyalty and rewards capability. Their Engagement team were also brilliant at keeping us updated with all developments and we honestly couldn’t be happier with the final product. We highly recommend them to any F&B or Retail businesses that need a supportive and amazing tech partner.
Tom Stock
Founder, Burger & Beyond
We brought in Gathered & Found for a critical engagement that required highly talented engineers. Our previous consulting partners had done a decent job, but were struggling with the complexity of delivering the initiative at scale in a regulated environment. The G&F squad that we received was extremely high bar and allowed us to keep in-line with our roadmap and ultimately delivered a great piece of work ahead of schedule and under budget. We are very pleased to have them as part of our wider partner team
Investment Bank
CIO
Gathered & Found have consistently exceeded our expectations with regards to delivering talented consultants that genuinely understand our business and mission. Their consultants are very well versed in our way of doing things and hit the ground running straight away. They have enabled us to deliver a number of high priority projects over the past 3 years, largely due to their ability to rapidly deploy great consultants into our teams and projects extremely quickly
Global Insurance Firm
Transformation Director
