How to Build a Culture of Continuous Improvement
Continuous improvement is not a value on a wall. It is three concrete disciplines: frameworks that scale with complexity, metrics that make progress visible, and a culture that treats urgency and ownership as the default rather than the exception.
Most organizations say they want continuous improvement. Few build the operating conditions that produce it. Improvement is not a mindset you install with a slide; it is the output of a system, and that system has to be designed the same way any other piece of infrastructure is designed: deliberately, with clear ownership, and with feedback loops that catch drift before it compounds. Across Wear OS, Pixel Watch, and now the AI research programs at the Chan Zuckerberg Biohub, the organizations that improved fastest all shared the same three disciplines.
Build frameworks that scale with complexity, not just headcount
Most program management frameworks are built for the org that exists on the day they are written. They fail quietly as the org grows, because growth changes two variables at once: more people, and more technical complexity per person. A framework designed only for headcount buckles the first time a program spans distributed GPU training, multiple research tracks, and a hard external commitment simultaneously.
The frameworks that hold up share a structural property: they are built around decision rights and interfaces, not around org charts. Define what decisions each layer of the organization can make without escalation, define the interface each team owes the teams downstream of it, and the framework keeps working as both the team and the technical surface area grow. When Wear OS scaled from a single OS release to coordinating 22 product teams and multiple hardware partners at once, the release process that survived was the one built on stable interfaces, not the one built on a fixed set of people who knew where the bodies were buried.
Scalable also means versioned. A framework that cannot be revised without a reorg is not a framework; it is a habit wearing a framework's name. Build in a review point where the framework itself gets evaluated against the complexity it is currently facing, not the complexity it was designed for.
Define and track the metrics that make improvement visible
You cannot improve what you have not defined, and you cannot sustain improvement on metrics nobody is tracking. The organizations that actually get better over time track three categories deliberately: execution quality, predictability, and efficiency, and they track them as trends, not snapshots.
Execution quality asks whether what shipped matched what was committed: defect rates, post-launch incidents, rework required after a milestone was called done. Predictability asks whether the organization's estimates can be trusted: variance between committed and actual dates, the frequency and size of slips, how often a program surprises leadership versus how often it was flagged early. Efficiency asks what it costs to produce a unit of progress: cycle time from decision to shipped outcome, GPU or engineering capacity spent per milestone, the ratio of coordination time to execution time.
In my last team at Google, I introduced a release-quality metric by adapting a Six Sigma manufacturing discipline: defects per million opportunities (DPMO).
While manufacturing defines an opportunity as a specific point where a defect could occur, I redefined it as a single line of code. This allowed us to track Defects per Thousand Lines of Code (DTLOC) as a standardized release-quality benchmark. This metric remains comparable release over release and team over team, regardless of the release size.
Ultimately, the specific unit mattered less than the discipline it established. Every team now has a concrete metric to hold itself against, eliminating subjective assessments of whether a release "felt buggy."
A metric nobody reviews is decoration. A metric that changes a decision is infrastructure.
The discipline is not in choosing the metrics; it is in reviewing them on a fixed cadence and acting on what they show, including when they show that a process you are attached to is not working. Benchmarks matter here too: a metric in isolation tells you the direction, but a benchmark against your own past performance or a comparable program tells you whether the pace of improvement is actually adequate.
Make urgency and ownership the default, not the exception
Frameworks and metrics only compound if the culture around them rewards acting on what they reveal. That requires urgency and ownership to be defaults, not qualities you have to invoke for the important programs. Urgency means treating a metric that moved the wrong direction as a signal to act this week, not at the next quarterly review. Ownership means every gap has a named owner accountable for closing it, not a team that collectively hopes someone gets to it.
The fastest way to kill this culture is to punish the people who report bad news early. The fastest way to build it is the opposite: make it visibly safer and more rewarded to surface a problem in week two than to let it surface itself in week ten. Teams that internalize this stop waiting for permission to fix what the metrics show is broken, and continuous improvement stops being a program and starts being how the organization defaults to operating.
This is also where scalable frameworks and tracked metrics reinforce each other. A framework with clear decision rights gives ownership somewhere concrete to attach. Metrics reviewed on a fixed cadence give urgency a trigger instead of a vague aspiration. Culture is what happens when both are in place long enough that acting on them stops requiring a champion.
The flywheel
None of these three disciplines works in isolation. A framework without metrics has no way to know if it is still fit for purpose. Metrics without a culture of ownership become a report nobody acts on. A culture of urgency without scalable frameworks burns people out chasing problems the system should have prevented. Together, they form a flywheel: the framework creates the conditions for clean measurement, the measurement creates the evidence urgency needs, and the culture of ownership feeds improvements back into the framework. Organizations that build all three simultaneously do not just get better once. They build the machine that keeps getting better on its own.