Rules
1,053 rules · page 12 of 22
A complete feedback loop needs three elements
For any recurring activity, explicitly define three elements—the specific output being measured, the standard for comparison, and the adjustment rule triggered by deviation—to create a complete minimal feedback loop.
Measure feedback delay in actual time units before…
Before attempting to improve any feedback loop, measure the current delay between action and signal in concrete time units (seconds, minutes, hours, days) rather than accepting vague assessments, because unmeasured delays appear shorter than they actually are through habituation.
Substitute a faster noisy signal for a slower precise one…
Find a faster correlated signal that approximates delayed feedback rather than waiting for the original signal, accepting that speed compensates for increased noise in the approximation.
Daily activities need weekly feedback; strategic…
For daily activities, if feedback latency exceeds one week, or for strategic activities if latency exceeds one month, design a leading indicator or checkpoint that shortens the delay before drift compounds.
Build measurement systems when you design the strategy…
Build measurement dashboards and leading indicators at the same time you design the strategy they measure, not after problems appear, because instrumentation designed during crisis measures symptoms rather than causes.
Strengthen virtuous loops through one lever at a time
Strengthen a reinforcing loop you want to amplify by reducing friction at any node, increasing gain at a single node, or shortening cycle time, implementing one intervention per loop rather than attempting simultaneous multi-variable changes.
Only optimize the constraint — verify that improving…
Before attempting to improve a feedback loop component, verify it is actually the constraint by measuring whether improvements there would increase total system throughput, as optimizing non-constraints produces local gains without system-level improvement.
When feedback is slower than behavior frequency, the brain…
When feedback consistently arrives in days or weeks while the behavior repeats daily, the brain cannot reliably attribute consequences to specific actions due to temporal credit assignment failure—requiring external tracking systems to maintain the causal connection.
Schedule reviews at intervals shorter than natural…
Schedule forcing functions (weekly reviews, monthly retrospectives, quarterly strategy assessments) at intervals shorter than the natural feedback latency to artificially tighten loops that cannot be structurally accelerated.
Document every deviation from standards — repeated silent…
Treat any deviation from established standards as a potential normalization-of-deviance signal requiring documented evaluation rather than silent acceptance, because repeated deviations without consequence train the system to accept the deviation as normal.
Reverse a vicious cycle by flipping one node's signal…
Convert vicious cycles into virtuous ones by intervening at a single node to reverse signal direction rather than attempting to dismantle the entire loop structure, because loop topology is often more stable than loop content.
Translate every discrepancy into a specific behavioral…
When a feedback loop identifies a discrepancy between current and target state, translate the evaluation into a specific behavioral adjustment for the next cycle rather than stopping at awareness, because learning occurs during adjustment not observation.
Diagnose broken loops by mapping onto…
Map any broken feedback loop onto the four-part structure (Act, Observe, Evaluate, Adjust) to diagnose which specific component is missing, because each missing part produces a distinct failure signature.
Before correcting in a delayed system, inventory pending…
Before adding corrective action in a delayed-feedback system, inventory pending actions already taken but not yet producing results to avoid pipeline overfilling and subsequent overshoot.
Pre-define how long you'll persist with slow-feedback…
Separate the decision to continue a slow-feedback strategy from subjective feelings of progress by defining persistence duration in advance, because delayed systems provide zero felt momentum before delivering concentrated results.
Wait 48 hours between receiving criticism and deciding…
Separate feedback reception from feedback evaluation by implementing a mandatory 48-hour delay between receiving criticism and deciding whether to act on it, as identity triggers fire faster than analytical capacity and premature evaluation guarantees defensive rejection.
The faster you dismiss feedback, the more likely it hits…
When feedback triggers immediate counter-argument before you finish listening, treat the speed of that dismissal as diagnostic evidence that the feedback addresses an important blind spot rather than as evidence the feedback is invalid.
Validate new feedback mechanisms in the first cycle
For each feedback mechanism you build, verify within the first cycle that the data reveals something unknown, that measurement effort is sustainable, and that you can specify one concrete adjustment based on results—if any component fails, redesign before continuing.
Audit decision-driving metrics every 3 months
When a metric has been used to drive decisions for more than three months without revision, conduct a three-question audit: what behavior does this metric actually incentivize, is the proxy still correlated with the outcome, and what would gaming this metric look like compared to current behavior.
Retire metrics that can't distinguish gaming from genuine…
Retire metrics entirely when they no longer distinguish between gaming behavior and genuine progress, as continued use of a decoupled metric produces wrong information you trust rather than mere absence of information.
Major transitions require full feedback loop recalibration…
Treat major life or work transitions as mandatory recalibration events requiring review of all existing feedback loops, as changed context invalidates proxy-outcome correlations that held under previous conditions.
When improvement stalls despite effort, shift…
When improvement effort in a domain has stalled despite sustained attention, shift focus from single-loop correction (adjusting actions) to double-loop correction (questioning the framework generating actions) by explicitly listing and testing the assumptions underlying your approach.
Design a degraded-mode version of every recurring system…
When building any recurring system (workflow, habit, routine), design an explicit degraded-mode version that preserves core function at reduced scope before the system encounters its first disruption.
Classify errors as execution, knowledge, or judgment…
For each detected error in a system, explicitly classify whether it represents an execution failure (wrong doing), knowledge failure (missing information), or judgment failure (incorrect assessment) before designing any correction.
Recurring errors with the same root cause need structural…
When an error recurs with the same root cause across multiple independent instances, apply structural fixes (process changes, environmental redesign, automated checks) rather than effort-based resolutions (increased attention, more discipline, trying harder).
Match correction type to error type
For execution errors, deploy procedural corrections (checklists, automation, environmental forcing functions); for knowledge errors, deploy epistemic corrections (new information sources, expert consultation); for judgment errors, deploy calibrational corrections (prediction tracking, external review, pre-mortems).
Test your riskiest assumptions first and cheapest — list…
Before committing significant resources to any project, list the 3-5 assumptions that would invalidate the most work if wrong, then design and execute the cheapest falsification test for each assumption in order of potential damage.
When the cost of late error discovery exceeds 5x early…
At each stage of a multi-phase commitment, calculate the cost ratio between discovering a foundational error now versus discovering it after the next phase completes—when this ratio exceeds 5:1, increase detection investment before proceeding.
Monitor your error detection system itself — track what…
Build error detection infrastructure that monitors both your primary outputs and your detection system's own performance, tracking what errors you catch versus what you miss through other means to detect detection failures.
Instrument before executing — drift detection requires…
Design measurement infrastructure before executing strategies rather than after problems become visible, because drift detection requires baseline instrumentation that must exist before deviation occurs.
Define your error budget in writing
For any system you operate, define four components in writing: (1) ideal behavior, (2) minimum acceptable behavior, (3) numeric deviation threshold, and (4) time window before triggering investigation.
When error budget is exhausted, analyze the pattern…
When error budget exhaustion occurs in a tracked system, conduct root cause analysis of the pattern rather than investigating individual deviations, because budget exhaustion signals structural problems while individual errors within budget represent normal variance.
Express error budgets as numbers with time windows — '2…
Express error budgets as time-bounded numeric thresholds (e.g., 'two missed sessions per week' or '30 minutes downtime per month') rather than vague intentions, and track consumption against the budget as a first-class metric.
A true root cause, eliminated, makes the error impossible…
Test root cause validity by asking whether eliminating the identified cause would make the error impossible rather than merely less frequent—if only frequency decreases, continue deeper analysis.
When 'why' has multiple independent answers, branch…
When asking 'why' produces multiple independent answers, branch the Five Whys analysis to follow each causal path separately rather than selecting one primary cause, because multi-causal problems require tree structures not chains.
Stop Five Whys at structural preventability…
Stop Five Whys analysis when you reach a cause you can structurally prevent, not at a predetermined question count—use five iterations as a heuristic but let actionability determine the stopping point.
Checklists are 5-10 items that catch what competent people…
Limit operational checklists to 5-10 items focused exclusively on steps most likely to be skipped or forgotten under load, not comprehensive process documentation.
Checklists need mandatory pause points where all activity…
Insert mandatory pause points in checklist execution where all activity stops and verification becomes the primary task, rather than running checklists as background processes.
Require a physical touch or verbal callout for each…
For each checklist item, require a physical action (touching the control) or verbal callout (saying the condition aloud) to prevent autopilot execution where the ritual completes without actual verification.
Place pre-flight checks at the prep/execution boundary…
Position pre-flight checks at the boundary between preparation and execution—after work is ready but before it begins—to catch errors when correction cost is minimal and propagation has not started.
If you check a box in under 5 seconds without pausing…
For any pre-flight check item you can complete in under 5 seconds without pausing, treat that as evidence of ritual execution not genuine verification—pause and locate observable evidence before marking complete.
After 10+ post-action reviews, analyze in aggregate…
After accumulating 10+ post-action reviews, analyze them in aggregate to identify structural causes appearing across multiple unrelated tasks—these recurring patterns indicate systemic tendencies requiring architectural fixes not isolated corrections.
Add verification checkpoints at every coupling point where…
Insert independent verification checkpoints at every coupling point where one process automatically consumes another's output without review to interrupt error cascade chains before they amplify.
Design three operating modes for every important process
For every important recurring process, design three explicit operating modes—full, reduced, and minimal—where each preserves progressively less fidelity but never loses continuity.
Define triggers for mode transitions in both directions…
Define transition triggers for each operating mode that specify when to shift from full to reduced, reduced to minimal, and—critically—from degraded back to full operation.
Test degraded modes during calm periods — if they don't…
Test degraded operating modes during periods of abundant resources to verify they preserve core function, because modes that fail under calm conditions will certainly fail under stress.
Occasionally run processes in degraded mode…
Practice running processes in degraded mode occasionally even when not required to rehearse partial failure, making the transition familiar rather than frightening when real constraints force it.
Document five recovery components for every important…
For every important process, document five components of recovery: failure mode specification, detection trigger, ordered recovery steps, recovery time target, and verification check.