thinking-feedback-loops
Feedback Loop Analysis
Overview
Feedback loop analysis, developed by Donella Meadows in "Thinking in Systems," provides a rigorous framework for understanding how systems behave over time. All dynamic systems—software, organizations, markets, products—are driven by feedback loops that either amplify change (reinforcing) or stabilize toward goals (balancing). Understanding these loops reveals why systems grow, collapse, oscillate, or resist change.
Core Principle: System behavior emerges from feedback structure. To change behavior, change the loops.
When to Use
- Analyzing organizational dynamics (growth, stagnation, dysfunction)
- Designing product growth loops and retention mechanisms
- Debugging systems exhibiting runaway growth or collapse
- Understanding why a system oscillates instead of stabilizing
- Finding high-leverage intervention points
- Predicting unintended consequences of changes
- Understanding why "obvious" fixes fail or backfire
Decision flow:
More from tjboudreaux/cc-thinking-skills
thinking-scientific-method
Hypothesis → Prediction → Test → Revise with explicit falsification. Use for debugging, feature experimentation, performance investigation, and A/B testing design.
29thinking-model-router
Route to the right mental model based on your domain and problem type. The single entry point for all thinking skills.
29thinking-socratic
Systematic questioning framework to deepen understanding, challenge assumptions, and uncover hidden beliefs. Use for requirements gathering, debugging, coaching, and critical analysis.
29thinking-inversion
Approach problems backward by identifying paths to failure, then systematically avoiding them. Use for risk identification, planning, and avoiding obvious mistakes.
28thinking-probabilistic
Express confidence in ranges, update predictions with new information, and track calibration over time. Use for project estimation, risk assessment, and decision making under uncertainty.
27thinking-red-team
Deliberately attack your own plans, systems, and assumptions to find weaknesses before adversaries or reality does. Use for security review, architecture validation, plan stress-testing, and pre-launch preparation.
27