PEC.com
Threshold framework

When should you invest in platform engineering? (and when you shouldn't)

There is a strong industry narrative that every organisation needs a platform team. The honest answer is smaller. Below a certain scale, you do not. Above it, you probably do. Here is how to know which side you are on.

The 30-engineer rule

The threshold where a platform team starts paying back is roughly thirty product engineers. This is consistent across the CNCF platform engineering survey, the DORA 2024 data on team maturity, and community data from Gartner peer threads. The specific number varies with stack complexity, regulatory environment, and deployment frequency needs, but thirty is a reasonable anchor.

Under 20 engineers
Almost certainly not

Managed services and conventions beat custom platforms. The overhead of a dedicated team exceeds the friction it removes. Hire product engineers and use opinionated cloud services.

20-30 engineers
Grey zone

One fractional platform engineer may help (20-40 percent of a senior IC's time). A full team is premature. Watch for the friction signals below.

30-50 engineers
Transition zone

If two or more friction signals are sustained for a quarter, budget for a platform team of 2-3 engineers. This is where delay starts to cost more than the investment.

50+ engineers
You are paying the cost

If you do not have a platform team at 50-plus engineers, you are paying for it anyway in slow deployments, long onboarding, and engineering frustration. Budget for 4-6 platform engineers.

The five friction signals

Instead of debating abstract scale thresholds, measure friction directly. Below are five specific, measurable thresholds. When any two are sustained over a full quarter, you have enough evidence to make the business case for a platform team.

01

Average deployment time exceeds 30 minutes

Product engineers sit and wait for pipelines to complete. Pipeline duration is the single most visible productivity tax and one of the first capabilities a platform team improves.

02

Onboarding new engineer to first PR takes over two weeks

If a new hire cannot ship something small in their first ten working days, your dev environment is broken. A platform team owns the dev environment as a first-class product.

03

More than two infrastructure-caused incidents per week

Configuration drift, missing runbooks, undocumented environment differences. These are platform work. Product engineers fixing them repeatedly is both expensive and demoralising.

04

Senior engineers spending 30%+ of their time on infrastructure help

When the most expensive engineers become reactive support staff for infrastructure questions, you are paying platform-team cost without getting platform-team leverage.

05

Spinning up a new service takes more than a day

Every new service requires manual cloud configuration, secrets setup, CI wiring, monitoring integration. A platform team replaces this with a golden path that takes an hour.

Signals you are wasting platform investment

The counterpoint. A platform team can be mis-invested. These are the red flags that mean the spend is not producing value and the investment needs a serious review rather than continued growth.

  • Adoption rate below 50 percent after 12 months. Product teams are building their own tooling around the platform. The platform is not solving their real problems.
  • Golden paths that do not solve the problems product teams actually have. Check by asking: which specific pain does this golden path remove? If the answer is vague, the path is not landing.
  • Platform engineers building features product teams did not ask for. The platform team has become a mini product team with no user research.
  • Internal tools that duplicate commercial offerings. If a decent commercial tool exists, building one means hiring a product team to lose the feature-parity race forever.

The first platform engineering hire

When you decide to invest, the first hire sets the tone. The ideal profile: a senior IC with at least five years of production experience across infrastructure-as-code, a CI platform, and cloud services. Cross-functional collaboration skill matters because they will be the primary interface to product teams.

Avoid hiring specialists first: a Kubernetes expert who has never done CI, or a security specialist who has not shipped deployments. Avoid hiring a manager before you have a team for them to lead. The first hire should be an engineer who will write most of the code for the first six months.

Salary expectation for this hire: staff-level loaded cost of $270k to $340k in US major markets (base $200k-$260k plus the 1.3x loaded factor). You are paying premium because this person designs the first two years of your platform.

The scaling path from one to eight

Once the first hire lands, here is the sequence that tends to work rather than over-hiring: second engineer within 6-9 months to remove single-point-of-failure risk on on-call. Third engineer at 12-15 months to enable one person taking meaningful leave without stalling the roadmap. Fourth through sixth engineers over the next 12 months as specialisation emerges (one CI/CD focused, one cloud infrastructure, one developer experience). Engineering manager hire becomes necessary at 6-8 engineers.

Resist the temptation to bulk-hire. A platform team of eight hired over 18 months ships more value than a platform team of eight hired over six months, because the earlier hires shape the hiring bar and the culture for the later ones.

Budget once you decide yes
Model the investment at your org size.
Team structure by scale
How the team composition evolves.
Build vs buy decision
Should the first year be custom or commercial?
Costs beyond salary
On-call, documentation, advocacy work.

Frequently asked questions

What is the minimum engineering team size that should invest in platform engineering?
Thirty engineers is the widely observed threshold where a dedicated platform function starts paying back. Below 20, the overhead of a platform team typically exceeds the friction it removes; managed cloud services and developer conventions work better. Between 20 and 30, one fractional platform engineer (senior IC with 20-40 percent platform responsibility) can help. Above 30, and especially above 50, you are paying the invisible cost of not having platform engineering even if you do not see it on any line item.
What are the specific friction signals that indicate you need platform engineering?
Five measurable thresholds. Average deployment time exceeds 30 minutes. Onboarding a new engineer to first shipped PR takes over two weeks. More than two infrastructure-caused incidents per week. Senior engineers spending over 30 percent of their time helping others with infrastructure. Spinning up a new service takes more than a day because there is no golden path. Any two of these sustained for a full quarter means you need to budget for a platform team in the next hiring cycle.
Can a startup skip platform engineering by using managed services?
Yes, and should, below about 30 engineers. Modern managed cloud (Vercel, Cloud Run, Fly, Heroku, AWS App Runner or the equivalent) plus a shared CI provider and basic observability covers 90 percent of what a startup platform team would build. The crossover point is when you have enough product complexity that conventions alone do not scale or enough engineers that onboarding becomes a bottleneck. Below 20 engineers this is rare; above 50 it is almost always there.
What happens if we invest in platform engineering too early?
Three failure modes. First, a platform team with no customers: product teams route around them because the platform is building features product teams did not ask for. Second, tooling that outgrows the org: the team builds for imagined scale, not actual scale, and maintenance burden exceeds value. Third, opportunity cost: senior engineers who should be shipping product are building internal tooling for a small audience. The waste is typically $500k to $1M per year at small scale and is not recovered when the team is later shut down.
Who should be the first platform engineering hire?
A senior IC (five-plus years) with production experience across infrastructure-as-code, a CI platform, and cloud services. Look for someone who has worked at both a small company (so they understand lean trade-offs) and a larger one (so they have seen what scale requires). Avoid specialists in this first hire: a Kubernetes expert who has never touched CI, or a security specialist who has not done deployments. Avoid hiring a manager first; you do not have a team for them to run yet.