systems-thinker

name	systems-thinker
description	Understanding complex systems through feedback loops (reinforcing and balancing), stocks and flows, Donella Meadows' 12 leverage points, causal loop diagrams, systems archetypes (tragedy of the commons, fixes that fail, shifting the burden), modeling tools, and application to organizational and real-world systems. Use when the user asks about systems thinker or needs help with related topics. Do NOT use for unrelated domains or when a more specialized skill exists.
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"strategy decision-making analysis frameworks","category":"productivity","subcategory":"methodology-frameworks","depends":"","disclaimer":"none","difficulty":"advanced"}

Systems Thinker

When to Use

Use this skill when the user:

• Describes a persistent, recurring problem that keeps returning despite repeated fixes -- symptoms that come back within weeks or months after interventions
• Observes counterintuitive behavior in an organization, market, or ecosystem (e.g., adding resources makes delivery slower, cutting costs increases long-term spending)
• Wants to understand why a policy or intervention produced the opposite of its intended effect
• Needs to map feedback loops, stocks and flows, or causal relationships to understand the structure driving observed behavior over time
• Asks explicitly about systems archetypes (tragedy of the commons, shifting the burden, fixes that fail, limits to growth, escalation), causal loop diagrams, leverage points, or Donella Meadows' framework
• Is designing an intervention in a complex adaptive system -- organizational change, policy design, product strategy, ecosystem management -- and needs to anticipate second- and third-order effects
• Observes behavior over time that shows classic system signatures: exponential growth followed by plateau, persistent oscillation, boom-bust cycles, or a slow erosion that seems to have no identifiable cause
• Wants to build a shared mental model with a team about how their organization, market, or system actually works

Do NOT use this skill when:

• The problem is simple and linear with a clear, unambiguous root cause -- use a standard root cause analysis or 5 Whys approach instead
• The user is asking about project scheduling, task management, or resource allocation without systemic complexity -- use a project management or planning skill
• The request is purely quantitative modeling or data science (regression, forecasting, ML) -- use a data analysis or quantitative modeling skill
• The user is asking about organizational design or role structure without behavior-over-time complexity -- use an organizational design skill
• The user needs a strategic planning framework like OKRs, balanced scorecard, or SWOT -- use a strategy planning skill
• The user is asking about a specific domain (supply chain optimization, financial modeling, ecological science) where a domain-specific skill exists
• The complexity of the situation is artificial -- the system is well-understood and a standard process improvement or lean/six-sigma approach is more appropriate

---

Process

Step 1: Define the Problem Dynamically

Before drawing a single loop or naming a variable, establish what the system is actually doing over time. Generic problem statements ("our growth is slow") produce generic models. Dynamic problem statements produce insight.

• Ask the user to describe the behavior of their key variable over time -- not just its current state. "Revenue declined 5% last quarter" is a snapshot. "Revenue grew 20%/year for four years, plateaued for eighteen months, and has been declining 5%/quarter for two years" is a behavior pattern that implies structure.
• Draw or describe a Behavior Over Time (BOT) graph for 2-4 key variables. What is the shape? Exponential growth? S-curve? Oscillation? Overshoot and collapse? Each shape maps to identifiable feedback structures.
• Identify what changed around the inflection point. Was it exogenous (a market shock) or endogenous (growth hit a structural limit)? Endogenous inflections are the signature of systems problems.
• Name the problem as a verb phrase, not a noun: not "the turnover problem" but "why turnover has accelerated over eighteen months despite three pay-raise interventions."
• Confirm the time horizon and spatial boundary. A problem that matters in weeks has different feedback structures than one that matters in decades.

Step 2: Map Stocks and Flows

Stocks are the foundation of every system model. Identify them before drawing feedback loops, because feedback loops only make sense as effects on or from stocks.

• List every accumulation that is relevant: employees, customer relationships, technical debt, organizational trust, cash, inventory, reputation, regulatory goodwill, product features, institutional knowledge. Stocks are anything you could measure at midnight on December 31st.
• For each stock, identify inflows (what fills it) and outflows (what drains it). Use rate language: hiring rate, churn rate, trust-building rate, knowledge depreciation rate.
• Identify which flows the user controls directly, which they influence indirectly, and which are outside their control. This immediately surfaces where agency exists.
• Note conservation laws: employees who leave the company don't vanish -- they become competitors, customers, or critics. Cash that leaves the firm goes somewhere. Tracking where stocks go clarifies unintended effects.
• Identify the key delays in each flow. The delay between recognizing a hiring need and reaching full productivity is typically 7-14 months in knowledge work (job definition: 2-4 weeks, sourcing and interviewing: 6-12 weeks, notice period: 4 weeks, onboarding: 4-12 weeks, full productivity ramp: 3-6 months). These delays create the structural conditions for oscillation.
• Use the stock-and-flow map to anchor all subsequent analysis. Every causal loop diagram variable should trace back to a stock or a flow that affects a stock.

Step 3: Build Causal Loop Diagrams

With stocks and flows mapped, build the causal structure that drives those flows.

• Identify the central variable -- the one whose behavior over time is the core problem -- and place it at the center of the diagram.
• For each variable, ask: what causes it to increase? What causes it to decrease? What does it cause to increase or decrease? Draw arrows with polarity: (+) means "an increase in A causes an increase in B, all else equal"; (-) means "an increase in A causes a decrease in B, all else equal."
• Trace loops and classify them: count the number of negative (-) arrows in a loop. An even number (0, 2, 4) = Reinforcing loop (labeled R). An odd number (1, 3, 5) = Balancing loop (labeled B). Reinforcing loops amplify; balancing loops stabilize or resist.
• Keep diagrams to 5-8 variables per diagram. If you need more than 8, decompose into sub-diagrams with connection points. Complexity does not equal insight -- a good 6-variable diagram is more useful than an unwieldy 20-variable web.
• Mark delays explicitly with a double-slash (//) on the causal arrow. Delays on balancing loops cause oscillation. Delays on reinforcing loops cause underreaction followed by overreaction.
• Validate the diagram by telling its story out loud: "When workload increases, stress increases, which increases turnover, which increases workload for remaining employees -- a reinforcing loop we're calling the Burnout Spiral." If the story sounds wrong to domain experts, the diagram is wrong.
• Identify which loops are currently dominant. A system's behavior at any moment is determined by which loop is winning. The goal of intervention is often to shift loop dominance.

Step 4: Identify Active Systems Archetypes

Match the observed behavior and causal structure to known systems archetypes. Archetypes are pre-identified causal structures that produce recognizable behaviors -- they provide instant diagnosis and point toward structural solutions.

• Fixes That Fail: A symptomatic fix relieves pressure in the short term but creates side effects that worsen the original problem. Look for: the same problem returning cyclically, solutions that used to work but now require escalating effort, increasing dependency on a particular intervention. Diagnostic question: "What were the unintended consequences of your last fix?"
• Shifting the Burden: A symptomatic fix not only fails long-term but actively atrophies the fundamental solution capability. The system becomes addicted to the quick fix. Look for: organizational capability that used to exist but has been outsourced or abandoned, increasing consultant dependence, managers who solve problems instead of developing problem-solving capability in their teams.
• Tragedy of the Commons: Individually rational behavior depletes a shared resource. Look for: no one owns the resource, each actor's marginal impact seems small, the resource shows gradual erosion nobody feels responsible for. Examples: shared codebases with no ownership, team attention and time, common market reputation in an industry.
• Limits to Growth: A reinforcing growth process meets a balancing constraint. Growth slows, plateaus, or oscillates. Look for: early-phase exponential growth that has flattened, management frustration that "pushing harder isn't working," a constraint that is implicit rather than acknowledged. The constraint, not the growth engine, is the point of intervention.
• Success to the Successful: Two activities compete for the same limited resource. Initial advantage compounds. Look for: star employees getting all interesting work, rich-get-richer dynamics in products or markets, internal projects that starve for resources while successful ones get more than they need.
• Escalation: Two actors each respond to the other's actions by increasing their own, in a reinforcing spiral. Look for: price wars, arms races, feature escalation, retaliatory policies. The system is costly to both parties but neither can unilaterally de-escalate without appearing to lose.

Step 5: Apply Meadows' 12 Leverage Points

Once the causal structure is mapped and archetypes identified, identify intervention options using the leverage point hierarchy. Work from low-leverage to high-leverage to find the most effective, feasible intervention.

• Points 12-10 (Low Leverage -- Numbers, Buffers, Physical Structure): Adjusting parameters (tax rates, headcount targets, pricing), increasing buffer stocks (cash reserves, inventory), or changing physical infrastructure. Easy to implement but rarely changes fundamental behavior. Appropriate for fine-tuning well-functioning systems, not fixing structural dysfunction.
• Points 9-7 (Medium Leverage -- Delays, Feedback Loops): Reducing delays (shortening reporting cycles, accelerating feedback), strengthening balancing loops (adding accountability mechanisms, regulations, audits), weakening reinforcing loops (limiting positive feedback that creates harmful growth or decline). Often achievable with organizational or process changes. A company that reduces its strategic planning cycle from annual to quarterly (Point 9) often responds to market changes dramatically faster.
• Points 6-5 (High Leverage -- Information and Rules): Changing who has access to what information (Point 6) and changing rules, incentives, and constraints (Point 5). Information interventions are often the cheapest and most underestimated lever. If loan officers see the 10-year default rates of their own loans, behavior changes. If developers see the production cost of their technical debt, prioritization changes. Rule changes restructure incentives that drive all downstream behavior.
• Points 4-3 (Structural Leverage -- Self-Organization and Goals): Enabling systems to change their own structure (markets, agile organizations, evolutionary processes) and changing the stated goal of the system. A company that shifts its stated goal from "maximize quarterly EPS" to "maximize 10-year stakeholder value" restructures every downstream decision. Goal changes are powerful but require sustained leadership commitment to override inertia.
• Points 2-1 (Transformational Leverage -- Paradigm and Meta-Paradigm): Changing the shared beliefs and assumptions that created the system (paradigm shift) or developing the flexibility to operate across paradigms (transcending paradigm). The hardest to change, the most powerful. Paradigm shifts -- from "growth is always good" to "sustainable scale" -- restructure what goals are conceivable, what rules are legitimate, what information matters.

For each leverage point considered, explicitly state: the mechanism of action, the anticipated effect on the dominant feedback loop, the likely delay before effect is visible, and the most probable unintended consequence.

Step 6: Test the Model and Stress-Test Interventions

A systems model is a hypothesis, not a fact. Before recommending interventions, stress-test the model.

• Mental simulation: Walk through the system's response to a proposed intervention. "If we hire 20% more engineers, the stock of employees increases, which initially increases capacity. But onboarding load increases, reducing productivity of senior engineers, which increases their burnout risk..." Trace the causal chain through at least three feedback cycles.
• Historical validation: Ask whether the model would have correctly predicted past behavior. If the model predicts growth when the system showed decline, the model is wrong. Revise until it accounts for known history.
• Boundary testing: What happens at extreme values? If demand doubles suddenly, does the model produce plausible behavior? If a key variable goes to zero, does the system collapse, recover, or oscillate? Extreme inputs reveal structural weaknesses.
• Unintended consequence check: For every proposed intervention, ask "what does this change in the feedback structure, and what loops might now become dominant that were previously secondary?" The most common systems thinking error is identifying the right lever but failing to anticipate the loop that becomes dominant after the intervention changes loop balance.
• Time horizon sensitivity: Some interventions look effective in a 6-month window and destructive in a 5-year window. Fixes That Fail archetypes only appear at longer time horizons. Always test recommendations at multiple time scales.

Step 7: Recommend Interventions with Structural Clarity

Translate the analysis into actionable recommendations anchored in the causal structure, not generic advice.

• State which leverage point each recommendation targets (using the Meadows numbering) and why that point is accessible given the user's constraints.
• Distinguish between symptomatic interventions (fast, necessary for crisis management, but insufficient alone) and structural interventions (slower, address root cause, create lasting change). Almost every situation requires both, sequenced appropriately.
• Provide leading indicators -- measurements the user can take now that will signal whether the system is changing before the lagging outcomes improve. In a hiring crisis, leading indicators include time-to-offer, offer acceptance rate, and onboarding satisfaction scores -- all visible months before headcount stabilizes.
• Identify the most dangerous assumption in the analysis and suggest how to test it cheaply before committing to expensive interventions.
• Recommend a monitoring structure: which stocks to measure, at what frequency, and what behavior over time would signal the intervention is working versus that it has triggered an unexpected loop.

Step 8: Communicate the Model to Stakeholders

A systems model only generates value if it changes how decision-makers think and act. Communication is not an afterthought.

• Use Behavior Over Time graphs to align stakeholders on the problem before introducing causal structure. People agree on what happened before they agree on why.
• Narrate causal loop diagrams as stories rather than presenting them as diagrams. "When we cut marketing spend to hit quarterly targets, we reduce the awareness flow into our customer acquisition funnel. Twelve months later, the customer stock has dropped 15%, which reduces revenue, which creates pressure to cut marketing further..." Stories are understood; diagrams are accepted and then ignored.
• Present the archetype diagnosis by name. "This is a classic Shifting the Burden structure. Here's what that means for us..." Named archetypes carry pre-built intuitions that accelerate understanding.
• Explicitly separate events (what happened) from patterns (the trend) from structure (the feedback loops) from mental models (the assumptions that created the structure). This is the Iceberg Model. Interventions at the event level are reactive; interventions at the structure and mental model level are transformational. Ask stakeholders: "At which level are we currently intervening?"

---

Output Format

When delivering a systems thinking analysis, structure the output as follows. Adapt depth to the complexity of the request -- a quick archetype identification needs less than a full causal model.

---

Systems Analysis: [System Name or Problem Statement]

Dynamic Problem Statement [Describe the behavior of the key variable over time -- not just current state. Include approximate time horizon.]

Behavior Over Time Graph (Verbal) [Describe the shape of 2-4 key variables over time: growth/decline rate, inflection points, phase relationships between variables. If the user can draw, suggest they sketch it.]

---

Stocks and Flows Map

Stock	Key Inflows	Key Outflows	Current Level (if known)	Critical Delays
[Stock name]	[Inflow 1], [Inflow 2]	[Outflow 1], [Outflow 2]	[High / Low / Unknown]	[Delay in weeks/months]

---

Causal Loop Diagram (Narrative)

[For each identified loop:]

Loop [Label] ([R/B] -- [Short name]): [Variable A] --(+/-)--> [Variable B] --(+/-)--> [Variable C] --(+/-)--> [Variable A] Story: [One sentence causal narrative of the loop] Current dominance: [Is this loop currently driving behavior? Why?] Key delay: [Where is the most important delay in this loop, and what does it cause?]

---

Archetype Diagnosis

Archetype	Present?	Evidence	Structural Implication
Fixes That Fail	Yes / No / Partial	[Observable evidence]	[What the structure predicts will happen]
Shifting the Burden	Yes / No / Partial	[Observable evidence]	[What capability is being eroded]
Tragedy of the Commons	Yes / No / Partial	[Observable evidence]	[Which shared resource is at risk]
Limits to Growth	Yes / No / Partial	[Observable evidence]	[What the binding constraint is]
Escalation	Yes / No / Partial	[Observable evidence]	[What the arms race is over]

---

Leverage Point Analysis

Intervention	Leverage Point (Meadows #)	Mechanism	Expected Delay	Primary Risk
[Intervention 1]	[#] -- [Name]	[How it changes feedback structure]	[Weeks/months/years]	[Most likely unintended consequence]
[Intervention 2]	[#] -- [Name]	[How it changes feedback structure]	[Weeks/months/years]	[Most likely unintended consequence]

---

Recommended Intervention Sequence

1. Immediate (0-3 months) -- Symptomatic relief: [What to do now to stop the bleeding, with acknowledgment that this is not the structural fix]
2. Short-term (3-12 months) -- Feedback loop restructuring: [The structural intervention targeting the dominant loop]
3. Long-term (1-3 years) -- Paradigm or goal shift: [If applicable, the deeper change required for lasting resolution]

Leading Indicators to Monitor:

• [Indicator 1]: Measure [frequency], expect to see [behavior] if intervention is working
• [Indicator 2]: Measure [frequency], watch for [warning signal] as early warning of unintended loop

Most Dangerous Assumption: [State the single assumption in the analysis that, if wrong, would invalidate the recommended intervention. State how to test it.]

---

Rules

1. Never begin with a solution. Always map the causal structure before recommending interventions. A solution proposed before the feedback structure is understood is just a guess with confident language. The most common failure mode in organizational problem-solving is jumping to a fix before understanding why the system produces the observed behavior.

2. Distinguish events from structure. Events (a bad quarter, a key departure, a lost customer) are outputs of structure. Analyzing events without identifying the underlying feedback loops that produce them will yield reactive, symptomatic interventions. Always push the analysis one level deeper: "What feedback structure would reliably produce this event?"

3. Always identify delays explicitly. Delays are the single most common cause of systems failure that looks like human error. When someone says "we tried that and it didn't work," the answer is almost always that they didn't wait long enough for the balancing loop to close, or they didn't account for the delay between intervention and effect. Mark every significant delay in the causal loop diagram.

4. Never claim a loop is Reinforcing or Balancing without counting arrow polarities. Intuition about loop type is frequently wrong, especially in complex diagrams with many variables. Count the negative (-) arrows. Even number = Reinforcing. Odd number = Balancing. This is a logical rule, not a judgment call.

5. Stocks change slowly -- never propose interventions that assume otherwise. You cannot rapidly change a stock. Trust built over years is not rebuilt in weeks. Technical debt accumulated over three years is not eliminated in a sprint. Customer relationships are stocks. Culture is a stock. When a user's intervention plan assumes rapid stock change, flag it explicitly and reframe the timeline.

6. Do not conflate the system boundary with the problem boundary. The most important causal loops may lie outside the organizational boundary the user is managing. A company's hiring problem may be driven by a regional labor market loop outside its control. A product's growth problem may be driven by an ecosystem loop involving regulators, competitors, and infrastructure. Always ask: are the dominant loops inside or outside the user's boundary of control?

7. Match archetype to observed behavior, not to intuition about causes. Archetypes are validated by behavioral signatures, not by the user's narrative about why problems occur. A user who says "we keep solving the same problem" may be in Fixes That Fail or Shifting the Burden or Limits to Growth -- the archetype is determined by the feedback structure, not the user's framing. Always ask for behavior over time before naming an archetype.

---

Edge Cases

When the System Is Tightly Coupled and in Crisis

A system in active crisis (a product launch failure, an organizational collapse, a rapidly escalating customer loss spiral) is tightly coupled: actions propagate fast, delays are short, and small interventions produce large effects. Standard systems modeling -- which assumes time to observe and deliberate -- may be too slow.

In this case: first stabilize the system using symptomatic interventions explicitly labeled as temporary. Build a rapid causal map (30-60 minutes, not days) focused on the two or three most active loops. Identify the one intervention that reduces the most harmful reinforcing loop. Implement it while narrating its limitations to stakeholders. Then do the full analysis once the system is no longer in freefall. Never let the perfect model be the enemy of a good enough intervention in a crisis.

When the User Is an Actor Inside the System

A manager analyzing their own organization, a policymaker analyzing their own agency, or a founder analyzing their own company is part of the system they are modeling. Their mental models, decisions, and behaviors are variables in the causal loop diagram. This creates two complications: (1) the user's framing of the problem reflects their position in the system and may systematically exclude loops that implicate their own behavior; (2) recommendations that require changing the user's behavior or mental model face internal resistance that purely external interventions do not.

Handle this by: naming it explicitly but tactfully ("One loop worth considering is how leadership decision-making style affects information flow..."). Include the user's role as a variable in the CLD. Ask questions that surface implicit assumptions: "What would have to be true about your organization for this problem to be producing itself?" Avoid assigning blame; assign structure.

When There Is Insufficient Data to Validate the Model

Systems thinking is often applied precisely because data is sparse, delayed, or untrustworthy. A causal model built on anecdote and intuition is still a model -- it just has higher uncertainty.

In this case: make the assumptions explicit and enumerate them as a list. Label each causal arrow with a confidence level (High/Medium/Low) or note which relationships are assumed versus validated. Recommend cheap observational tests to validate the most critical assumptions before committing to expensive interventions. Use the model to identify what data is most worth collecting, rather than waiting for comprehensive data before modeling.

When Multiple Stakeholders Have Conflicting Mental Models

In organizational and policy contexts, different stakeholders will map the same system differently because they observe different variables, operate at different time scales, and have different interests. A causal loop diagram built with one stakeholder will be rejected by another.

Handle this by: facilitating a Group Model Building session rather than delivering a finished model. Group Model Building -- developed by Jac Vennix -- is a structured process where stakeholders collaboratively build a shared causal map, surfacing and negotiating conflicting mental models. Even a rough shared model that stakeholders helped build is more actionable than a perfect model they didn't. The process of building the model is often as valuable as the model itself.

When the User Wants Quantitative Precision

Some users -- engineers, financial analysts, supply chain managers -- will want more than qualitative causal maps. They want numbers: how much does a 10% increase in attrition affect delivery capacity over 18 months?

In this case, escalate to System Dynamics modeling. Recommend: Vensim PLE (free, industry standard for professional SD modeling), InsightMaker (free, web-based, lower learning curve), or PySD (Python library for running Vensim models in Python environments). Frame the qualitative CLD as the necessary first step before parameterizing a simulation model -- you cannot build a valid quantitative model without first validating the causal structure qualitatively. Warn that parameterizing a model requires real data for stocks (initial values), flows (rates), and delays -- and that a poorly parameterized simulation is more dangerous than a well-reasoned qualitative model because it generates false precision.

When the Dominant Loop Is Outside the User's Control

A common and frustrating finding in systems analysis is that the most important leverage points are outside the user's span of control: industry-wide market dynamics, regulatory structures, geopolitical forces, platform policies set by monopolistic infrastructure providers. The user can see the system clearly but cannot intervene at the highest-leverage points.

In this case: be honest about this structural reality rather than forcing lower-leverage internal interventions into a high-leverage framing. Help the user identify: (1) the highest-leverage internal intervention they can actually make, (2) coalition strategies for influencing external loops (industry groups, regulatory engagement, standards bodies), and (3) adaptive strategies that make the user's system resilient to the external loop rather than dependent on changing it. Resilience to an uncontrollable loop is often more valuable than a failed attempt to change it.

When the System Shows Pathological Oscillation

Some systems oscillate persistently -- inventory over- and under-ordering, hiring freezes followed by aggressive hiring, quality crises followed by over-investment in quality processes. Oscillation is the behavioral signature of a balancing loop with a significant delay and inadequate information.

The structural fix for oscillation is almost never "try harder" or "be more disciplined" -- it is to reduce the delay, improve information quality, or change the decision rule. Specifically: if the delay cannot be reduced (it is material, not informational), the decision rule must account for the delay by aiming at where the system will be, not where it is now. This is a non-obvious insight that contradicts intuitive management behavior. Name it explicitly and provide the structural implication: a hiring manager should target the headcount they need in 9 months (accounting for ramp time), not the headcount gap today.

---

Example

User Input: "Our engineering team keeps oscillating between being massively overloaded and having slack time. When we're overloaded, quality drops, people burn out, and a few leave. Then we hire a bunch of people, and for a while everyone has too little to do. Then we win more contracts, get overloaded again, and the cycle repeats. We've been in this pattern for four years. What's going on?"

---

Systems Analysis: Engineering Capacity Oscillation

Dynamic Problem Statement Engineering capacity oscillates with a period of approximately 12-18 months between severe overload (resulting in quality degradation and attrition) and underutilization. The oscillation has persisted for four years despite repeated hiring interventions. The problem is not insufficient hiring -- the problem is the structure that produces cyclical overload and underutilization regardless of how much is hired.

Behavior Over Time Graph (Verbal)

• Engineering capacity (available person-weeks): Oscillates. Troughs during overload phases; peaks shortly after hiring surge completes and before new contracts are won.
• Workload (contracted person-weeks required): Grows in surges (contract wins) with relatively flat periods between. Leads capacity by approximately 3-6 months at each cycle peak.
• Attrition rate: Spikes 3-4 months after each overload peak, lagging workload peaks by the time it takes burnout to translate to departures.
• Quality metrics (defect rate, rework): Rise during overload phases, fall during underutilization phases. Lead attrition by 1-2 months.

---

Stocks and Flows Map

Stock	Key Inflows	Key Outflows	Current Level	Critical Delays
Engineering headcount	Hiring rate	Voluntary attrition, involuntary exits	[User to confirm]	7-14 months from recognition of need to full productivity
Productive capacity (effective person-weeks/month)	Headcount increase, onboarding completion, skill development	Overload-driven productivity loss, attrition, onboarding burden on senior engineers	Oscillating	3-6 months from hire to meaningful contribution
Contracted workload backlog	Contract wins	Delivery completions, scope reduction	Growing during overload	1-3 months from contract signature to work mobilization
Engineering morale and discretionary effort	Positive work experiences, recognition, meaningful work	Sustained overload, quality-related frustration, perceived futility	Low during overload peaks	2-4 months lag between workload and morale change
Organizational reputation as employer	Positive candidate experiences, employee referrals, external reputation	Burnout departures, Glassdoor-type signals, word of mouth in engineering community	Degrading slowly	6-18 months from attrition events to measurable recruiting impact

---

Causal Loop Diagram (Narrative)

Loop B1 (B -- Hiring Response): Workload backlog --(+)--> Perceived understaffing --(+)--> Hiring rate --(+)--> Headcount --(+)--> Productive capacity --(-)-- Workload backlog Story: When backlog grows, management perceives understaffing, initiates hiring, headcount increases, capacity grows, and eventually backlog is reduced. Current dominance: This loop is intended to be dominant but is systematically frustrated by the delay below. Key delay: 7-14 months from hiring trigger to full productive capacity. Management typically expects relief in 3-4 months, waits 6, sees no relief, hires more -- and then overshoots.

Loop R1 (R -- Burnout Spiral): Workload backlog --(+)--> Individual workload per engineer --(+)--> Burnout and stress --(+)--> Voluntary attrition --(-)-- Headcount --(-)-- Productive capacity --(+)--> Workload backlog Story: High backlog increases individual load, which drives burnout and attrition, which reduces capacity, which increases individual load further. Current dominance: Dominant during the overload phase. This loop is why the overload phase accelerates rather than stabilizing -- each departure worsens conditions for those who remain. Key delay: 3-5 months from sustained overload to attrition spike -- enough delay to make the causal connection invisible without data.

Loop R2 (R -- Onboarding Burden): Hiring rate --(+)--> New employees being onboarded --(+)--> Senior engineer onboarding burden --(-)-- Senior productive capacity --(+)--> Effective backlog per experienced engineer Story: The very act of hiring to solve the overload problem temporarily worsens it by consuming senior engineer time for onboarding and mentoring. Current dominance: Active during each hiring surge. Explains why adding headcount initially makes delivery worse before it makes it better -- a counterintuitive pattern that causes management to doubt the hiring strategy and sometimes halt it prematurely. Key delay: 2-4 months of degraded senior capacity per new hire cohort.

Loop R3 (R -- Reputation Erosion): Attrition rate --(+)--> Employer reputation damage --(+)--> Recruiting difficulty --(+)--> Time-to-fill open roles --(+)--> Capacity gap duration --(+)--> Overload --(+)--> Attrition rate Story: High attrition damages the organization's reputation as an employer, making future hiring harder and slower, extending the overload phase, driving further attrition. Current dominance: Grows stronger with each cycle. If four years of oscillating attrition has been producing employer brand signals, this loop is becoming increasingly important and explains why each cycle is harder to recover from than the last. Key delay: 6-18 months for reputation effects to translate into measurable recruiting pipeline changes.

Loop B2 (B -- Contract Modulation): Productive capacity --(+)--> Sales confidence --(+)--> Contracts sold --(+)--> Workload backlog --(-)-- Productive capacity Story: When the team has slack, sales pursues and wins more contracts, rebuilding the backlog. This is the loop that restarts the overload cycle after each hiring surge. Current dominance: Dominant during the underutilization phase. This is the loop that initiates each new overload cycle -- sales correctly identifies slack capacity and fills it, but without coordination with engineering on sustainable throughput, they fill it to overload.

---

Archetype Diagnosis

Archetype	Present?	Evidence	Structural Implication
Fixes That Fail	Yes	Hiring fixes overload temporarily but creates onboarding burden and reputation erosion that worsen future overload	Each hiring surge partially addresses symptom but strengthens the conditions for the next cycle
Shifting the Burden	Partial	Reliance on emergency hiring rather than building sustainable capacity planning capability	Capacity planning muscle may be atrophying -- management relies on reactive hiring rather than developing predictive staffing models
Limits to Growth	Yes	Reinforcing contract-winning growth is hitting the balancing constraint of engineering capacity, with oscillation as the signature behavior	The constraint is not hiring speed alone but the 7-14 month delay from need to productive capacity
Escalation	No	No second party engaged in a competitive response loop	N/A
Tragedy of the Commons	Partial	Senior engineer time is a shared resource consumed by both delivery and onboarding; no explicit governance of how it is allocated	Risk that senior engineers will protect themselves by disengaging from onboarding or delivery, triggering a different crisis

---

Leverage Point Analysis

Intervention	Leverage Point (Meadows #)	Mechanism	Expected Delay	Primary Risk
Hire faster (reduce time-to-offer)	9 -- Delays	Reduces the B1 loop delay, allowing balancing loop to close faster and reducing overshoot	2-4 months to implement, 3-6 months to affect capacity	Does not address the fundamental oscillation driver; B2 loop will still refill capacity to overload
Implement capacity buffer (maintain 10-15% slack target)	11 -- Buffer sizes	Maintains a capacity buffer stock that absorbs demand surges without triggering overload	Immediate if slack exists; requires 6-12 months to build if starting from overload	Sales will resist "idle" capacity; requires leadership commitment and a new mental model about slack
Create integrated sales-engineering capacity governance	8 -- Balancing feedback loops	Strengthens the B1 and B2 loops by connecting sales contracting decisions to engineering capacity in real time	3-6 months to implement governance process	Requires changing sales incentives (currently rewarded for bookings, not for sustainable delivery)
Change sales incentives to include delivery margin, not just booking revenue	5 -- Rules	Restructures the incentive that drives Loop B2 to overshoot; sales now has a stake in sustainable load	6-12 months for incentive change to fully affect behavior	Sales may resist; requires executive sponsorship; may reduce short-term revenue
Publish real-time capacity utilization to sales, delivery, and leadership	6 -- Information flows	Makes the capacity stock visible to all actors simultaneously, reducing information delays that cause misaligned decisions	1-3 months to implement a dashboard	Only effective if decision-making processes are structured to use the information; information without decision authority changes little
Shift organizational goal from "maximize contracts won" to "maximize sustainable delivery throughput"	3 -- Goals	Restructures what success means for sales, engineering leadership, and executives, changing all downstream rules and information requirements	12-24 months to fully internalize	Requires board and investor alignment if publicly visible metrics are affected

---

Recommended Intervention Sequence

1. Immediate (0-3 months) -- Symptomatic relief: If currently in overload, implement emergency capacity measures (contractor augmentation for non-core work, scope renegotiation with clients on 1-2 lowest-margin or lowest-strategic-value contracts, explicit workload reduction of 15-20% for engineers showing burnout signals). Label these explicitly as temporary. Do not allow them to become permanent without addressing the structural cause.

2. Short-term (3-12 months) -- Feedback loop restructuring:

   • Implement a capacity visibility dashboard showing current capacity, committed backlog, projected capacity in 3, 6, and 12 months (accounting for current hiring pipeline and ramp delays). Make this visible to sales and delivery leadership weekly.
   • Establish a Sales-Engineering Capacity Review meeting (bi-weekly) with explicit contracting authority: no new contracts can be committed without engineering capacity sign-off against the 12-month forward model.
   • Change sales incentive structure to include a delivery quality and margin component weighted at 25-30% of total variable compensation.
   • Implement a structured onboarding program that explicitly caps senior engineer onboarding time at 15% of weekly capacity per cohort, with a formal handoff timeline.

3. Long-term (1-3 years) -- Paradigm shift: Move the organizational mental model from "maximize revenue" to "maximize sustainable delivery capacity." This requires: redefining the company's growth story to investors and clients around quality and reliability rather than volume; building a predictive capacity planning capability (using 12-18 month rolling workforce models, not reactive headcount requests); and investing in employer brand repair by systematically gathering and acting on exit interview data, improving return-to-company pathways, and building university recruiting pipelines that are not disrupted by short-term hiring freezes.

Leading Indicators to Monitor:

• Capacity utilization rate: Measure weekly. Target 80-85% utilization (not 95-100%). If consistently above 90%, the next overload cycle is 3-6 months away.
• Senior engineer onboarding hours per week: Measure monthly. If above 15% of senior capacity, new hire cohorts are creating a drag that will manifest as delivery quality problems in 4-8 weeks.
• Time-to-offer for open roles: Measure monthly. If increasing, reputation or process issues are extending the B1 loop delay and worsening future oscillation risk.
• Sales pipeline vs. 12-month capacity forecast gap: Measure monthly. If pipeline exceeds capacity by more than 20%, the B2 loop is primed to trigger the next overload cycle without governance intervention.
• Voluntary attrition by tenure band: Measure monthly. A spike in 2-4 year tenure attrition is the earliest signal that the Burnout Spiral (R1) is activating.

Most Dangerous Assumption: The analysis assumes the overload-attrition-reputation reinforcing loop (R3) has not yet permanently damaged the employer brand enough to make each subsequent hiring cycle materially harder. If attrition over four years has been generating sustained negative employer reputation signals in the target engineering community, the capacity recovery time in each cycle is extending, not staying constant. Test this by: pulling recruiting funnel conversion rates (applicant-to-interview, interview-to-offer-acceptance) over the last 4 years. A declining offer acceptance rate is the signature of reputation erosion. If confirmed, employer brand investment is not optional -- it becomes as urgent as the governance and incentive changes.