the death of platforms

Over the past three years, I worked on various mobile SDKs in a platform team at a large company, witnessing the team’s rise, growth, and decline. Recently, I transferred to a business team due to a new opportunity. After four months, my recent experiences have formed a stark contrast with my previous team’s way of working.

So I want to summarize my experiences from the past few years and discuss the topic of “The Death of Platform Teams.”

Looking Back

This afternoon, while browsing my former team’s chat group, I saw the sprint planning board. Combined with recent events, the phrase “the platform is dead” that I had heard before suddenly became tangible. Here’s what happened: due to declining company revenue over the past year, management decided to drastically cut costs. Business teams’ budgets were slashed heavily, and the platform team began considering cost savings from every angle:

The platform team’s headcount was frozen. First, those with previous PIP (Performance Improvement Plan) records were laid off, followed by those in redundant positions.
The team’s output was counted as the company’s operational cost, so the support team’s sprint task scheduling was strictly controlled. All task scheduling was required to serve business needs only. New technology research and technical debt cleanup were no longer allowed in sprints (unless these tasks could directly prove they would bring business benefits).
Every sprint’s task schedule was strictly reviewed to ensure all development time was reasonably utilized. However, due to point two, developers found it difficult to have enough tasks to fill all their time in each sprint.
Based on points two and three, project managers would decide whether there was resource redundancy based on sprint scheduling, and if redundancy existed, layoffs would be considered.

This series of actions dealt a huge blow to team morale. Everyone was worried about being the next person to be laid off. The platform team’s position in the company was already awkward—it was a support team serving business teams directly, but it didn’t directly create business value. Therefore, the company’s investment in the platform technical team was limited, but the demands were harsh:

Whenever mistakes occurred during feature delivery/support, business teams had the right to demand post-mortems from the platform team, and in severe cases, require punishment for those responsible. Regardless of how these review meetings were dressed up, they were essentially about punishing mistakes through public criticism and humiliation (every time I think of such meetings, I’m reminded of China’s Cultural Revolution in the 1970s). This directly affected the platform team’s work atmosphere—everyone was afraid of making mistakes and felt insecure.
Operations-led: Yes, there was a layer of “Platform Operations - Business Operations” roles between the platform technical team and business teams. All requirements and tasks were assigned to the technical team by operations, and the technical team had no say. The technical team could only passively accept tasks and couldn’t proactively plan or drive technical development. However, operations decisions were often based only on short-term business needs, lacking understanding and planning for technical development, preventing the technical team from long-term technical accumulation and innovation.
Information from upper management was essentially a black box. The technical team had difficulty knowing the company’s future strategic direction and technical planning, making it impossible to prepare in advance. Most of the time, they could only reactively respond to business requirements.
- This was partly due to the team structure itself, with operations as a middle layer;
- It was also because some managers treated this information asymmetry as a natural source of power, using it to control and manage subordinate teams. I witnessed more than once that when something contained parts (A+B+C), management would only tell the technical team about part A, while parts B and C were either hidden or modified into different versions.
Forget personal development. Team members in this structure would become expendable, with no opportunities for transfer or promotion. This is probably a common problem in most Chinese companies: when hiring for a position, HR and management only focus on the candidate’s current skills and experience, ignoring their long-term development potential and career planning.

Actually, “the death of platform teams” is a well-known concept, with this obvious trend starting around 2020. However, with the explosion of AI technology in recent years, the process of middle platforms moving from twilight to the grave has accelerated. Now we’re just putting up the tombstone 🪦.

Let me summarize the key points of “The Death of Platform Teams”:

The Paradox of Resource Redundancy:
- The most awkward thing about platform teams is that if you make the system robust enough and highly automated, you no longer need as many people; if you don’t do well enough, business teams will question your value due to frequent failures. This paradox of “the better you do, the faster you die” is the root cause of morale collapse.
The Moat of Power: Information Asymmetry
- When facing layoff pressure, middle managers or intermediate teams often monopolize information to ensure their indispensability.
- They prevent technical teams from understanding the big picture to turn team members into “pure execution tools.” This way, even if some people are laid off, as long as the information hub (management themselves) remains, the business can limp along. This approach protects management positions in the short term but destroys the entire technical ecosystem in the long term.
“Operations-Oriented” is Poison for Technical Development:
- Short-termism: Operations KPIs are usually weekly or monthly, while underlying technical optimization (such as refactoring, performance improvements) operates on quarterly or even annual cycles.
- Mismatch: Under this structure, technical staff cannot accumulate business intuition nor dive deep into technical depth. This two-way mediocrity eventually turns the entire team into “tools” and “expendables.”

Once a technical team loses the right to define products and becomes “operations’ handyman,” its professional vitality is over.

So after the platform dies, who takes on its responsibilities? There are essentially four points:

The proliferation of professional third-party service platforms. Many platform functions can actually be achieved through third-party services, such as push notification services, analytics services, user authentication services, etc. By using these professional third-party services, business teams can save substantial development and maintenance costs while obtaining better service quality and user experience.
The rise of AI technology. Many modules that platforms previously provided—requiring significant development effort to integrate, such as login/compliance/recommendation functions—can now be rapidly integrated into business systems by project teams using mature open-source solutions, with AI development tools greatly improving development efficiency.
Compliance/risk control related matters are split into corresponding smaller, more flexible business teams. Compliance provides compliance advice and guidance, while risk control provides unified risk identification work. (Such teams should be very small because they’re vertical to specific scenarios.)
Will the atomic small teams mentioned in point three always exist? I personally believe it depends entirely on future industry development and whether there are more efficient ways to implement these functions. If better technical means or service platforms emerge in the future, these small teams may also be further consolidated or eliminated.

These four points essentially all belong to the sinking and outsourcing of capabilities. The core value of platform teams lies in integration and reuse capabilities, but as technology develops and markets change, these capabilities become increasingly easy to obtain through external means, so they will gradually be stripped away.

Looking Forward

Having discussed the various limitations of platforms above, what should technical teams that fit this era look like? Let me share what my current small team’s work includes:

Building a complete Flutter application supporting both iOS and Android platforms, providing chat/speech recognition/TTS/social feed/login and corresponding UI components.
Independently developing a Vue3+TS admin dashboard supporting permission management/data reports/content moderation and other features.
CI/CD pipelines for both projects mentioned above.
Oh, and learning Flutter wasn’t just about using it—I thoroughly read through the Flutter framework layer source code and produced two technical articles.

Transforming from a cog (or even just a thread) into an engineer who needs both technical breadth and depth to solve larger directional problems—this is the biggest identity transformation and challenge when jumping from a platform team to a real agile team that fits this era.

Finally, a complaint: When I heard we needed to integrate SDK modules from my previous team, my main concern was “Will this SDK module slow down my development progress? Will it increase my maintenance costs?” rather than “Can this module meet business needs? Can it help me save development time?” 😂

Previous Next

TOC