Tech debt at Series A to C: the velocity crisis
Series A-C is the stage where tech debt becomes a board-level conversation. The 30-engineer wall, the second-CTO-hire problem, and the velocity crisis that defines mid-stage scaling all converge in this window. The decisions made here shape the next 5-7 years of engineering culture.
The 90-Second Answer
Most engineering organisations hit a sharp velocity decline at 25-40 engineers as decisions that worked for a small coordinated team stop scaling. Hiring faster does not fix the velocity decline; addressing tech debt does. Series A-C is the right window to invest 15-25% of capacity into structured remediation, before the company reaches a size where rebuilding becomes prohibitively expensive.
The 30-Engineer Wall
Why velocity falls off a cliff at mid-stage scale
The 30-engineer wall is a widely-observed inflection point. Engineering organisations passing through the 25-40 engineer band almost always experience a sharp velocity decline. The cause is structural rather than personnel: an organisation of 10-15 engineers coordinates through informal conversation and shared context; an organisation of 35+ engineers requires explicit interfaces, defined ownership boundaries, and platform infrastructure that did not previously exist. The transition is uncomfortable because the cost is paid in current-period velocity for a future-period structural benefit.
What founders typically observe: the team that shipped a major release every two weeks at 15 engineers now ships every six weeks at 35 engineers. The lead time on changes has grown. The on-call burden has grown. Senior engineers complain about coordination overhead. New hires complain about onboarding friction. The natural diagnosis is “we need to hire faster”, which is almost always the wrong diagnosis at this stage and produces no improvement when implemented.
What is actually happening: the structural debt accumulated during the small-team phase is now being paid as coordination tax across the larger team. The cost of integrating a feature now requires touching code owned by multiple engineers, none of whom have full context. The release process that worked for a 15-engineer team breaks under the load of a 35-engineer team. The architecture that supported the early product no longer supports the cross-team dependencies the larger team has created. Each of these is a debt position whose cost was deferred during the small-team phase and is now being collected.
The Capacity Allocation
How much capacity should go to debt reduction at this stage
The sustainable capacity allocation for tech debt at Series A-C is consistently in the 15-25% range across well-run engineering organisations. Below 15%, the work produces no measurable improvement because individual remediations are too small to register against accumulating debt. Above 25%, feature velocity slows to the point that the board challenges the allocation as misuse of fundraised capital.
The structuring of the allocation matters as much as the percentage. A dedicated platform team consuming 20% of total capacity often delivers more measurable improvement than the same 20% distributed across product squads.
The Second CTO Hire
When the founding CTO is the wrong CTO for the next stage
The founding CTO who built the company through pre-Series A is sometimes the wrong person to lead a 40+ engineer organisation. The skills that produce a working MVP and ship product through Series A (technical depth, hands-on building, small-team leadership) are different from the skills that build an engineering organisation through Series B-C (people leadership, platform thinking, board-level communication). The transition between the two skill sets is not automatic, and the second CTO hire is often the moment at which the company acknowledges that the transition needs to happen.
The tech debt narrative is sometimes the explicit reason for the second CTO hire. A founding CTO who has built up significant debt during the small-team phase is, by association, the leader most responsible for it. The board's instinct is sometimes to bring in fresh leadership to drive the remediation, regardless of whether the founding CTO is also capable of doing so. This dynamic is uncomfortable but common, and it is worth naming explicitly in any tech-debt conversation that surfaces at the board level during the Series A-C window.
The cleaner version of this transition is the proactive one: the founding CTO recognises the skill-shift required, moves into a Chief Architect or Founding Engineer role, and hires a VP Engineering or new CTO who is calibrated for the next stage. This pattern preserves the founding CTO's institutional knowledge and equity participation while bringing in scale-stage leadership. It is the dominant pattern in successful Series A-C engineering org evolutions.
The Board Conversation
What the Series A-C board wants to hear about tech debt
Series A-C boards have at least one investor with operating experience, often more. These directors will ask pointed questions about engineering productivity when the velocity dip starts to become visible in roadmap slippage. The CTO should expect to present a tech-debt assessment to the board at least once during this window, ideally proactively rather than in response to a slippage event.
The board's questions are specific. Lead time trend, deploy frequency trend, MTTR trend, change failure rate, senior IC retention, time-to-productive for new hires, percentage of capacity allocated to platform work. The board will compare against benchmarks they have seen at other portfolio companies. A CTO who presents these numbers candidly, with a credible remediation plan, builds long-term board credibility. A CTO who presents only the favourable subset, or who treats the conversation as adversarial, makes the next board meeting harder.
The companion board pitch page covers the formal fiduciary frame for boards with public-company or pre-IPO orientation. The Series A-C variant is less formal but more frequent: it is part of the standard quarterly engineering update rather than a standalone fiduciary item. The substance is similar; the framing is more operational and less compliance-flavoured.
Cross-Reference
Series A-C in the company-stage stack
The Series A-C stage sits between pre-Series A and growth stage. The companion later-stage pages are late stage and public company. For the cross-stage business-metric impacts most relevant at this window, see velocity impact (DORA), onboarding impact, and burn-rate impact.
For the fundraising DD that becomes substantive at Series B and C, see the VC pitch page. For the engineering-practitioner view of the platform-team patterns that work at this scale, see the sister site technicaldebtcost.com.
Field Notes
Frequently asked questions
Why is tech debt particularly acute at Series A-C?+
Because the company is growing engineering headcount fast enough that decisions made when the team was small no longer scale, but the company has not yet reached the size where platform investment is a self-evident priority. The mismatch produces a velocity crisis that founders often misdiagnose as a hiring problem.
What is the 30-engineer wall?+
The observation that many engineering organisations hit a sharp velocity decline somewhere between 25 and 40 engineers. The cause is structural: decisions and processes that worked for a coordinated small team no longer scale to a team that requires explicit interface contracts and platform infrastructure. Most teams pass through this transition with a 6-9 month velocity dip.
Should we hire faster or address debt to recover velocity?+
At Series A-C, address debt first. Hiring faster into a debt-heavy codebase often produces no velocity gain (and sometimes a velocity loss) because the new hires inherit the onboarding tax and the coordination overhead. The order of operations matters: debt reduction creates capacity that subsequent hires can plug into.
How does board involvement change at this stage?+
The Series A board typically has at least one VC investor with operating experience, and they will start asking pointed engineering productivity questions if the velocity dip becomes visible in roadmap slippage. The CTO should expect to present a tech-debt assessment to the board at least once during the Series A-C period.
Is the second CTO hire common at this stage?+
More common than founders expect. The founding CTO who built the company through pre-Series A is sometimes the wrong person to lead a 40+ engineer organisation, and the transition (with or without the founding CTO moving to a different role) often happens during the Series A-C window. The tech-debt narrative is sometimes the explicit reason for the transition.
What is the right tech debt remediation budget at this stage?+
Typically 15-25% of total engineering capacity, structured as either a dedicated platform team or as a fixed allocation across product squads. Below 15% produces no measurable improvement; above 25% slows feature velocity to the point that the board challenges the allocation. The sweet spot is sustained, not bursty, allocation in the middle of the range.
Adjacent Reading