What is a platform team, in plain terms?

A platform team is a group whose job is to build and maintain the shared tools and systems that other product teams use, things like deployment pipelines, shared authentication, logging, or internal developer tools. Instead of each product team solving the same infrastructure problem on its own, the platform team solves it once and the other teams use that solution.

How many product teams do we need before a platform team makes sense?

There is no fixed number that applies to every company, because the real trigger is duplicated work, not team count. That said, a single product team, or even two, rarely generates enough repeated shared-infrastructure work to justify a dedicated group; the question becomes worth asking seriously once you have three or more teams independently solving the same kinds of problems.

What is the clearest sign we need a platform team now?

The clearest sign is the same infrastructure problem getting solved more than once by different teams in the same quarter, each unaware of the other's fix. A second sign is a senior engineer on a product team spending real weekly hours on deployment, environment, or tooling work that has nothing to do with the product itself.

What happens if we build a platform team too early?

A platform team with only one or two product teams to serve usually ends up with no real customers for its work, so it either invents problems nobody asked it to solve or turns into a slow-moving ticket queue. Either way, you have paid full salaries to move work off product teams that were not actually struggling with it yet.

Does a platform team replace DevOps or infrastructure engineers?

Not exactly. A platform team can include people who used to be called DevOps or infrastructure engineers, but the shift is in who they serve and how: instead of running tickets for individual requests, they build a system that product teams can use themselves, on their own schedule, without waiting on a ticket queue.

How do we measure whether a platform team is paying for itself?

Track two things over time: how many hours product teams spend on shared-infrastructure problems before the platform team exists, and how that number changes after. If the hours do not drop within a couple of quarters, the platform team is not solving the right problems, and that is worth naming directly rather than waiting it out.

What is the biggest mistake companies make with platform teams?

Treating the platform team as a cost center that exists because "companies our size have one," rather than as a team that must earn continued investment by measurably reducing duplicated work across product teams. A platform team with no product-team feedback loop drifts toward building what its own engineers find interesting instead of what the rest of the company actually needs.

Should the platform team report to the same leader as product engineering?

In most setups it makes sense to keep the platform team under the same engineering leadership as the product teams it serves, so that priorities are set by the same person who can see both the product roadmap and the shared bottlenecks. A platform team that reports separately, with its own competing roadmap, is more likely to drift from what product teams actually need.

What is the risk of never building a platform team?

Each product team keeps solving the same problems separately, and the company pays for that duplication forever in slower delivery, inconsistent tooling, and engineers who could be building product features instead of rebuilding infrastructure that already exists somewhere else in the company. The cost is real; it is just spread out and harder to see on one line of a budget.

Does staff augmentation help before we are ready for a full platform team?

Yes. Bringing in outside engineers for a defined period to build the shared tooling a platform team would eventually own lets you get the duplication problem solved without committing to permanent headcount before you know the work is ongoing rather than a one-time cleanup.

How to decide if you need a platform team: Reveneau

Q: Can we solve shared infrastructure problems without a dedicated team?

Yes, and for a small number of product teams this is usually the right answer. One engineer owns the deployment scripts, another owns the shared environment setup, and the group agrees on conventions everyone follows, all without anyone being pulled off product work full time.

We have scoped builds where the client already had a platform team of six people serving two product teams of five engineers each. We have also scoped builds where five product teams shared one overworked infrastructure engineer who fixed the same deployment problem four separate times because nobody had written down the fix from the first three. Both companies thought they were being efficient. Only one of them was.

The difference was never about company size or engineering headcount. It was about whether the same infrastructure problem was getting solved more than once. That is the whole test, and it holds regardless of whether you have twenty engineers or two hundred.

The rule: count the duplication, not the teams

A platform team exists to solve one problem: shared infrastructure work that would otherwise get redone, slightly differently, by every product team that hits it. Deployment pipelines, environment setup, shared authentication, logging, internal developer tools. None of that work builds a feature a customer sees. All of it has to exist for the features to ship safely and fast.

The decision is not "do we have infrastructure work," because every company with more than one engineer has some. The decision is whether that work is duplicated: whether two or three teams, working separately, are each burning hours solving a version of the same problem because there is no shared owner for it.

One team hitting a deployment problem once is a normal Tuesday. Three teams hitting the same deployment problem in the same month, with three different half-fixes, is the signal. At that point the cost is not the hours spent fixing it. It is the hours spent fixing it three times, plus the inconsistency that shows up later when those three fixes behave differently under load.

When it pays for itself: three or more teams, real duplicated hours

In the work we do, the pattern that justifies a dedicated platform team looks like this: three or more product teams, each independently spending real weekly hours on shared-infrastructure problems that have nothing to do with the product they were hired to build.

That second part matters as much as the team count. A company can run five product teams and never need a platform team, if each team's infrastructure needs are genuinely different enough that there is nothing to share. What forces the decision is repetition: the same class of problem, hit by different people, solved differently each time, with no mechanism for one team's fix to reach the others.

When that repetition is happening, a platform team is not overhead. It is the removal of overhead that was already being paid, just paid in a way that did not show up as a single line item. Before the team exists, the cost is scattered across every product team's velocity, a little slower here, a little slower there, never quite big enough on its own to justify a fix. A dedicated team turns that scattered cost into one visible investment that is easier to manage and easier to hold accountable.

The 2025 DORA Report found that 90 percent of organizations surveyed had adopted an internal developer platform, and 76 percent had a dedicated platform team, up sharply from prior years. That adoption curve tells you platform teams have become the normal answer once a company reaches a certain scale, not that every company needs one on day one.

When it is premature: one or two teams, work that is not actually shared

The mirror case is just as clear. With one product team, there is no duplication to remove, because there is only one team doing the work. A platform team here has no real customer. It either invents problems nobody asked it to solve, or it turns into a queue that the one product team waits on, which is slower than the team just owning its own infrastructure.

Two product teams sit in the same trap more often than leaders expect. Two teams can absolutely have overlapping infrastructure needs, but two teams can also just talk to each other. One engineer owns the deploy scripts, another owns the shared environment setup, and the two teams agree on conventions in a meeting that takes an hour, not a payroll line that takes a quarter. Cooperation between two teams is cheap. A dedicated team is not, and the difference in cost has to be earned by the size of the duplication problem, not assumed because "companies our size have a platform team."

The failure mode we see most often is not a company refusing to build a platform team when it needed one. It is the opposite: standing one up early because it felt like the responsible, grown-up thing to do, then watching a senior engineer who should be shipping product spend the next two quarters building internal tools for an audience of one or two teams who did not have a duplication problem in the first place.

There is a quieter cost to the early version, too. Once a platform team exists, it needs its own roadmap, its own priorities, and its own justification at every budget review. A company that built one too early now has to defend the team's existence on top of doing the team's work, and defending a decision is a worse use of a leader's time than making the right one in the first place.

The test to run before you hire

Before adding a platform team, answer two questions with real numbers, not a guess.

First: how many product teams currently exist, and how many of them have independently solved a version of the same infrastructure problem in the last two quarters? If the answer is one team, or two teams that have simply never needed to talk, the case is not there yet.

Second: how many hours a week is a senior engineer, on any product team, spending on infrastructure work that is not specific to their own product? Add it up across teams. If that number is small, a platform team converts a small problem into a fixed cost that has to be justified every quarter going forward. If that number is real and growing, a platform team turns a cost you are already paying, just paying invisibly, into a team whose whole job is to bring it down.

Track that number after the team exists, too. A platform team that does not measurably reduce duplicated hours within a couple of quarters is not solving the right problems, and that is worth naming directly rather than assuming the investment will pay off eventually.

Write both numbers down before you decide, not after. It is easy to remember the deployment outage that took a whole afternoon and forget the twenty smaller instances of the same underlying problem spread across a quarter, each one small enough on its own to shrug off. The scattered version of a cost is easy to underweight precisely because no single instance of it looks expensive.

What to do in the gap before you commit

Some companies sit in an uncomfortable middle: not yet at three teams with clear duplication, but growing fast enough that the question will come back in two quarters. In that gap, staff augmentation is often the better first move. Bringing in engineers for a defined period to build the shared tooling a platform team would eventually own lets you fix the duplication that exists today without committing permanent headcount to a role you are not yet certain is ongoing work rather than a one-time cleanup.

That approach also produces the evidence you need for the real decision. If the augmented team's work keeps needing updates and keeps getting requested by more product teams as they onboard, you have your answer, and you have already proven the platform team's backlog is real before you hire for it.

The teams that get this right are not the ones with the most infrastructure. They are the ones that can point to the specific hours being lost to duplicated work before they spend a single dollar removing it. A platform team is not a milestone you reach at a certain size. It is a fix for a cost you can already measure.

Sources

The 2025 DORA Report, platform engineering capability: supports the adoption figures cited above, 90 percent of organizations using an internal developer platform and 76 percent with a dedicated platform team.