Why does systems review vs action review reflection fail?

The most common reason systems review vs action review reflection fails: The most common failure is performing a systems review that is actually just action review in disguise. You write "my system for morning exercise is broken" when what you mean is "I did not exercise this morning." The distinction matters: a genuine systems review examines the structural elements — the trigger, the environment, the sequence, the feedback loop, the incentive — while a disguised action review just adds the word "system" to a personal judgment. A second failure mode is the opposite extreme: becoming so absorbed in systems analysis that you never take responsibility for your own agency within those systems. Systems shape behavior, but they do not eliminate choice. The mature position is that you are both a product of your systems and the designer of them — and review should address both levels. A third failure is redesigning systems based on a single week of data. Systems need time to reveal their true performance characteristics. A system that fails in one unusual week may be perfectly functional over a quarter. Review the trend, not the anomaly.

The fix: Conduct a systems-level review of the past month. (1) List your three biggest outcomes — positive or negative — from the past thirty days. For each outcome, do not analyze what you did right or wrong. Instead, identify the system that produced it. What was the workflow, routine, environment, or structure that made the outcome likely or inevitable? (2) For each system, apply the five whys. Why did this outcome occur? Because of X. Why did X occur? Because of Y. Continue until you reach a structural cause — a design choice, a missing process, a flawed environment, a broken feedback loop. Write down the root system cause. (3) For each root cause, determine its leverage point using Meadows framework: Is this a parameter adjustment (low leverage), a feedback loop fix (medium leverage), or a rule/goal change (high leverage)? (4) Design one system-level change for each outcome — not a personal resolution ("try harder") but a structural modification ("move the meeting," "add a trigger," "change the default"). (5) Write a brief systems review addendum to your regular review template that you will use going forward, containing three questions: What systems produced my results this period? Which systems need redesign? What is the highest-leverage change I can make? Time: 45-60 minutes for the initial review; 5-10 minutes per review session thereafter.

The underlying principle is straightforward: The systems that produced your results deserve as much review as the results themselves.