Platform team vs each team owns its stack

The decision

Every product team must build, deploy, monitor and run its services. With team-owned stacks, each team picks its own languages, pipelines and hosting, and carries the work itself. With a platform team, a central team builds one common way to do this, called the paved road, and product teams use it as customers. A middle way is a thin platform: a small, optional paved road that teams can leave when they have a reason. The forces are team speed, cost, risk when people leave or move, and the mental load on each team.

Choose team-owned stacks when

• You have few teams, for example 3 or fewer. A platform team would cost more than it saves (see the numbers, which are our model).
• Teams do very different work, such as a machine learning team, a mobile team and a payments team.
• The company is early and still learns what it needs, so a common road may be wrong.

Choose a platform team when

• You have about 6 or more product teams doing the same infrastructure work again and again (our break-even, see the numbers).
• Engineers move between teams often, and every move costs weeks of learning.
• You must show the same security and audit controls in every service.
• Product teams say that infrastructure work takes a big share of their time.

Choose a thin platform when

• You are between the two cases above, and you want the savings without the queue.
• You can offer templates, pipelines and guides that save time, and let teams opt out with a short written reason.

The numbers that change the answer

All numbers here are our assumptions or our calculations, except the Team Topologies quotes. An engineer costs Rs 3,000,000 a year, and a product team has 6 engineers.

Where a platform pays back (calculation).

• Without a platform, a team spends 20% of its time on infrastructure: 0.20 x 6 = 1.2 engineers.
• With a good platform, 8%: 0.08 x 6 = 0.48 engineers.
• Saved per team: 1.2 - 0.48 = 0.72 engineers = 0.72 x 3,000,000 = Rs 2,160,000 a year.
• The platform team has 4 engineers: 4 x 3,000,000 = Rs 12,000,000 a year.
• Break-even teams = 12,000,000 / 2,160,000 = 5.6, so 6 teams.

Moving between teams (assumptions plus calculation). Assumption: with 10 different stacks a person who moves needs 4 weeks to be useful; with one road, 1 week. Assumption: 10 moves a year. Saved = 10 x 3 weeks x Rs 62,500 = Rs 1,875,000 a year (62,500 is Rs 3,000,000 over 48 weeks). This is not in the table above.

When the platform becomes the bottleneck (calculation). Assumption: product teams file 40 requests a month. Each takes 1.5 engineer-days. The 4 platform engineers spend half their time on requests, with 20 working days a month. Capacity = 4 x 20 x 0.5 / 1.5 = 26.7 requests a month. The queue grows by 40 - 26.7 = 13.3 a month. After 6 months it holds 80 requests, which is 80 / 26.7 = 3 months of waiting. A platform that answers by tickets does not scale. It must offer self-service, so that requests drop below its capacity.

Cited ideas (Team Topologies). The Team Topologies site says platform teams create services that accelerate stream-aligned teams (teams that own a flow of product work). It says overloaded teams make poor decisions and move slowly, as overloaded processors do. It warns that most internal platforms become bloated and slow teams down, and it names the thinnest viable platform as the answer. It lists three ways for teams to work together: collaboration (high bandwidth, high cost), use as a service (minimal interaction), and facilitation (temporary and focused). See Sources.

What breaks with each choice

Team-owned stacks.

• Ten teams solve the same problem ten ways, so fixes are done ten times. Fallback: a shared guide and a monthly sharing meeting.
• A security or audit rule needs ten separate changes. Fallback: a short list of required controls, checked by a script.
• On-call is hard because an engineer from another team cannot read the stack. Fallback: a minimum standard for logs, metrics and runbooks.

Platform team.

• It becomes a ticket queue (a 3-month wait in the example). Fallback: self-service tools, and a limit on work in progress.
• It builds what it likes, not what teams need. Fallback: treat teams as customers, with a roadmap and a regular review with them.
• One road does not fit an odd team, and the team goes around it. Fallback: a written way to opt out, and help from the platform team to build the exception.
• It grows into a large, slow system. Fallback: the thinnest viable platform and a regular review that removes unused parts.

Thin platform.

• Optional means some teams use it and some do not, so you pay for both. Fallback: measure voluntary use and make it the default for new services.

What it costs

• People: 4 engineers at Rs 12,000,000 a year in the example. The thin platform starts with 1 to 2 engineers part-time, or Rs 1,500,000 to Rs 3,000,000 (0.5 to 1 engineer-year).
• Reversible-first path. Start with team-owned stacks and one shared template for a new service, kept by volunteers. When a third team asks for the same thing, build it into the thin platform. Make a full team when you pass about 6 product teams (our calculation above). Make it also when teams report more than 15% of their time on infrastructure (Assumption: our trigger). Make the road the default for new services before you make it mandatory. Measure voluntary use (Assumption: aim for more than 70% of services), days from a new service to its first deploy, and request wait time.
• Changing your mind: a platform can be reduced to a thin one by freezing it and letting teams leave. Going the other way takes quarters (Assumption). Moving ten teams from their own stacks to one road needs the platform team to help each team move.

How each level answers

The question is: "We have 10 product teams. Should we build a platform team?"

SDE-1: A platform team builds common tools so product teams do not build them again.

SDE-2: With 10 teams each building their own pipelines, I would make a platform team, so teams ship faster and use the same security checks.

Senior: In my model a platform of 4 engineers costs Rs 12 million a year. It saves each team 0.72 engineers, or Rs 2.16 million. Break-even is 6 teams, so at 10 we gain Rs 9.6 million. I would watch the queue. 40 requests a month against a capacity of 26.7 grows a 3-month wait, so I build self-service first. The fallback is an opt-out path.

Staff: I treat the platform as a product with customers, a roadmap and metrics. I would start thin, with volunteers, and fund a full team at about 6 teams or 15% of time on infrastructure. I would ask engineering leaders to agree on what is mandatory (security controls) and what is optional (language). I measure voluntary use, time to first deploy, and the share of team time spent on infrastructure. I revisit it each year, and when a new kind of team, such as a machine learning team, arrives.

Say it in the interview

With 3 teams I would let each team own its stack and share a template. In my model a platform team of 4 costs about Rs 12 million a year and saves each team about Rs 2.16 million. So it pays back at about 6 teams. I would start thin and optional, build self-service so the queue stays short, and make it mandatory only for security controls.

Common mistakes

• Building a platform team at 3 teams. In the example the cost is Rs 12 million and the saving is Rs 6.48 million.
• Running the platform through tickets. The queue grows without limit, and teams find ways around it.
• Making the road mandatory on day one. You do not yet know what teams need. Make it the easy choice first.
• Counting only cost. Faster moves between teams and the same security controls are benefits that do not show in the table.

Sources

• Team Topologies, key concepts: platform teams create services that accelerate stream-aligned teams; overloaded teams make poor decisions and move slowly; most internal platforms become bloated, hence the thinnest viable platform; three interaction modes (collaboration, X-as-a-service, facilitation). https://teamtopologies.com/key-concepts (opens in a new tab) (checked 26 Oct 2026)
• The salaries, team sizes, time shares (20% and 8%), the number of moves and requests, the capacity of the platform team and the 15% and 70% triggers are our assumptions. The break-even of 6 teams, the savings and the queue figures are our calculations, shown above.