메뉴
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Choosing a technology/framework/dependency and longevity matters. Use the heuristic that for non-perishable things, expected remaining life is proportional to current age — favor the proven.
| name | thinking-leverage-points |
| description | Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move. |
Donella Meadows' "Places to Intervene in a System" ranks intervention points by their power to change behavior. Most effort goes into low-leverage moves (parameters, buffers) when higher-leverage points (rules, goals, structure) change behavior with less force. This is the canonical home of the 12-level hierarchy—other skills (thinking-systems, thinking-feedback-loops) reference it instead of duplicating it.
Core Principle: Higher in the hierarchy = more leverage, but more resistance. Find the highest leverage point you can actually move.
Want to change system behavior?
→ Stuck tuning parameters with no lasting effect? → MOVE UP THE HIERARCHY
→ Found the lever but the change won't stick? → look for a balancing loop resisting it
thinking-systems first; you can't rank interventions on a system you don't understand.When tuning parameters keeps not sticking and you need to pick where to intervene:
If a single low-level parameter genuinely is the fix (wrong timeout value), just change it. If there's no system behind the decision, skip — this hierarchy adds nothing.
What: Numbers—budgets, rates, thresholds, timeouts
Examples:
Why low leverage: Parameters rarely change behavior fundamentally. The system absorbs parameter changes and continues its pattern.
Intervention: Increase server timeout from 30s to 60s
Result: Slow requests succeed, but root cause remains
Leverage: Very low—masks symptom, doesn't fix system
What: Stabilizing stocks—queues, caches, inventories
Examples:
Why low leverage: Buffers absorb fluctuations but don't change system dynamics. Bigger buffer = slower response to change.
Intervention: Increase message queue size
Result: Handles traffic spikes, but processing lag grows
Leverage: Low—buys time but doesn't address throughput
What: Physical architecture—how things are connected
Examples:
Why medium leverage: Hard to change once built; design matters but is often locked in.
Intervention: Add read replica to reduce DB load
Result: Significant improvement in read performance
Leverage: Medium—structural change, but within existing paradigm
What: Time lags in feedback loops
Examples:
Why medium leverage: Shortening delays makes systems more responsive and stable. Many oscillation problems are actually delay problems.
Intervention: Reduce deployment time from 2 hours to 10 minutes
Result: Faster feedback, fewer bugs reaching production
Leverage: Medium-high—changes system responsiveness fundamentally
What: Negative feedback that counteracts change
Examples:
Why medium-high leverage: Strengthening balancing loops increases stability; weakening them enables change.
Intervention: Implement circuit breaker with automatic recovery
Result: Failures isolated, cascade prevention
Leverage: Medium-high—changes failure dynamics
What: Positive feedback that amplifies change
Examples:
Why high leverage: Reinforcing loops drive exponential growth or collapse. Controlling gain = controlling trajectory.
Intervention: Create "fix broken windows" culture that reinforces quality
Result: Quality begets quality, technical debt decreases
Leverage: High—self-sustaining improvement
What: What signal is surfaced, and where
Examples:
Why high leverage: A component can only respond to what it can see. Adding a feedback signal where one was missing changes behavior without changing any logic.
Intervention: Emit and alert on cache hit-rate that was previously invisible
Result: Regression caught immediately instead of after an outage
Leverage: High—behavior change through visibility
What: Constraints the system enforces—what's allowed, required, or rejected
Examples:
Why high leverage: Rules define what's even possible. Change the rule and a whole class of behavior changes or becomes impossible.
Intervention: Make the type checker / schema validation a hard CI gate
Result: An entire class of bug can no longer reach production
Leverage: High—changes what's acceptable
What: Ability of the system to change its own structure
Examples:
Why very high leverage: Systems that can adapt their own structure survive change; rigid systems eventually break.
Intervention: Replace a hardcoded dispatch table with a plugin registry
Result: New behavior added without touching the core; the system evolves
Leverage: Very high—enables adaptation
What: What the system is actually optimizing for
Examples:
Why very high leverage: Everything downstream serves the goal. Optimizing for the wrong target reliably produces the wrong behavior, no matter how good the parts are.
Intervention: Change a cache eviction goal from "max hit rate" to "bound tail latency"
Result: Different eviction policy, different downstream behavior entirely
Leverage: Very high—redirects all effort
What: The shared assumptions from which goals and architecture arise
Examples:
Why transformational: Paradigms are upstream of goals, rules, and structure. Shift the paradigm, transform the system.
Intervention: Shift from "retry until success" to "fail fast + shed load"
Result: Retry storms become impossible; the whole failure mode changes
Leverage: Transformational—changes what's thinkable
What: The ability to change paradigms, recognizing no paradigm is "true"
Examples:
Why highest leverage: Freedom from paradigm lock-in enables choosing the right paradigm for each context.
Mastery: Recognize when "microservices always" became dogma
Choose monolith when it's right
Result: Optimal architecture for each situation
Leverage: Highest—freedom from ideological constraints
Where are you currently trying to create change?
Current interventions:
- Increasing server count (Level 11 - buffers)
- Adjusting timeout parameters (Level 12 - parameters)
- Adding monitoring (Level 6 - information flows)
Plot on the hierarchy to see leverage distribution:
High Leverage [3] Goals
[5] Rules
[6] Information ← Monitoring
[7] Reinforcing loops
Medium [8] Balancing loops
[9] Delays
[10] Structure
Low Leverage [11] Buffers ← Server count
[12] Parameters ← Timeouts
For each low-leverage intervention, ask: "What's the higher-leverage version?"
| Low Leverage | Ask | Higher Leverage |
|---|---|---|
| More instances | Why do we need more capacity? | Fix the inefficient algorithm/query (structure) |
| Longer timeouts | Why are things slow? | Reduce a delay in the pipeline (Level 9) |
| Patch each bug instance | Why does this class recur? | Make it unrepresentable / add a CI gate (10, 5) |
Higher leverage usually means more cost or more resistance. Evaluate before committing:
Intervention: Make schema validation a hard gate (Level 5)
Leverage: High—blocks a whole bug class
Cost/resistance: Touches every caller; needs migration of existing data
Strategy: Validate in warn-only mode first, then flip to enforce
Select the highest-leverage intervention you can actually execute now.
Endlessly tuning parameters when the real issue is structural:
Symptom: Constantly adjusting cache TTLs, retry counts, timeouts
Reality: Architecture doesn't match access patterns
Solution: Redesign the data flow (Level 10) instead of tuning parameters
A component behaves badly because a signal is invisible to it:
Symptom: A regression ships repeatedly and is only caught downstream
Reality: The relevant metric is never surfaced
Solution: Emit + alert on it (Level 6)—behavior corrects without new logic
The system optimizes a proxy that diverges from the real objective:
Symptom: Cache maximizes hit-rate but tail latency is terrible
Reality: The optimization target is wrong
Solution: Change the goal to "bound p99" (Level 3)
Sometimes the whole frame is wrong:
Symptom: Recurring retry storms despite tuning retry counts
Reality: "Retry until success" is the wrong paradigm under load
Solution: Shift to "fail fast + shed load" (Level 2)
| Problem | Low-Leverage Response | High-Leverage Alternative |
|---|---|---|
| System too slow | Add caching (11) | Fix algorithm; surface latency in feedback (6, 10) |
| Too many bugs slip through | More manual testing (12) | Make the check a required gate / CI rule (5) |
| Repeated cascading failures | Bigger timeouts (12) | Add circuit breaker / backpressure loop (8) |
| Retry storms under load | Lower retry count (12) | Change the retry paradigm: fail fast + shed (2) |
| Same bug class recurs | Patch each instance (12) | Make it unrepresentable via type/schema (10, 4) |
| Hidden, wrong defaults | Tune the value (12) | Make the config visible/validated (6, 5) |
"People who manage to intervene in systems at the level of paradigm hit a leverage point that totally transforms systems."
"Magical leverage points are not easily accessible, even if we know where they are. There are no cheap tickets to mastery."
The highest leverage requires the most skill and often the most patience. But knowing where leverage exists helps you stop wasting effort at the bottom of the hierarchy.