Scaling DevOps in Large Organizations: Normalization, Standardization, and Platformization

Below is my personal experience summary. One hundred people is a critical threshold for organization management, at which point the demand for scalable efficiency improvements emerges, making it representative.

Although DevOps practices have been widely understood and accepted for a decade, many organizations still struggle to expand DevOps successfully to more teams, and DevOps often fails to scale further.

One reason is that most enterprises have misaligned organizational structures, goals, and incentive mechanisms, and lack a sense of responsibility or ownership for the outcomes they should drive.

Three Primary Steps

When a software organization exceeds a hundred people, merely copying a set of DevOps practices cannot embed the culture advocated by DevOps; structural adjustments are required to optimize the way teams work.

However, before structural adjustments, it is often necessary to go through three steps, as shown below.

1. Normalization

DevOps emphasizes the importance of measurement. In reality, most software enterprises lack directly measurable engineering management. The same engineering activity often yields different results depending on the executor, making the quality of an activity heavily dependent on whether the executor is reliable.

This approach is acceptable in the early startup phase, but as the business scales rapidly and personnel increase, it leads to a noticeable decline in production efficiency.

During rapid growth, the enlarged team renders previous information‑transfer methods ineffective; new members bring their own default standards for each engineering activity, which may differ from the company’s consensus. Even the same type of activity can vary across teams due to different leader styles.

Therefore, normalization is needed to eliminate unnecessary waste caused by inconsistent information transfer and unstandardized execution.

Normalization is the process by which organization members jointly establish a new collaborative consensus.

For example, standards are defined for activities such as requirement analysis and breakdown, software quality verification, and deployment processes, limiting basic actions and output requirements. Due to historical reasons, multiple sets of standards may exist for the same domain to address different scenarios.

When normalization reaches a sufficient level, effective measurement becomes possible.

2. Standardization

Once effective measurement is feasible, the next challenge is to achieve verifiable, effective metrics.

Through normalization we can collect data (mostly manually gathered and aggregated) to guide DevOps improvements, which creates a further management demand for more detailed data to drive refinements.

For instance, why do two teams show large differences on the same metric? Are the differences caused by anomalous data due to human involvement, or do they stem from genuinely different scenarios? Are the scenario differences driven by distinct business needs or other factors?

Thus, each engineering activity’s downstream scenarios are analyzed, the normalized content is modeled, and a digital process model is extracted, with appropriate tooling support in each professional engineering domain.

Standardization is the manifestation of an organization’s effective measurement capability.

3. Platformization

When the organization further expands, platformization becomes necessary to cope with the additional management costs brought by personnel and production scale.

At this stage, integrating multi‑domain platforms solves information‑flow inefficiencies across engineering stages, enabling scaling up so that business growth outpaces personnel growth, or at least does not noticeably hinder scale‑up benefits.

Remarks

Initially, rapid expansion leads to inefficiency because people act inconsistently. Through the first two stages, each workflow’s collaborative outcomes and delivery quality become predictable and partially controlled, thereby solving the “collaboration trust” problem between people.

The third step’s connectivity, built on the resolved trust issue, further links digital tools to create an integrated platform, eliminating information‑dependency between individuals in earlier stages and introducing richer, effective measurement items.

In theory, the three steps can be merged into one, but the resistance faced by the organization is high, resulting in a low success rate; however, the theoretical possibility still exists.

Promotional Notice

Teacher Qiao Liang is launching a video course “Continuous Deployment Bootcamp (Python Version)” with a limited‑time special price! This course helps you improve software development efficiency and quality, reduce deployment pain, and master building‑test‑deploy pipelines, incremental feature releases, and database schema changes through theory and hands‑on practice.