Why Tencent’s EPC Initiative Failed: Lessons from DevOps and Middle‑Platform Missteps

Tencent launched a massive technology transformation in 2019, focusing on DevOps and middle‑platform construction.

Middle Platform Construction

Inspired by Alibaba’s middle‑platform model and the book *Enterprise IT Architecture Transformation*, the author notes that building or dismantling a middle platform is a product of specific historical stages; ignoring business and market context leads to empty rhetoric.

Critics—often product‑oriented people—raise two main concerns:

Middle platforms become tools for engineers to claim territory and promotions, leaving messy leftovers and no real efficiency gains.

Some argue that platforms become bottlenecks when business scales faster than platform delivery, reflecting a fundamental misunderstanding of the platform’s purpose.

From two years of hands‑on experience, the author suggests:

Build platforms with a product mindset—optimizing overall efficiency rather than being all‑encompassing.

Clearly define which functions belong to the platform and which stay with the business; mis‑aligned thickness leads to conflict.

DevOps

Tencent’s DevOps journey (2019‑2021) was marred by the infamous EPC (Engineering Productivity Certificate), which many misunderstood.

Before EPC, the concept of EP (Engineering Productivity) is defined by Google as a data‑driven discipline that optimizes the engineering process to deliver better user experiences faster.

What is Engineering Productivity? We are a data‑driven engineering discipline focused on optimizing the engineering process so that Google can deliver amazing experiences to our users, faster.

In plain terms, it means using data‑driven methods to streamline engineering so Google can ship faster.

EPC defines 12 measurement items, each with five maturity levels, covering product requirement breakdown, code quality, automated testing, CI/CD, release efficiency, post‑release operations, and product effect analysis.

The author observes two guiding principles that were poorly executed:

Not every item needs to be pursued; select improvements wisely.

Higher levels are not always better—choose levels that fit your context.

The core from a development perspective is shifting quality left and automating the development pipeline.

Quality left‑shift means catching defects early through code review and extensive automated testing.

Automation replaces manual testing, compilation, packaging, deployment, and post‑deployment checks, reducing human error and increasing efficiency.

Software development constantly balances quality, efficiency, and time; the author’s stance is:

Within an acceptable quality threshold, strive for maximum efficiency.

After decades of agile, testing, CI/CD, and other practices, the author notes little truly novel theory has emerged recently.

Based on the author’s experience with the Weishi backend, a concrete DevOps implementation path was proposed but has not yet been realized.

A Feasible Execution Idea

Key requirements include:

Platform tools must support full binary lifecycle operations and releases.

Environment requirements : Separate dev, staging, and production environments; strict canary deployment matching production.

Canary traffic routing with two strategies (edge‑level isolation or internal routing) and multiple traffic‑selection methods.

Fault detection using platform monitoring, system‑level metrics, and business metrics within 1‑5 minutes.

Fault recovery allowing rollback to the previous stable version within 5 minutes.

EPC

Programmers are essentially craftsmen, so management pushes for higher engineering efficiency through agile, automated testing, CI/CD, and other practices.

Since the rise of large language models in 2023, tools like Copilot and ChatGPT can write code faster and adapt to any style, creating a genuine efficiency crisis for developers.

Tencent’s EPC rollout aimed for world‑leading standards, but resulted in widespread dissatisfaction:

Product managers complained about slower efficiency and reduced manpower.

Developers faced unchanged timelines with increased workload—more code reviews and unit tests.

Tools were cumbersome; pipelines often stalled, wasting time.

Frequent EPC assessments forced teams into short‑term “boosts” to maintain scores.

Changing EPC rules required massive rework to keep levels from dropping.

Personal observations:

Tooling was incomplete; EPC ratings relied on manual evidence, leading to inconsistent assessments.

EPC scores tied to performance reviews caused turnover and bizarre workarounds (e.g., fake test functions to inflate coverage).

Many teams attempted DDD/TDD without sufficient skill, treating them as slogans.

The author believes EPC is a valuable set of efficiency metrics, but teams should select relevant indicators and improve them purposefully rather than chasing higher levels for their own sake.

Success factors for improving engineering efficiency include:

Management and culture : Policies link EPC to performance, but acceptance is low without long‑term vision.

Tool support : Automated testing, CI/CD pipelines, and accurate fault detection are essential.

Reasonable measurement : Metrics must drive improvement, not become an end in themselves.

People and training : Diverse technical skill levels and immature infrastructure hinder rapid adoption.

Technical consistency : Fragmented tech stacks across business units make unified platform implementation difficult.

EPC itself is not wrong, and improving engineering efficiency is worthwhile, but misaligned management, insufficient tooling, skill gaps, and premature timing hinder success.

Current CI/CD/CO efforts are forming a new platform; with persistence, the previously mentioned capabilities may become achievable.

Winning the strategy but losing the execution.