Round Table: Platform Teams — Value or Hype?

Filipp defines a platform team through the work other developers need done. It creates a shared abstraction, much like a library that replaces repeated code. A company should not need five different release processes or a separate approach to testing in every team. Alexander starts from scale: product teams share work on release pipelines, infrastructure, libraries, and components. A platform team emerges when solving those problems together becomes more useful than maintaining separate implementations.

Mergers and acquisitions provide another reason: infrastructure and systems from several companies need to be brought together. Andrey, speaking from operations, adds a key criterion: a platform should make product teams autonomous. Its tools should let them work without constantly negotiating with neighbouring teams. Pavel describes a broader group consisting of SREs supporting production, developers building shared services, and a load-testing team. Their customers are internal technical specialists, and their work concerns development speed and reliability.

The host asks how this differs from an ordinary team of administrators. Andrey acknowledges the risk of simply renaming operations. If a developer still negotiates separately to obtain monitoring, alerts, and a release, the path to production remains complicated. A platform should provide those capabilities as a service. Sometimes clear instructions are enough for a team to get the result independently. Filipp adds that infrastructure is only one kind of platform: his team works on analytics, event collection, and storage.

At very large scale a platform becomes necessary, but the participants offer no universal headcount threshold. It makes little sense to say one is required at fifty employees but not at forty-nine. Filipp uses Avito as an example: once several product teams exist, shared release and testing work needs coordination. Repeated processes and a real need for common solutions justify the investment. A few engineers wanting to build an interesting internal product is not enough.

Alexander saw a platform team emerge organically with only fifteen to twenty developers: several strong engineers took responsibility for shared components intended to replace part of the existing stack. It no longer met their needs for performance, maintenance cost, or feature delivery speed. His other example is a group of companies with multiple business divisions and separate IT departments. A dedicated base-technologies unit was established to align engineering approaches and infrastructure.

How can non-functional requirements be handed to people who neither know the domain nor wrote the product code? The discussion suggests starting with shared infrastructure and metrics: release frequency, lead time, reliability, and cost. A common approach can develop gradually. Some improvements need no product-code changes at all; adjusting infrastructure and its configuration is enough. Creating the team does not by itself demonstrate that it removes the right constraint.

Metrics depend on the service. For Filipp’s analytics SDK, event loss, internal product adoption, and developer feedback matter. In his example, adding a new event once took up to several days and now takes less than an hour. Alexander returns to the original goal: splitting a monolithic front end and introducing a micro-frontend shell enabled teams to release changes and run experiments independently. The migration cost was counted separately; releases per day were among the infrastructure team’s measures.

Andrey evaluates an environment-provisioning service with straightforward questions: does it succeed on the first attempt, how long does it take, and does it fail? Repeated questions in the chat can expose gaps in documentation. Pavel categorizes infrastructure-chat requests and service-desk tickets weekly to identify where an instruction would help and where software is needed. Taking a support shift makes the cost of manual work visible and motivates engineers to give developers the means to perform those actions themselves.

Pavel also tracks repetitive manual work, cloud cost, and availability over a rolling four-week window. Infrastructure spending pushed the team to address service architecture. The participants justify this work to the business differently: Alexander talks about technical debt and a “technology mortgage,” while Andrey points to a specific pain removed. Showing which work became easier and what it cost is more useful than defending the abstract idea of a platform.

The closing question is how to recognize that the work is finished. Filipp describes a team that still has small requests in its backlog but has solved its original major problem. It is looking for the next substantial need. Alexander sees this as a successful conclusion: if a product is ready and used, a strong team can move to the next constraint instead of polishing a working tool indefinitely. A completed assignment does not mean the company no longer needs its engineers.

The opposite case is a tool that exists but whose intended users reject it because of quality or reliability. Alexander recommends acting on feedback rather than mandating adoption. If the team cannot change the outcome, its composition may need to change; he recalls doing this with a small group. Andrey also ties a platform’s future to demand for its services and the needs of the business. A changed business model may mean that the existing platform no longer addresses the right problem.

The participants also consider decentralization: engineers join product teams while shared knowledge survives through a professional community or a small central group. Disbanding therefore needs a plan for the service and its knowledge. Criteria agreed when the team was formed help distinguish completion from failure. In the first case the team chooses the next useful assignment; in the second, it investigates why the service is unwanted or does not meet users’ needs.