Rules
1,053 rules · page 4 of 22
Eliminate first, simplify second, automate last — never…
Follow the automation hierarchy of eliminate-simplify-automate in strict order, because automating waste entrenches it and automating complexity makes it brittle.
Automate only fully-specifiable tasks — if it needs…
Automate only tasks where the rule can be stated completely (fixed rule, known inputs, predictable outputs) and execution requires no judgment about exceptions or novel cases.
Track every automation in a registry — function, tool…
Maintain an automation registry listing each automation's function, tool, last verification date, failure indicators, and review cadence to prevent automation debt accumulation.
Start automation with checklists and templates before…
Start automation at the lowest-tech level that solves the problem (checklists, templates, calendar events) before considering platforms or scripts, because simplicity reduces maintenance burden.
Tier your habits for graceful degradation — know which…
Rank operational habits into three tiers (minimum viable, performance-improving, optimizations) so you know which to preserve under moderate disruption (tiers 1-2) and severe disruption (tier 1 only).
After 2+ day disruptions, triage before processing — many…
After disruptions longer than two days, triage accumulated items (actionable + time-sensitive, resolved itself, archive) before chronological processing to eliminate waste from self-resolved issues.
Restart habits tier by tier after disruption — confirm…
Restart operations sequentially after disruption by adding tier 1 first, confirming stability, then adding tier 2, then tier 3, rather than attempting simultaneous restart of all habits.
Weekly
Add a single recurring check at the end of each weekly review that compares your operational handbook to your actual operations and updates discrepancies immediately.
Run systems at 70-85% capacity — full utilization means…
Run operational systems at 70-85% of measured capacity to maintain adaptive buffer, because systems at full utilization cannot absorb environmental change without breaking.
Budget 30 min to 2 hours weekly for system maintenance…
Calculate maintenance budget for entire operational system (30 minutes to 2 hours weekly) as binding constraint; reject additional components when aggregate maintenance would exceed sustainable capacity.
Physically pause for 90 seconds before responding…
When receiving critical feedback, insert a physical pause (close laptop, stand up, or wait 90 seconds) before responding to allow prefrontal cortex engagement rather than amygdala-driven reaction.
After every operational failure, run five blameless…
After any operational failure, write a blameless post-mortem using five questions: what happened (factual description), what was the timeline of contributing events, what were the systemic factors, what are the action items (specific system changes), and what would have prevented this.
One hypothesis-driven improvement per week — state…
Run one complete PDCA improvement iteration per week on a single operational system: state a hypothesis predicting how a specific change will improve a specific measurable outcome by an estimated amount, implement for one cycle, measure the result, then adopt, adjust, or abandon based on whether the prediction held.
Add backup slot and automated reminder to critical…
When operational maintenance is scheduled at a time with no buffer, no reminder, and no fallback slot, add redundancy through a primary slot, backup slot, and automated reminder rather than increasing willpower.
Test 'busywork' by asking what breaks if you stop…
For every operational task you currently frame as 'busywork,' write one sentence describing what would break if you stopped doing it for a month—if nothing breaks, eliminate it; if something breaks, relabel it as infrastructure.
Draft the reactive version first, then wait 10 minutes…
In emotionally charged messages, draft your reactive response first in a private document, then wait 10 minutes before composing the actual message, using the comparison between versions as data about emotional distortion.
Use AI as an emotional distortion mirror, not a ghostwriter
When using AI to draft difficult communications, compare your reactive draft against the AI-generated neutral version to measure where emotions are distorting your message, rather than sending the AI version directly.
Replace 'interrupted' and 'ignored' with camera-observable…
Replace evaluative words that smuggle judgment ('interrupted,' 'ignored,' 'slammed') with camera-observable behavior descriptions ('began speaking while I was mid-sentence,' 'has not replied since Tuesday') in feedback conversations.
Use 'how did this happen' not 'why did you do this'…
In technical postmortems, use 'how' questions ('how did the deployment occur') rather than 'why' questions ('why did you skip review') because 'how' elicits description while 'why' elicits defensive justification.
Write down your mood and expectation before high-stakes…
Before high-stakes observations (meetings, decisions, analyses), write down your current mood and strongest expectation about the outcome to make perceptual filters visible for later comparison against actual observations.
Search logs for evidence that falsifies your hypothesis…
When debugging with strong initial hypotheses about root cause, deliberately search logs for evidence that would falsify the hypothesis rather than confirm it, to counteract confirmation bias in data collection.
Enforce 5 minutes of data-only observation in incident…
During incident response, enforce a mandatory 5-minute observation period where team members only report dashboard data and log patterns before anyone proposes a causal theory.
Name the specific emotion precisely before responding…
After initial defensive emotional reaction to feedback, name the specific emotion with high granularity ('I notice frustration about the timeline comment, not the technical critique') before responding, to activate prefrontal regulation.
Make implementation intention triggers highly specific…
When using implementation intentions to create behavioral pauses, specify the triggering situation at high detail ('If I receive code review feedback challenging my approach...') rather than generically ('If I get criticism...') to increase cue detectability.
Before committing to a bug hypothesis, write
Before committing to a hypothesis about a bug's cause, write one sentence completing 'What would I expect to see if I were wrong?' then specifically search for that evidence before continuing the investigation.
High confidence is a trigger for more scrutiny, not less…
When confidence in a technical conclusion exceeds 8/10, treat that high confidence as a trigger to increase scrutiny and deliberately search for disconfirming evidence rather than reducing verification effort.
Before recurring meetings, list five things that never get…
Before any recurring meeting or code review, spend 5 minutes writing down what topics never get discussed, what people never speak, and what failure modes are never mentioned—listing at least five absences.
Describe a familiar system for 10 minutes without…
When encountering a familiar system or codebase, force yourself to describe what you observe using only concrete sensory details for 10 minutes before applying any evaluative categorization or pattern labels.
Before design reviews, write what you assume is already…
Before entering any design conversation or architecture review, write one sentence answering 'What am I assuming is already settled here?' to surface expertise-hidden assumptions that should be re-examined.
Treat a newcomer's unanswerable question as a signal…
When a newcomer to a codebase or system asks a question you cannot immediately answer about code you wrote, treat their question as a defamiliarization signal requiring investigation rather than dismissing it as lack of context.
After explaining a system, revisit every 'obviously'…
After explaining a system to someone with zero context, revisit any point where you said 'obviously' or 'of course' and document the unstated assumption those words concealed.
Use random body-scan timers to build interoceptive awareness
Set three random timers throughout your workday; when each fires, pause for 30 seconds to scan jaw, shoulders, chest, stomach, and hands for tension, rating each 1-5 and noting your current activity.
When dashboards are all-green but something feels wrong…
When a system reports all-green status but something feels wrong, immediately check for missing log streams, absent metrics, or silent services rather than trusting the presence of positive signals alone.
When your body tenses in a design review, name what…
When you feel chest tightening or jaw tension during a design review or technical discussion, write down 'I notice I want to protect [X]' before formulating your response to create separation between observation and defense.
Filter facts from stories in difficult emails before sending
Before sending difficult emails or presenting challenging conclusions, run your draft through fact-story filtering by asking which statements would survive if you had to prove them with timestamps, screenshots, or measurements, because this prevents narrative from masquerading as evidence.
Trace execution paths variable-by-variable instead…
When reviewing code or data, trace actual execution paths or data trends variable-by-variable rather than pattern-matching from function names or headline numbers, because the gap between assumed behavior and actual behavior is where critical issues hide.
After strong reactions, record facts and interpretations…
After any event producing strong reactions, spend 90 seconds recording observations in a two-column format (left: camera-recordable facts, right: interpretations) before analysis, because this separation prevents retroactive rewriting of evidence to fit conclusions.
Complete the incident timeline before writing any causal…
When drafting incident postmortems or failure analyses, complete the timeline of observable events (with timestamps and measurements) before writing any causal analysis, because mixing observation and explanation during collection produces defensive filtering.
Force AI to separate observations from interpretations…
Before prompting AI to analyze meeting transcripts or documents, explicitly request separated outputs: first section lists only observable facts without interpretation, second section offers interpretations of those observations.
Announce mode switches explicitly in team observation…
In team contexts where observation must be separated from evaluation, make the phase transition explicit through verbal announcement ('We are now switching from observation mode to evaluation mode'), because implicit transitions allow the two modes to collapse into each other despite individual intentions.
If the same judgment appears in three contexts…
When you encounter the same judgment arising across three or more different contexts, treat it as a structural cognitive habit requiring explicit examination rather than a series of independent assessments, because cross-context repetition indicates the judgment is executing from pattern-matching rather than situation-specific analysis.
Mark habitual judgments after they fire — you cannot…
For habitual judgments that fire too quickly to intercept before they execute, implement a marking protocol where you log each occurrence with 'HJ' notation immediately after noticing it, because marking converts the judgment from invisible background process to observable object without requiring the neurologically impossible task of preventing automatic activation.
Apply the substitution test to check if a judgment…
When noticing a habitual judgment about a person or group, apply the substitution test by asking whether you would make the same evaluation if a different person or group were in the identical situation—if the answer is uncertain or negative, you have detected a judgment running on identity rather than behavior.
Convert judgments into genuine questions — ask about…
When a judgment forms during an interaction, immediately convert it into a genuine question by replacing the evaluative conclusion with an inquiry about constraints, context, or reasoning ('Why would anyone write it this way?' becomes 'What constraints or context led to this approach?'), because questions activate exploratory cognition while conclusions activate confirmatory cognition.
Ask 'what was your reasoning?' not 'why did…
In code reviews or technical evaluations, frame feedback requests as requests for reasoning rather than requests for justification—ask 'What was your reasoning?' instead of 'Why did you do it this way?'—because the first activates analytical explanation while the second activates defensive explanation.
Build observation skills on a five-level hierarchy…
When building new observation skills, construct a five-level difficulty hierarchy ranging from trivial annoyances to identity-level triggers, then spend minimum one week at each level before progressing, because attempting high-stakes observation without low-stakes mastery produces reversion to automatic judgment under pressure.
Advance observation practice when the trigger becomes…
When practicing observation at any difficulty level, stay at that level until the trigger becomes boring rather than advancing on a fixed schedule, because boredom signals that automatic judgment has been replaced by automatic observation at that complexity level.
Use AI to catch hidden judgments in your observation writing
When using AI to practice observation skills, provide it with your written accounts of charged situations and explicitly request separation of observational statements from evaluative statements, using the AI's output as immediate feedback on which judgments you embedded without noticing.