Two teams, two strategies, one year later
Imagine two software teams shipping the same product. Team A deploys every Friday — small changes, a few features, a handful of fixes. Each deployment touches a manageable surface area. When something breaks, the team knows exactly which change caused it because only a few things changed. Rollbacks are fast. Learning is immediate.
Team B deploys quarterly. They accumulate three months of changes into a single massive release. Launch day is an event — war rooms, all-hands-on-deck, late nights. When something breaks, and something always breaks, nobody can isolate which of the hundreds of changes caused the failure. Debugging takes weeks. The post-mortem is sixty pages long. The team is exhausted before the next cycle even begins.
This is not a hypothetical. The 2024 DORA State of DevOps Report found that elite-performing software teams deploy 182 times more frequently than low performers, with eight times lower change failure rates (Forsgren et al., 2024). The pattern is consistent across a decade of data: smaller, more frequent changes produce better outcomes than larger, rarer ones. Not marginally better. Categorically better.
The same principle applies to your cognitive infrastructure. Your schemas — mental models of how the world works, what motivates people, what you are capable of, how systems behave — are software you run on reality. And the same deployment dynamics apply. Small, frequent updates to those schemas are less disruptive, more accurate, and more sustainable than large, rare overhauls. This lesson explains why, drawing on evidence from software engineering, manufacturing, cognitive psychology, organizational science, and artificial intelligence.
The engineering case: small batches reduce risk
The insight that small batch sizes reduce risk did not originate in Silicon Valley. It was formalized in manufacturing, sharpened in software engineering, and validated by a decade of empirical research on software delivery performance.
The DORA research program, published in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim (2018), identified four key metrics that predict software delivery performance: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. The consistent finding across ten years of data collection is that these metrics are positively correlated — teams that deploy more frequently also have lower failure rates and faster recovery times. This contradicts the intuition that deploying more often means more risk. In practice, the opposite is true. Each small deployment carries less risk because its blast radius is limited. If something fails, the cause is obvious and the fix is contained.
The DORA team's explanation centers on batch size. When you reduce the batch size of changes, you reduce the number of variables in play at any given moment. You can reason about a three-line code change. You cannot reason about a three-thousand-line code change with the same fidelity. The small batch does not just reduce risk mechanically — it makes the change legible to the humans managing it.
Contrast this with the "big bang" deployment model, where all changes are accumulated and released simultaneously. Big bang releases require extensive coordination, and if something goes wrong, isolating the cause within hundreds of interacting changes becomes exponentially harder. The 2024 DORA data shows that organizations adopting continuous delivery practices reduce change failure rates while increasing throughput — a combination that was once considered impossible (DORA, 2024).
The lesson for schema evolution is direct. When you accumulate belief-updates and attempt to overhaul your mental models all at once — after a crisis, after a retreat, after reading a transformative book — you are performing a big bang deployment on your cognitive infrastructure. The blast radius is large, the interactions are unpredictable, and when something goes wrong (and it will), you cannot isolate which revision caused the problem.
The manufacturing case: kaizen and the power of continuous small improvements
The most sustained empirical demonstration of incremental improvement comes from Toyota's kaizen philosophy — a Japanese term meaning "change for the better." Kaizen is not a technique. It is an operating philosophy: every person in the organization, every day, looks for small ways to improve their work.
The numbers at Toyota are striking. Employees generate more than one million process improvement ideas annually, and approximately 90 percent of those ideas are implemented (Liker, 2004). These are not revolutionary innovations. They are minor adjustments — repositioning a tool to save two seconds, adjusting a work sequence to reduce one unnecessary motion, rewriting an instruction to prevent a recurring misunderstanding. Individually, each change is trivial. Cumulatively, they compound into one of the most efficient production systems ever created.
The Toyota Production System demonstrates a principle that applies directly to schema evolution: the compound effect of small changes exceeds the impact of occasional large changes, because small changes are cheaper to implement, faster to evaluate, and easier to reverse if they fail. Toyota does not wait for major problems to trigger improvement. Workers refine their processes while working — adjusting assembly layouts, updating work instructions, tweaking standard operating procedures continuously (Imai, 1986).
This is the mindset that incremental schema revision requires. You do not wait until your model of the world is catastrophically wrong to update it. You revise continuously, in small increments, as new evidence arrives. Each revision is modest. The cumulative effect is transformative.
Healthcare organizations have adopted kaizen with measurable results. A 2023 systematic review published in Cureus found that kaizen methods improve team engagement, communication, and the sustained development of new ideas — precisely the qualities that make continuous improvement self-reinforcing rather than episodic (Al Kuwaiti et al., 2023). The same self-reinforcing quality applies to personal schema maintenance: the habit of making small updates makes future updates easier, because you build the neural and behavioral infrastructure for revision itself.
The cognitive case: why your brain prefers small changes
The engineering and manufacturing cases show that small changes work better in external systems. The cognitive science explains why they work better for the internal system doing the changing — your brain.
John Sweller's Cognitive Load Theory, first published in 1988 and refined over three decades, established that working memory has strict capacity constraints. When you try to process more information than working memory can handle, learning degrades — not gradually, but sharply. Sweller identified three types of cognitive load: intrinsic (the inherent complexity of the material), extraneous (unnecessary processing demands from poor presentation), and germane (the productive effort of integrating new information into existing schemas). The goal of effective learning is to maximize germane load while minimizing extraneous load, all within the fixed capacity of working memory (Sweller, 1988).
Nelson Cowan's 2001 research refined our understanding of that capacity. While George Miller's famous 1956 estimate of "seven plus or minus two" chunks became folk wisdom, Cowan demonstrated through extensive experimental evidence that the true capacity of focused attention is closer to four chunks (Cowan, 2001). Four. Not seven. When you attempt to update multiple schemas simultaneously — revising your model of your career, your relationships, your creative process, and your health habits all at once — you are attempting to hold and manipulate far more chunks than working memory can support. The result is not partial success. It is cognitive overload: none of the changes integrate properly, and you revert to prior patterns within days.
A single schema update, by contrast, fits comfortably within working memory capacity. You can hold the old version of the schema, the new evidence, and the proposed revision in mind simultaneously. You can evaluate whether the revision improves predictive accuracy. You can notice when the new version conflicts with adjacent schemas. This is germane cognitive load — the productive kind — and it only works when the information volume stays within capacity.
This is the cognitive mechanism behind a universal observation: people who try to change everything at once change nothing permanently, while people who change one thing at a time change everything eventually.
The organizational case: why gradual change succeeds where radical restructuring fails
The pattern holds at the organizational level too. McKinsey's research on organizational transformations consistently finds a baseline success rate around 30 percent — meaning roughly 70 percent of major change initiatives fail to achieve their intended outcomes (McKinsey, 2023). The statistic is often attributed to John Kotter's change management research, though as Hughes (2011) noted, the empirical basis for the specific 70 percent figure is weaker than commonly assumed. What is well-documented is the pattern: large-scale, radical transformations fail more often than they succeed.
The reasons parallel the engineering and cognitive arguments. Radical organizational change introduces too many variables simultaneously. Employees cannot distinguish which new processes to adopt and which to resist. Communication channels overload. The organization loses functional practices alongside dysfunctional ones because nobody can sort the two during the chaos of wholesale restructuring.
McKinsey's 2023 research on transformation success found that organizations which "look regularly for new and better ways to work" — continuous incremental improvement — double their chance of sustaining improvements after transformation. When combined with other success factors like leadership modeling and employee engagement, the odds of success can nearly triple from the 26 percent baseline to 58 percent (McKinsey, 2023).
The Prosci research framework for organizational change management draws a useful distinction: incremental change modifies existing structures, while radical change replaces them. Incremental change is easier to implement, generates less resistance, and preserves institutional knowledge. Radical change is sometimes necessary — when existing structures are fundamentally broken — but it is always more expensive, more disruptive, and more likely to fail (Prosci, 2024).
For personal schemas, the parallel is precise. When you incrementally revise a mental model — adjusting your estimate of how long a project will take, updating your understanding of what motivates a colleague, refining your theory of your own productive hours — you preserve the functional core of the schema while correcting the parts that do not match reality. When you perform a radical overhaul — throwing out your entire approach to time management, or completely reimagining your career theory after one bad quarter — you lose the valid elements along with the invalid ones. Radical revision feels decisive. Incremental revision is effective.
AI and the Third Brain: catastrophic forgetting as a warning
Artificial intelligence research provides a vivid demonstration of what happens when a learning system attempts large updates instead of small ones. The phenomenon is called catastrophic forgetting, and it is one of the most studied problems in machine learning.
When a neural network is trained on a new task, it adjusts its internal weights to learn the new patterns. But those same weights encode everything the network previously learned. If the weight adjustments are large — as they are when the network is trained aggressively on new data — the network loses its ability to perform previous tasks. It does not gradually degrade. It catastrophically forgets, as if the prior learning never happened (McCloskey & Cohen, 1989; Kirkpatrick et al., 2017).
This is not a theoretical curiosity. A 2024 empirical study on large language models found that catastrophic forgetting intensifies as model scale increases, particularly in models ranging from one to seven billion parameters (Luo et al., 2024). The parallel to human cognition is instructive: when you aggressively overwrite your mental models with new information — binge-reading a field you know nothing about, or wholesale adopting a new framework after a single compelling presentation — you risk losing the functional models you already had. The new information does not integrate with the old. It overwrites it.
The AI research community has developed several strategies to prevent catastrophic forgetting, and each has a direct analog in personal schema evolution:
Elastic Weight Consolidation (EWC): This technique penalizes large changes to weights that are important for previously learned tasks (Kirkpatrick et al., 2017). The personal equivalent: when updating a schema, identify which components are load-bearing — the parts that generate accurate predictions — and protect them from revision. Update the parts that are failing, not the parts that are working.
Replay and rehearsal: Neural networks retain old knowledge by periodically reviewing examples from previous tasks alongside new data. The personal equivalent: when you adopt a new mental model, deliberately revisit and practice the insights from your previous models that remain valid. Do not let new learning crowd out old learning.
Parameter-efficient fine-tuning (LoRA, adapters): Instead of retraining the entire network, these methods add small, targeted modifications while leaving the base model intact. The personal equivalent: when new evidence arrives, make the minimum necessary adjustment to your schema rather than rebuilding from scratch. The base model is probably mostly right. Adjust the specific parameters that the evidence addresses.
For your Third Brain — the AI-augmented knowledge infrastructure you are building — this has practical implications. When you use AI tools to help you think, the same incremental discipline applies. Do not ask an AI to "redesign my entire approach to X." Ask it to help you identify the specific component of your current approach that is not working, and to suggest the smallest revision that would address the problem. This mirrors the engineering best practice: small pull requests, not monolithic rewrites.
Protocol: building the incremental revision habit
Theory is insufficient without practice. Here is a concrete protocol for making incremental schema revision a regular part of your cognitive maintenance.
Step 1: Maintain a revision queue. Keep a running list of schemas that feel slightly off — predictions that were wrong, assumptions that surprised you, models that produced unexpected results. You do not need to fix them immediately. You need to notice them and write them down. A simple note on your phone or a dedicated section in your journal works. The queue is the raw material for incremental revision.
Step 2: Process one item per week. Choose one schema from your queue — ideally the one where the evidence for revision is clearest. Write down the current schema in one sentence. Write down the specific evidence that suggests it needs updating. Write down the smallest revision that would account for that evidence. Implement the revision.
Step 3: Test the revision for one week. Live with the updated schema and pay attention to whether it generates better predictions than the old version. Does your revised estimate of how long meetings run match reality more closely? Does your updated model of your energy levels help you schedule more effectively? Collect data, even informally.
Step 4: Log the result. Record whether the revision improved accuracy, made no difference, or made things worse. If worse, revert. If better or neutral, keep it and move to the next item in the queue. This log becomes the raw material for L-0304 — tracking what triggered each update.
Step 5: Resist the overhaul impulse. When you encounter a domain where many schemas feel wrong simultaneously — a career crisis, a relationship rupture, a professional failure — the temptation is to throw everything out and start over. Resist it. Instead, prioritize: which single schema revision would have the largest impact? Start there. Then process the next one. The crisis does not require a revolution. It requires a faster cadence of evolution.
The cadence matters more than the magnitude. One small revision per week gives you fifty-two documented schema updates per year. That is not incremental in the colloquial sense of "barely noticeable." It is transformative — but in a way that preserves continuity, maintains what works, and builds a traceable record of how your thinking evolved.
From updating to tracking: the bridge to L-0304
You now have the principle (small, frequent updates beat large, rare overhauls) and the practice (a weekly revision protocol with logging). But a log of what changed is only half the picture. The other half is why it changed — what specific evidence, experience, or observation triggered each revision.
Tracking triggers is not bookkeeping. It is how you learn about your own learning process. When you review a year of revision logs and can see that most of your schema updates were triggered by direct experience rather than reading, or by conversations with one particular person, or by failures rather than successes, you gain meta-knowledge about how your cognitive infrastructure evolves. That meta-knowledge is the foundation of Phase 17 — Meta-Schemas — but it starts here, in Phase 16, with the simple practice of recording what prompted each change.
L-0304 introduces the discipline of trigger-tracking: recording not just what you revised, but what made you revise it. If this lesson gave you the rhythm of incremental revision, the next gives you the memory.
Sources
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- DORA. (2024). 2024 State of DevOps Report. Google Cloud.
- Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill.
- Imai, M. (1986). Kaizen: The Key to Japan's Competitive Success. McGraw-Hill.
- Al Kuwaiti, A., et al. (2023). A practical guide to the kaizen approach as a quality improvement tool. Cureus, 15(5).
- Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257-285.
- Miller, G. A. (1956). The magical number seven, plus or minus two. Psychological Review, 63(2), 81-97.
- Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87-114.
- McKinsey & Company. (2023). The science behind successful organizational transformations.
- Hughes, M. (2011). Do 70 per cent of all organizational change initiatives really fail? Journal of Change Management, 11(4), 451-464.
- Prosci. (2024). Incremental versus radical change.
- McCloskey, M., & Cohen, N. J. (1989). Catastrophic interference in connectionist networks. Psychology of Learning and Motivation, 24, 109-165.
- Kirkpatrick, J., et al. (2017). Overcoming catastrophic forgetting in neural networks. Proceedings of the National Academy of Sciences, 114(13), 3521-3526.
- Luo, Y., et al. (2024). An empirical study of catastrophic forgetting in large language models during continual fine-tuning. arXiv:2308.08747.