Processes, Checklists, and Experience Repositories: Externalizing Intelligence into Systems

Our leader module has already covered a lot about institutional building, but a company is not merely composed of “people” and “institutions.”

Institutions address rights, responsibilities, benefits, and incentives and constraints: they enable a group of people to collaborate willingly, prevent fraud and mischief, and direct individual efforts towards the company’s interests. But what exactly to do is another matter. For a company to become a highly efficient machine for making money or accomplishing tasks, it must have another “third thing” in addition to its institutions.

You must have long heard of some related terms, such as processes, SOP (Standard Operating Procedure), checklists, best practices, Playbooks, and even organizational intelligent agents. Perhaps we can view them as different forms of the same thing, which we might collectively call “cogware.”

Just as hardware and software reside within a machine, cogware is the intelligence embedded within an organization.

Cogware precipitates methods, standards, and experience. If you imagine a company as an intelligent agent operated by people, then methods are “skills,” standards are “guardrails,” and experience is “memory”: together, they enable an organization to know how to do things, do them correctly, and get better at them over time.

Institutions ensure an organization isn’t chaotic; cogware ensures an organization isn’t foolish.

Ideally, instead of cogware accommodating people, people should serve the company’s cogware system: obeying, maintaining, refining, and upgrading this system. People may come and go, but the system forever grows.

The cogware system is composed of skills, guardrails, and memory; let’s discuss them one by one.

Skills: Transforming Intent into Stable Action #

“Skills” define how everyone should act when tasks arise.

Processes, SOPs, Playbooks, operational guidelines—these are all skills, differing only in their granularity: a process dictates how a task flows between departments, an SOP specifies how a particular role should operate, and a Playbook outlines strategies for a certain type of scenario. They all address how to transform intent into stable action.

The keyword is “stable.” A skill is a script, or rather, a playbook, essentially an organization’s causal hypothesis: if we perform these actions in this sequence, by these roles, at these checkpoints, we can consistently achieve the desired outcome.

Economists Richard Nelson and Sidney Winter, in their study of organizational evolution, likened organizational “routines” to a company’s genes: companies don’t start from scratch every morning, figuring out how to work; they preserve their capabilities through a set of repeatable skills [1].

Put simply, you cannot just “wing it.” You are truly part of the company when you operate by established rules; only with established rules is it a legitimate company.

For example, by 1999, Huawei was already a star enterprise, yet it had some unflattering figures: its on-time order delivery rate was only about 50%, while international peers achieved 94%; inventory turned over 3.6 times a year, compared to 9.4 times for others; and Huawei’s R&D return on investment was only one-sixth that of IBM [2]. It wasn’t that Huawei’s people weren’t smart—quite the opposite, at that time, Huawei relied entirely on brilliant individuals tirelessly putting out fires, and heroism was rampant. But heroes cannot bear the weight of scale; once a company grows large, it can no longer depend on the intelligence and ingenuity of a few individuals.

Ren Zhengfei’s diagnosis was that the company lacked not talent, but skills. So he heavily invested in bringing in IBM to teach Huawei “Integrated Product Development (IPD).” This was a script for product development actions: from requirements, project initiation, and R&D to delivery—who does what, when, with whom to align, and by what standards to pass—all written as repeatable, callable methods.

To ensure Huawei transformed into a company with skills at its core, Ren Zhengfei established a famous policy: “First become rigid, then optimize, then solidify.” “Rigid” meant copying exactly; no unauthorized improvements were allowed in the first few years! In Ren Zhengfei’s own words: “We must first buy a pair of American shoes; if they don’t fit, we will cut our feet to fit the shoes.” [3]

Why such an extreme approach? Because Ren Zhengfei understood that once an enterprise reaches a certain scale, individual intelligence must be translated into skills; otherwise, that intelligence will be swallowed by scale. Small teams rely on tacit understanding, large organizations rely on interfaces.

A company lacking skills will exhibit several characteristic symptoms: nothing moves until the boss prods it; customer information is repeatedly lost; everyone has their own way of doing the same task; departments blame each other; newcomers don’t know whom to approach next…

You might think it’s the people who are incapable, saying “we’re just an amateur troupe,” but in fact, it’s not the people, but the lack of established company-specific skills.

But skills only ensure things get done, not whether they are done correctly. A process without guardrails is like a conveyor belt that “pushes things forward regardless of right or wrong…”

Guardrails: Ensuring the Correctness and Safety of Actions #

“Guardrails” answer a different kind of question: How do we know it’s done correctly? What absolutely cannot go wrong?

Checklists, quality standards, acceptance criteria, risk redlines, review thresholds—these are guardrails.

When I mention checklists, you might think they’re just crib sheets for beginners, right? Listing what to do first, what to do second, like a travel guide. What you’re describing is an SOP; that’s not the full purpose of a checklist. The function of a checklist is not to tell you how to do something, but to prevent you from making mistakes: you might already know a task has 18 steps, but you often miss one or two—if someone is there reading out the checklist to you, you can ensure the entire operation is flawless.

A 2009 study published in The New England Journal of Medicine showed that the World Health Organization implemented a 19-item surgical safety checklist in 8 hospitals across 8 countries, reducing surgical mortality from 1.5% to 0.8% and complications from 11% to 7% [4]. The items on that checklist were simple to an almost “insulting” degree: confirm patient identity, confirm surgical site, confirm allergy history, count sponges and instruments… This demonstrates that even the world’s most highly trained surgical teams can “fumble” in these areas.

Errors often stem not from ignorance, but from fatigue, interruptions, rushing, and “I thought you had checked.”

Executing a checklist requires a sense of ritual and ensuring the entire team is synchronized. For example, a crucial item in surgical checklists is for everyone to pause before the incision and verbally confirm together. From that moment on, the lead surgeon, anesthesiologist, and nurses enter the same task world. Many accidents don’t happen because no one knew, but because A thought B knew, and B thought C would check.

Any irreversible operation must have guardrails beforehand. Before signing contracts, before making payments, before launching, before deleting data, before making external statements—always stop, observe, and confirm one more time. The checklist is an organization’s deep breath at the edge of a cliff.

Guardrails must be short and firm, with each item observable and confirmable. “Whether carefully checked” is not a checklist item; “Is the contract amount consistent with the quotation?” is a checklist item.

A checklist doesn’t eliminate judgment; rather, it provides “cognitive offloading” [5], reducing the brain’s cognitive load through external actions. The checklist remembers these trivial matters for you, freeing up your attention for other thoughts. A bad checklist says: “Don’t think, just do.” A good checklist says: “Don’t forget these few things; for the rest, please use your judgment.”

Guardrails don’t significantly increase operational costs, but a company lacking them will present the following picture: contracts are signed only for pitfalls to be discovered later, products are launched only for tests to be found unrun, and employee permissions remain unrevoked half a year after their departure.

Memory: Accumulating Experience, Driving Organizational Learning #

“Memory,” then, is fundamental to organizational learning.

The memory referred to here is a noun, not a verb; it’s not individual recollection, but the distillation of predecessors’ experiences. A company’s memory includes best practices, failure case studies, post-mortems, experiment records, and knowledge bases. Experts don’t just read experience repositories to copy them; they do so to stand on the shoulders of giants and extrapolate from them.

The term “best practice” sounds like an optimal solution, as if it can simply be copied and applied—wouldn’t that just be an SOP? In fact, a best practice is “a proven approach within a specific context”; it’s embedded within a team’s culture, customer base, and incentive structure. Management scholar Gabriel Szulanski conducted a famous study showing that not only is it difficult to copy best practices from other companies, but even within the same company, a good practice from one team often fails when transferred to another. He termed this the “internal stickiness” of knowledge [6].

This is the “organ transplant disease” of many companies: they see others succeed with OKRs, so they adopt OKRs; they see others hold stand-up meetings, so they hold stand-up meetings… Unbeknownst to them, the organ might be good, but their body will reject it.

The correct use is to treat best practices as a transferable causal structure, extracting their mechanisms and preconditions, then adapting them locally: Why is it effective? What conditions does it depend on? For my context, what should be retained, and what must be modified?

Failed experiences are even more valuable memories because they can directly improve your cogware system. The best example of this, which you might not expect, is China’s space program.

In the early morning of February 15, 1996, the Long March 3B rocket made its maiden flight in Xichang; its attitude control was lost two seconds after ignition and liftoff, and 22 seconds later it crashed into a hillside and exploded. Those were some of the darkest years for China’s space program: since 1992, Long March rockets had suffered successive failures, and their credibility in the international commercial launch market had plummeted.

This past might not have been widely publicized because it was inglorious, but China’s space program learned real lessons from it.

In desperation, the space program established a rule called “closed-loop problem solving” (归零): any quality issue, no matter how minor, must be “closed-loop solved” before approval.

“Closed-loop problem solving” has five requirements: accurate localization, clear mechanism, problem reproduction, effective measures, and generalization [7].

The first four points establish an irrefutable case for a single problem: locate the exact position, clarify the underlying mechanism, reproduce the fault in front of everyone, and then prove the improvement measures are truly effective. The fifth point, “generalization,” is the soul: solving one problem is not enough; you must conduct a system-wide investigation—all similar designs, processes, and links must be updated accordingly.

In modern terms, this is iteration. An accident must become a system upgrade.

The “closed-loop problem solving” system led to the subsequent long string of successful records for the Long March rockets. In 2015, the International Organization for Standardization issued this method as international standard ISO 18238 [8]. In essence, China’s space program turned its scars into a global textbook.

If a company commits the same errors multiple times, if it performs slightly better only when it miraculously finds a capable person, and if that person’s 20 years of experience walk out the door with them when they leave… then that company simply has no memory.

Skills, Guardrails, and Memory: The Lifecycle of a Good Method #

Skills, guardrails, and memory are not three parallel drawers; you can view them as three interconnected links that feedback into each other. Let’s look at the life of a good method.

Suppose, in your company, a salesperson discovers a new approach: instead of rushing to demo the product to large clients, first spend half an hour helping them calculate the costs—“See how much money your current old system loses unnecessarily each year, and how much our system can save you…” By calculating costs first and then demonstrating, the closing rate is significantly higher.

This could be called a “best practice,” but initially, it’s just a variation, a “wild approach” residing in an individual. In most companies, its fate follows the salesperson: if this guy gets promoted, the approach becomes a legend; if he leaves, the approach vanishes.

However, good companies allow good methods to complete their full lifecycle.

Step one, Experimentation. Test on a small scale: Is the approach effective, or is the salesperson just inherently skilled? Does it still work with another person? Which types of clients respond well, and which don’t?

Step two, Recording into Memory. If proven effective, document it according to memory’s guidelines—mechanisms, preconditions, boundaries, none can be missing, otherwise it’s just another “secret family recipe.”

Step three, Solidifying into a Skill. If the approach is consistently effective, encode it into an SOP: scripts, calculation templates, training materials. New salespeople can master 80% of an experienced salesperson’s capability within a week of onboarding. A best practice is validated experience; an SOP is codified experience.

Step four, Establishing Guardrails. If common errors are identified during execution, create a specific checklist for them.

Step five, Feedback. Review the results of each deal—what led to success, what caused failure—update memory, and memory then revises skills and guardrails. Thus, a closed loop is formed.

In evolutionary terms: innovation is mutation, experimentation is selection, and processes are retention. Thus, innovation and processes are not enemies at all; they are different stages of the same evolutionary cycle—

Innovation generates skills, processes solidify skills, checklists provide guardrails, and best practices precipitate memory.

Cogware from a Macro Perspective: The Scientific Revolution and Organizational Wisdom #

Broadly speaking, isn’t this precisely the essence of the Scientific Revolution? The scientific method is not a specific body of knowledge, but a set of cogware that allows intelligence to accumulate: experiments must be documented to the extent that others can reproduce them—this is a skill; peer review is a guardrail; academic journals are memory. A genius’s discovery does not vanish with their death; instead, it becomes the foundation for the next genius. The scientific method allows knowledge to compound.

In contrast, Song Yingxing in the late Ming Dynasty collected the most advanced agricultural and industrial techniques, compiling them into the three-volume, eighteen-chapter work Tiangong Kaiwu (The Exploitation of the Works of Nature), which could be considered an assembly of “best practices” of its time—yet this book never formed organizational memory. It was not included in Siku Quanshu (Complete Library in Four Sections), no one reprinted it, and by the mid-Qing Dynasty, it was almost unknown within China. Instead, it was published as a Japanese edition in 1771 and studied for generations, which is why we have the opportunity to see it today [9].

China has never lacked individual geniuses, but pre-modern civilizations lacked a set of cogware that allowed their genius to leave a lasting legacy.

Summary: The Significance and Three Stages of Organizational Cogware #

In summary, while a boss certainly manages people, a more important aspect of managing a company is managing the “value stream”: customer from where they enter → who diagnoses needs → who quotes → who delivers → who accepts → who collects payment → who renews. This chain is the company’s backbone, and departments are merely muscles attached to that backbone.

You must provide a stable skill for core operations, a guardrail for every irreversible node, and a memory for every success and failure.

If the company grinds to a halt the moment you go on vacation, that means skills haven’t been codified; if you consistently pay to remedy issues after they occur, that means guardrails are missing; if newcomers repeatedly fall into the same traps as experienced employees, that means memory hasn’t been established.

In the sense of cogware, an organization has three stages.

The first stage is the “person-led organization.” Everything prioritizes the boss’s intent; people do whatever the boss tells them, and if the boss doesn’t speak, things remain stagnant. This type of organization relies entirely on the master craftsmen’s skills, the veteran salespeople’s connections, and the boss’s overall vision. Business following individuals is a form of “personal dependency,” which inevitably leads to chaos as scale increases.

The second stage is the “process-driven organization.” It has skills and guardrails, with everyone performing according to prescribed actions. It’s stable, replicable, and scalable. The lifelong pursuit of most companies is to climb from the first stage to the second. If it stops at this stage, once processes become sacred, the organization will become rigid; everything will follow processes to seek exemption from responsibility, and work will turn into a compliance performance.

The third stage is the “learning organization.” Processes are not the final answer but the current version; checklists are not rituals but living risk perceptions; post-mortems are not eulogies but version updates. The entire cogware system is perpetually in use and perpetually being modified. In such a company, bypassing a process is not a violation but a signal—exceptions are observed, explained, and then incorporated into the next version.

The intelligence of a person-led organization resides in individuals; a process-driven organization embeds intelligence into prescribed actions; a learning organization’s intelligence is continuously rewritten by reality.

The Role of People in a Cogware System #

When we say people should serve the system, it doesn’t mean reducing people to tools. What you serve are precisely the things the system cannot do itself: judging exceptions, identifying anomalies, managing value conflicts, transforming today’s lessons into tomorrow’s memory—and taking responsibility for results.

If we imagine a company as an intelligent agent, this agent does not evolve automatically; it requires your continuous input.

As a verse testifies:

Errors forge skills, At the cliff’s edge, a pause. Scars become memory, People depart, but the light burns on.

注释

[1] Nelson, Richard R., and Sidney G. Winter. An Evolutionary Theory of Economic Change. Cambridge, MA: Harvard University Press, 1982.

[2] Knowledge at Wharton. “Huawei Technologies: A Chinese Trail Blazer in Africa.” April 20, 2009. https://knowledge.wharton.upenn.edu/article/huawei-technologies-a-chinese-trail-blazer-in-africa/.

[3] Ren Zhengfei’s speech at the IPD Phase 1 Summary Report Meeting, November 16, 1999; see also Zhang, Zihan, and Johann Peter Murmann. “Transforming Product Development at Huawei: The IPD Initiative.” In The Management Transformation of Huawei. Cambridge University Press, 2020.

[4] Haynes, Alex B., et al. “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population.” New England Journal of Medicine 360 (2009): 491–499.

[5] Risko, Evan F., and Sam J. Gilbert. “Cognitive Offloading.” Trends in Cognitive Sciences 20, no. 9 (2016): 676–688.

[6] Szulanski, Gabriel. “Exploring Internal Stickiness: Impediments to the Transfer of Best Practice Within the Firm.” Strategic Management Journal 17 (1996): 27–43.

[7] “Emerging from Setbacks to Quality Upgrade,” China Aerospace Science and Technology Corporation website. http://zhuanti.spacechina.com/n1449297/n1449403/c1459659/content.html.

[8] ISO 18238:2015, Space systems — Closed loop problem solving management. See also “China’s Space Program Steps Onto the International Standard Stage,” China Aerospace Science and Technology Corporation website.

[9] Pan Jixing, Collated and Researched Edition of Tiangong Kaiwu, Bashu Publishing House, 1989.