Tech debt at growth stage: the platform investment decision
Growth-stage companies have the budget to fund a platform team but rarely have the willingness. The dominant tech-debt question at this stage is whether to fund structural engineering infrastructure or to keep delegating it to product teams that under-invest by design.
The 90-Second Answer
When the engineering organisation crosses 30-40 engineers, the marginal productivity gain from funding a dedicated platform team typically exceeds the marginal productivity gain from hiring more product engineers. The platform team produces a 15-30% productivity uplift across the rest of the engineering organisation within 12-18 months, dwarfing its own cost.
Why Platform Teams Get Underfunded
The structural under-investment problem
Platform teams are systematically underfunded relative to their economic value because of a structural problem in how engineering organisations are budgeted. Product engineering teams are funded against named product outcomes; their value is visible and measurable in the roadmap. Platform engineering teams are funded against productivity uplifts across other teams; their value is real but diffuse, and it requires several quarters to materialise. In a budget cycle that rewards visible short-term outcomes, the diffuse-and-delayed argument loses.
The result is a pattern that recurs across growth-stage engineering organisations: every product team builds a partial version of the platform infrastructure they need (deployment tooling, monitoring, service discovery, library wrappers), each one different from the others, none of them well-maintained, all of them eventually becoming a category of tech debt the entire organisation pays for. The aggregate engineering capacity consumed by these partial duplicate implementations is typically 2-4x the cost of a dedicated platform team that would have provided the canonical implementation. The platform team is the strictly cheaper option, but the structural budgeting problem makes it the harder option to fund.
A growth-stage CTO who recognises this dynamic can name it explicitly to the CFO and to the board. The pitch is not “please fund a platform team”; the pitch is “we are currently paying 2-4x the cost of a platform team in distributed duplicated work, and the duplicated work is itself becoming tech debt that will compound for years if we do not consolidate it”. The reframing converts the platform-team funding decision from a cost question into a cost-recovery question, and the answer becomes obvious.
The Sizing Heuristics
How big the platform team should be
Platform-team sizing varies by company stage, product complexity, and existing infrastructure maturity. The heuristics below are starting points for the conversation; specific companies often need to deviate based on their situation.
The platform engineer to product engineer ratio is the cleanest single metric; aim for roughly 1:6 to 1:10 at growth stage, settling toward 1:8 in steady state.
The Mandate
What the platform team is actually for
The most consequential decision about a new platform team is not its size but its mandate. Platform teams can be set up as service organisations (the rest of the company files tickets, the platform team executes), as architectural organisations (the platform team owns the canonical infrastructure and product teams consume it), or as internal-product organisations (the platform team builds tools that product teams choose to adopt). Each mandate produces different outcomes, and the wrong mandate for the company's culture produces a platform team that is constantly fighting the rest of the organisation.
The architectural mandate is the highest-leverage but the hardest to maintain. Product teams resent the constraint; the platform team gets pulled into political fights about what counts as “canonical”. The internal-product mandate is the most popular in modern engineering organisations, because it preserves product team autonomy while providing better defaults. The service mandate is the easiest to fund initially because the immediate visible value is clear, but it produces the smallest long-term strategic impact because the platform team's work scales linearly with product team requests rather than non-linearly with architectural decisions.
The CTO's choice of mandate should match the engineering culture. A strong-product-team culture (the Spotify-model orientation) typically prefers an internal-product mandate. A more centralised engineering culture (the larger-company orientation) typically prefers an architectural mandate. The service mandate works for early platform teams that need to demonstrate value quickly before earning the right to a stronger mandate, but it should be a transitional state, not a permanent destination.
The Uplift Mechanism
Where the 15-30% productivity uplift comes from
The 15-30% productivity uplift cited in the headline answer is not a single intervention; it is the cumulative effect of removing many small frictions that consume engineering capacity diffusely. A well-run platform team eliminates: per-team duplication of CI/CD configuration, per-team duplication of deployment tooling, per-team duplication of observability setup, per-team duplication of secret management, per-team duplication of internal API discovery, and per-team duplication of the dozens of similar primitives that every product team needs.
Each individual friction is small (perhaps a few engineer-hours per team per quarter), but the aggregate across an engineering organisation of 50-100 engineers is substantial. The platform team's work is to identify these frictions, build the canonical solution once, and reduce the per-team cost from “a few hours per quarter” to “effectively zero”. The 15-30% uplift figure is what emerges when this work is done sustainably across 12-18 months.
The uplift is rarely visible as a single metric. It shows up as: faster lead times for product changes (because deployment is no longer a hand-rolled process per team), faster incident recovery (because observability is consistent across services), faster onboarding for new hires (because the development environment is canonical and well-maintained), and faster cross-team integration work (because the internal API surface is documented and discoverable). Each of these is a separately measurable improvement; the aggregated productivity uplift is the sum.
Cross-Reference
Growth stage in the company-stage stack
Growth stage sits between Series A-C (where the 30-engineer wall typically emerges) and late stage (where pre-IPO cleanup work intensifies). For the public-company variant of the same platform investment thinking, see tech debt at the public company. For the business-metric impact most affected by platform investment, see the velocity (DORA) page and the SaaS gross-margin page (platform investment typically improves both).
For the engineering-practitioner view of the platform-team patterns that work at this scale, see the sister site technicaldebtcost.com. The platformengineeringcost site (a portfolio sibling) covers the per-engineer cost arithmetic for platform team funding specifically.
Field Notes
Frequently asked questions
What defines the growth stage for tech debt purposes?+
Roughly Series C to pre-IPO. Engineering team typically 50-200 engineers, revenue $50M-$300M, the company has product-market fit and is scaling go-to-market while preparing for either a late round or a public listing. Tech debt at this stage is no longer a small-team improvisation problem; it is a structural-investment decision.
When should a growth-stage company fund a dedicated platform team?+
Typically when the engineering organisation crosses 30-40 engineers and the percentage of capacity consumed by coordination and infrastructure work exceeds 25%. Funding a platform team earlier than this is often premature; funding it later is usually overdue and means the debt has already accumulated significantly.
How big should a growth-stage platform team be?+
A rough heuristic: 1 platform engineer per 6-10 product engineers, with a minimum viable platform team of 4-6 people for the leadership and architectural cohesion to be effective. Below this size the platform team becomes a service team rather than an architectural team, and the strategic impact is much smaller.
What does the platform team actually do?+
Builds and maintains the internal infrastructure that other engineering teams build on: CI/CD pipelines, deployment systems, observability stacks, internal developer tooling, shared service infrastructure, the per-tenant or per-customer scaling primitives. The work is upstream of every product team's work, which is what makes it high-leverage.
Should the platform team report to the CTO or VP Engineering?+
Either, depending on company structure. The principle is that the platform team should report at the same level as the largest product engineering org, not below it. Reporting structures that put the platform team below product engineering tend to result in the platform team being treated as a support function rather than an architectural function.
What is the typical platform-team ROI for a growth-stage company?+
Hard to express as a single number but the productivity uplift across the product engineering organisation is typically 15-30% within 12-18 months of a well-run platform team's establishment. For a 60-engineer product organisation, that uplift translates to the equivalent of 9-18 additional product engineers worth of capacity, which dwarfs the platform team's cost.
Adjacent Reading