Team-size cost framework

10-engineer platform team: sub-team crossover at $2.4M to $3.2M a year

Ten engineers is the threshold at which sub-team specialisation starts to pay back, formal engineering management becomes necessary, and the platform team starts to feel like a small engineering org.

Annual all-in

$2.4M-$3.2M

Salary dominates; management overhead and enterprise-tier tooling crossover add lines.

Sub-team count

2-3

Typically DevEx, Infrastructure, CI/CD. Often informal at this scale, formal at 12+ engineers.

Right fit at

150-250 devs

Below 150 is over-investment; above 250 the next structural transition kicks in.

Why 10 engineers is a structural transition

Above 10 engineers, the single-team structure becomes coordination-heavy. Roadmap conversations get long, planning rituals consume too much time, individual engineers lose visibility into what the rest of the team is doing. Below 10 engineers, sub-team specialisation adds more coordination overhead than it saves. Ten is the threshold at which splitting into 2 to 3 sub-teams starts to deliver clear focus benefits.

The other structural change at 10 engineers is the formal engineering-manager role. At 5 engineers (the MVP configuration) the lead carries management responsibility part-time. At 8 to 10 engineers the management work consumes most of the lead's time, pushing technical contribution out. The formal EM role exists to absorb that work and let the previously-overloaded lead either return to deep technical contribution as a Staff engineer or fully commit to the management track.

Both transitions add cost. Both deliver capacity unlock that exceeds the cost within a year. This page walks through the numbers.

The typical headcount mix

A 10-engineer platform team most commonly looks like:

1 engineering manager. Loaded cost typically $300k to $390k. Manages 8 to 9 engineers (plus often the staff engineer as a peer-coaching relationship), owns hiring, owns roadmap planning, holds the platform team's relationships with engineering leadership.
1 staff engineer. Loaded cost typically $300k. Technical leader for the platform team, owns architectural decisions, mentors senior and mid-level engineers, often holds technical relationships with vendors and the broader open-source community.
4 senior engineers. Loaded cost about $234k each. Each owns one or two capability areas across the 2 to 3 sub-teams. Drives major roadmap initiatives.
4 mid-level engineers. Loaded cost about $182k each. Each focused on hands-on contribution in one sub-team, growing into broader scope.

Salary mix totals about $2.27M loaded for the typical configuration. Variations: a leaner mix (no separate staff engineer, EM doubles as Tech Lead) totals about $1.95M; a senior-heavy mix (no mid-level, 6 senior engineers) totals about $2.6M.

The 2 to 3 sub-team pattern

Most 10-engineer platform teams split into 2 to 3 sub-teams. The most common pattern:

Developer Experience (DevEx). 3 to 4 engineers. Owns golden paths, scaffolding, developer portal customisation, internal documentation, and adoption work.
Infrastructure. 3 to 4 engineers. Owns cloud foundations, networking, security baselines, Kubernetes management, single-cluster operations.
CI/CD or Build Tooling. 2 to 3 engineers. Owns build pipelines, deploy pipelines, secrets management, environment-promotion workflows.

At 10 engineers, the sub-team split is often informal: teams within the team, with the staff engineer or EM holding cross-sub-team responsibilities, rather than separate sub-team leadership. Formal sub-team management (each sub-team with its own EM) typically arrives around 12 to 15 engineers (the 250-developer picture).

Cost line by line

Salary. $1.95M to $2.6M loaded for the team. About 70 to 75 percent of total platform cost.
Hidden overhead. $240k to $360k a year. On-call stipends across 10 engineers (typically $300 to $1,500 per engineer per month), training budget ($30k to $100k total), recruiting amortisation (3 to 4 new hires a year at this scale is normal), equipment, per-head SaaS.
Tooling. $200k to $500k a year for a 150 to 250-engineer organisation. Crossover from standard to enterprise tier typically kicks in on observability, sometimes on CI/CD, often on the IDP if you use a commercial product with audit and SSO needs.
Cloud infrastructure for the platform itself. $80k to $200k a year. Larger Kubernetes clusters, higher observability ingest, more secrets-manager capacity, often a multi-cluster developer-portal hosting tier.

Total: $2.4M to $3.2M a year. The lean configuration (leaner seniority mix, standard tier tooling) lands at the lower end; the standard configuration (typical seniority mix, enterprise-tier tooling crossover) at the upper end.

The sub-team formation dip and the unlock

Splitting a 10-engineer team into 2 to 3 sub-teams creates a productivity dip in the first quarter:

10 to 20 percent of team capacity goes to coordination overhead as sub-team boundaries are clarified.
Informal handover patterns that used to be ambient (the senior engineers all knew what each other was doing) need to be made explicit (cross-sub-team standups, shared backlog visibility).
Some work that used to be picked up by whoever had bandwidth now has to be explicitly routed to a sub-team, which slows it down.

This dip is real and is the most common reason platform leaders panic about sub-team transitions. Plan for it; communicate it clearly to engineering leadership ahead of time; do not roll back the transition. By quarter two, the dip usually reverses. By quarter three, the team's substantive output is 15 to 30 percent higher than before the transition:

Each sub-team can focus deeply on their domain without context-switching to other areas.
Individual engineers lose the cognitive overhead of having to know everything the team is working on.
Architectural decisions in each domain become faster because they can be made within the sub-team.
Hiring becomes easier because the role definitions are clearer.

Net effect over a year is positive, often significantly. The capacity unlock is the reason the sub-team transition is the right structural move at this scale.

Keeping cohesion across sub-teams

The risk of sub-team splits is that the sub-teams drift apart: each becomes a small fiefdom, cross-sub-team work becomes hard, the platform feels increasingly inconsistent to product engineers. Three patterns help avoid this:

Shared on-call. One rotation across all 10 engineers, with sub-team escalation paths rather than separate sub-team rotations. Keeps everyone connected to the operational reality of the whole platform and reminds engineers that decisions in one sub-team affect the others.
Regular cross-sub-team initiatives. Each major roadmap initiative has at least one engineer from each sub-team, even if a single sub-team is the primary owner. Forces information flow and prevents sub-team isolation.
Weekly all-hands rituals. A 30-minute weekly sync where each sub-team shares progress and current friction. Low overhead, high information bandwidth, prevents any sub-team from becoming invisible to the others.

Investing in cohesion explicitly is the difference between a 10-engineer team that operates as one platform and a 10-engineer team that operates as three small platforms in a trenchcoat.

What the team can deliver in year one

A 10-engineer platform team at a 150 to 250-developer organisation can realistically deliver in year one:

3 to 4 golden paths covering the most common service types.
Mature CI/CD with build-time SLAs, pipeline observability, and team-level pipeline metrics.
A mature observability stack with per-team dashboards, SLO tracking, alerting rule curation, and basic distributed-tracing adoption.
Secrets management with rotation, audit logging, and integration with policy-as-code.
A service catalogue with high data freshness and 4 to 6 scorecards covering reliability, security, ownership, on-call, documentation.
Self-service environment provisioning for the most common workload types.
Initial FinOps integration (visibility into per-team cost, basic cost-aware deployment recommendations).

What the team cannot reasonably deliver in year one:

Multi-region operations at full maturity.
Deep compliance scaffolding for sector-specific regulations.
A formal Platform Product Manager function.
Mature DX measurement (DORA dashboards, DX survey cadence, time-to-productivity tracking).

Comparison with adjacent team sizes

2 engineers: $500k-$700k, suits 20-40 product engineers.
5 engineers: $1.2M-$1.6M, suits 60-150 product engineers, MVP configuration.
10 engineers: $2.4M-$3.2M, suits 150-250 product engineers, sub-team crossover (this page).

Above 10 engineers, the platform team typically transitions to formal multi-sub-team structure with a Director and multiple EMs (see /cost-for-250-developers). The next coherent team-size band is 18 to 25 engineers at the 250-developer organisation scale.

Salary figures per BLS OEWS and Levels.fyi. Sub-team formation dynamics per Team Topologies framework material and CNCF Platforms Working Group case studies. Verified 2026-05-11.

Frequently asked questions

What does a 10-engineer platform team cost?

About $2.4M to $3.2M a year loaded. The typical headcount mix is one engineering manager at $300k loaded, one staff engineer at $300k loaded, four senior engineers at $234k each, four mid-level engineers at $182k each. Salary mix totals about $2.27M loaded. Add hidden overhead ($240k to $360k) and tooling ($200k to $500k for a 150 to 250-engineer organisation at standard tier with crossover toward enterprise) to get to $2.4M to $3.2M total platform cost. The single biggest variable is whether tooling has crossed to enterprise tier on the major categories.

Why is 10 engineers the sub-team specialisation crossover?

Above 10 engineers, the team becomes coordination-heavy as a single coherent unit. Roadmap conversations get long, planning rituals consume too much time, individual engineers lose visibility into what the rest of the team is doing. Below 10 engineers, sub-team specialisation adds more coordination overhead than it saves. Ten is the threshold at which splitting into 2 to 3 sub-teams (typically DevEx, Infrastructure, CI/CD) starts to deliver clear focus benefits, although the splits at this scale are often informal (teams within the team, not formal sub-teams with separate management).

When does a formal engineering manager role become necessary?

Typically around 7 to 10 engineers, at which point the senior IC or staff engineer who has been carrying the lead role part-time finds that management work is consuming most of their time and pushing technical contribution out. At 10 engineers, the formal EM role is almost always necessary. The role exists to handle 1:1s with 8 to 10 engineers, hiring and onboarding, performance management, cross-team coordination, and roadmap planning, all of which is full-time work at this scale.

What are the productivity dynamics of the 10-engineer team?

Two effects show up. First, the productivity dip during sub-team formation: when the team splits into 2 to 3 sub-teams, the first quarter loses 10 to 20 percent of capacity to coordination overhead, role clarification, and informal team boundaries forming. Plan for it; do not panic. Second, the capacity unlock once sub-teams are formed: each sub-team can focus deeply on their domain, individual engineers lose context-switching tax, and the team's substantive output rises by 15 to 30 percent within two quarters of the transition. Net effect over a year is positive but the first quarter feels worse than the previous configuration.

How does a 10-engineer team keep cohesion across sub-teams?

Three patterns work consistently. First, shared on-call: one rotation across all 10 engineers, with sub-team escalation paths rather than separate sub-team rotations. Keeps everyone connected to the operational reality of the whole platform. Second, regular cross-sub-team work: each major roadmap initiative has at least one engineer from each sub-team, even if a single sub-team is the primary owner. Third, weekly all-hands rituals: a 30-minute weekly sync where each sub-team shares progress and current friction, so that no sub-team becomes invisible to the others.

What is the organisation size sweet spot for a 10-engineer team?

One hundred fifty to two hundred fifty product engineers. The 1:15 to 1:25 ratio looks lean at this scale; the 1:20 midpoint puts 10 platform engineers at the 200-developer scale. Below 150 product engineers, 10 platform engineers is over-investment (you can deliver the same scope with 7 to 8 engineers). Above 250 product engineers, 10 engineers is under-investment and the next structural transition (formal multi-sub-team, Director role, possibly Platform PM) becomes urgent. See /cost-for-250-developers for that picture.

5-engineer team cost

The MVP configuration before this.

2-engineer team cost

Bootstrap configuration.

250-developer cost

Next structural transition.

Team structure

How team shape evolves.

Director salary

Senior leadership role.

Run your numbers

Plug in your specific inputs.