From QA to Engineering Productivity: Reflections on Building an EP Team

Author: Gao Lei, Technical Director of Wandou Lab. Published in "Programmer" magazine, August 2013.

Two or three years ago I worried about the future of QA (software quality assurance) as a discipline and a team; now I have the chance to put my ideas into practice and share them.

From my limited experience I have witnessed many shifts in software development models, driven by trends or real problems, leading QA teams from process focus to automation, then to agile and continuous integration, raising expectations while confronting a recurring organizational curse.

Organizational Development Curse

This curse often starts at any point in the organization.

For example, senior technical leaders may deem testing unimportant, which trickles down, compressing career space for testers, raising skill demands while limiting growth, creating a perception of QA as a low‑tech team. To counter this, teams build automation frameworks, yet the disconnect between QA value and company vision widens, reinforcing the low‑tech image.

This cycle is common in many software R&D organizations.

Our practice broke the cycle by essentially eliminating the traditional QA team, freeing QA engineers and the entire development process.

Basic Values

We start with fundamental values.

First, take ownership: each project has an Owner acting like a CEO, responsible for product, development, testing, and operations, making the project independent of platforms and focused on features.

Second, define quality by impact: a severe issue is one that causes real impact; minor issues with wide impact are also serious.

Third, balance perfect delivery with rapid rollback mechanisms, recognizing that perfect products are unrealistic in fast‑moving internet markets.

These values guide our development improvements, leading us to form the EP team.

What is EP

EP stands for Engineering Productivity, a tool‑focused team that aims to boost the efficiency of the entire technical organization.

We define productivity levels: 1) quality as the foundation, 2) speed given equal quality, 3) engineer happiness through automation, and 4) growth through continuous problem solving.

What EP Does

EP follows a three‑stage approach: replace, teach, and become independent.

In the replace stage, EP temporarily performs testing, deployment, and operations for developers.

In the teach stage, EP trains developers to test, build environments, and operate their own services using standardized tools.

In the independent stage, EP evolves into a product team delivering robust, standardized services rather than labor.

EP Team and Its Relationship to the Rest of Technology

EP is likened to an automobile manufacturer providing efficient tools, while product teams act like logistics firms using those tools to deliver value.

Both depend on each other yet remain independent.

Who Is in the EP Team

The EP team consists of several roles:

SED (Software Engineer in DevOps): multi‑skill engineers handling automation, CDN deployment, Windows build acceleration, etc.

SA (System Admin): focuses on system‑level work, automating monitoring and deployment to free developers.

TE (Testing Engineer): manages release channels (Beta, RC, Release) and automates publishing processes.

Venders: an on‑site outsourced testing group that gradually reduces as automation improves.

UOE (User Operation Engineer): bridges user feedback with technical resolution, building tools for operations.

EP Working Style and Challenges

EP takes on unassigned tasks, supports all teams, and operates without long‑term plans, using OKR‑style objectives such as “Smoothly & Fast” and “Self‑service”.

Challenges include lack of personal achievement, risk of over‑engineering, hiring difficulties, need for experience‑driven improvement, dependence on overall team maturity, and ensuring owners take responsibility.

Why We Can & Why You Can

Success factors include a lean startup team, a culture of freedom and responsibility, operating in the internet industry with rapid product iteration, fast‑changing business models, decisive commitment to change, and high standards for team members.

These principles can be applied by other organizations seeking to build an Engineering Productivity function.