Engineering Conflict Model

A hybrid System Dynamics + agent-based simulation of engineering feedback degradation under delivery pressure, built in AnyLogic 8.9.9.

Core question: Can an organization appear increasingly aligned while its underlying technical risk is getting worse?

The model operationalizes the central hypothesis behind the Engineering Decisions articles:

There is a fundamental difference between "we have nothing to argue about" and "we no longer see the point in arguing."

It is an exploratory/explanatory simulation, not a predictive model of real engineering organizations. Its normalized variables and coefficients are model constructs, not empirically estimated organizational measurements.

Example run with a strongly delivery-oriented Product Manager (riskTolerance=0.8, deliveryBias=0.9) and low autonomy-boundary clarity (0.1). The UI separates underlying technical state from observable conflict and exposes the health of the engineering feedback channel.

The stock-and-flow model connects delivery expectations, delivery pressure, technical debt, technical risk, warning behavior, management response, engineering voice, signal effectiveness, psychological safety, and stabilization capacity.

The same structure with live simulation values.

The model combines:

• System Dynamics for continuous stocks, flows, delays, and feedback loops;
• agent-based modeling for an EngineerAgent and a ProductManagerAgent;
• LLM-driven behavioral policies for context-sensitive discrete decisions;
• governance mechanisms that can constrain or moderate discretionary management behavior.

The main causal path is:

delivery expectations
        |
        v
delivery pressure
        |
        +--------------------------+
        |                          |
        v                          v
technical debt               PM decision context
        |                          |
        v                          v
technical risk ---> engineer warning ---> PM response
                                         |
                    +--------------------+-------------------+
                    |                    |                   |
                    v                    v                   v
             signal effectiveness  psychological safety  stabilization
                    |                    |                   |
                    +---------+----------+                   |
                              v                              v
                       engineering voice               debt repayment
                              |
                              v
                       visible conflict

The model is designed to allow TechnicalRisk and VisibleConflict to diverge. Low visible conflict therefore does not automatically imply a healthy engineering system.

The model draws on several bodies of work:

These sources motivate the conceptual structure. They do not provide empirical estimates for the numerical coefficients used in this implementation.

Engineer actions:

STAY_SILENT
RAISE_WARNING
ESCALATE

Product Manager actions:

DEFER
ACKNOWLEDGE
ALLOCATE_CAPACITY

ESCALATE represents a stronger warning path in the current model; it is not a full multi-level organizational escalation hierarchy.

The LLM is used as a behavioral policy provider:

system state + traits + interaction history -> discrete action

It allows decisions to depend on combinations of context without hard-coding a complete decision table.

The LLM is not structurally required. The same architecture could use deterministic rules, probabilistic policies, empirical classifiers, or human-in-the-loop decisions instead.

All values such as EngineeringVoice, SignalEffectiveness, PsychologicalSafety, VisibleConflict, and TechnicalRisk are normalized simulation constructs. For example, PsychologicalSafety = 0.7 is not a psychometric survey score, and TechnicalRisk = 0.6 is not a 60% probability of an incident.

The implementation contains several interacting loops. The most important conceptual mechanisms are:

delivery pressure
-> short-term optimization / debt accumulation
-> technical debt
-> delivery degradation
-> delivery gap
-> more delivery pressure

technical risk
-> engineering warning
-> PM response
-> stabilization capacity
-> debt repayment
-> lower technical risk

ineffective or deferred warnings
-> lower signal effectiveness
-> weaker engineering voice
-> fewer warnings
-> less corrective intervention

ignored warnings
-> psychological safety erodes
-> willingness to speak decreases
-> fewer warnings surface

higher short-term delivery
-> delivery expectations rise
-> future delivery gap/pressure can increase

These loops are modeling assumptions. The simulation is used to study the trajectories and interaction effects that emerge when they operate together.

The current model includes three structural interventions.

These mechanisms represent governance rules rather than individual personality.

They allow the model to test a second question:

Can structural commitments and clear decision boundaries prevent or reduce feedback degradation under strong delivery pressure?

This distinction is essential when interpreting the model.

Examples include:

• technical debt contributes to technical risk;
• delivery pressure can increase debt accumulation;
• repeated ineffective responses can reduce future engineering voice;
• ignored warnings can erode psychological safety;
• allocated stabilization capacity increases debt repayment;
• delivery performance can change future delivery expectations;
• governance mechanisms can constrain otherwise discretionary behavior.

These relationships are part of the model design. The simulation does not "discover" them.

Questions that are meaningfully explored by running the model include:

• Can technical risk rise while visible conflict falls?
• Can repeated deferral create a persistent low-voice organizational regime?
• Do different PM response traits lead to different long-run trajectories?
• Can a committed stabilization budget prevent a debt/feedback trap?
• Does an error-budget threshold create a different equilibrium?
• How strongly does autonomy-boundary clarity moderate delivery pressure?
• Which outcomes remain stable across repeated stochastic LLM runs?

Simulation results support claims about this model under specified assumptions and parameters, not causal claims about real organizations without external validation.

• AnyLogic 8.9.9 (Personal Learning Edition or higher)
• A supported LLM provider:
  • Google Gemini, or
  • Ollama for local inference

1. Obtain an API key from Google AI Studio.
2. Open the model in AnyLogic.
3. Set geminiApiKey in the model variables.

The model can also read GEMINI_API_KEY from the environment when the model variable is empty.

Set:

llmProvider = "OLLAMA"

and configure llmEndpoint for the local Ollama server.

The current model exposes llmModel and provider configuration in the model. Record the provider, exact model, and generation settings when publishing experiment results: LLM behavior can change between models and versions.

Configure the scenario before running the simulation.

The baseline scenarios are deliberately stylized. Values such as 0.2, 0.5, and 0.8 are experimental settings, not calibrated real-world personality scores.

Example structural tests:

Where:

CSB = CommittedStabilizationBudget
EBT = ErrorBudgetThreshold
ABC = AutonomyBoundaryClarity

For stochastic LLM scenarios, run multiple replications rather than interpreting a single trajectory as representative.

The primary plot compares:

• TechnicalRisk
• VisibleConflict
• ApparentAlignment

A widening gap between technical risk and visible conflict is the model's central observable phenomenon.

Tracks:

• EngineeringVoice
• SignalEffectiveness
• PsychologicalSafety

These are related but distinct constructs:

SignalEffectiveness = does speaking appear to influence decisions?
PsychologicalSafety = does speaking feel safe?
EngineeringVoice    = how strongly engineering concerns actually surface?

Tracks:

• TechnicalDebt
• ActualDeliveryRate
• ExpectedDeliveryRate

This exposes the interaction between short-term delivery pressure and longer-term technical consequences.

Do not interpret normalized values literally.

Incorrect:

TechnicalRisk = 0.7 means a 70% chance of system failure.

Correct:

Within the model's normalized risk scale, the scenario reached a substantially higher technical-risk state than the comparison scenario.

Incorrect:

ApparentAlignment = 0.93 means the real organization is 93% aligned.

Correct:

The model shows very low visible conflict despite high underlying technical risk.

Likewise, differences between scenarios should be reported with the full parameter configuration and multiple runs.

Experiments performed during development indicate several recurring behaviors in the current model configuration:

1. Visible conflict can fall while technical risk remains high or rises.
2. Strong delivery-oriented response regimes can degrade signal effectiveness, psychological safety, and engineering voice.
3. Pre-committed stabilization capacity can materially change the trajectory even when PM traits remain delivery-oriented.
4. Risk-triggered stabilization can constrain technical debt around a threshold-dependent equilibrium.
5. Autonomy-boundary clarity can materially moderate debt accumulation under delivery pressure.

These are simulation findings, not empirical findings about real organizations.

Exact numerical results depend on model version, scenario parameters, LLM provider/model, and stochastic runs. For that reason this README intentionally avoids presenting development-run numbers as universal constants.

The model has undergone several forms of internal validation during development:

The Engineer and Product Manager LLM policies were tested across combinations of:

• technical risk;
• risk tolerance;
• assertiveness / delivery bias;
• warning history;
• response history.

The purpose was to verify action-space coverage and directional sensitivity, not to claim empirical human-behavior calibration.

Baseline and governance scenarios have been executed repeatedly to distinguish stable model regimes from single stochastic LLM trajectories.

Governance parameters such as:

• CommittedStabilizationBudget;
• ErrorBudgetThreshold;
• AutonomyBoundaryClarity

are varied independently and in combination to test whether headline outcomes are robust to structural interventions.

The model has not been externally validated against longitudinal data from real engineering organizations.

Therefore it should not be used as:

• a forecasting model;
• a personnel assessment tool;
• a quantitative risk calculator;
• evidence that a particular real-world management style will produce a specific numerical outcome.

The model intentionally simplifies a much larger sociotechnical system.

Current limitations include:

• Product–Engineering interaction is represented through a Product Manager response agent and delivery-pressure dynamics rather than a complete bargaining model.
• There are no explicit utility functions, reservation points, or negotiated settlements in the Schelling/game-theoretic sense.
• ESCALATE is a stronger warning path, not a complete multi-level organizational escalation hierarchy.
• Engineer exit/attrition is not modeled.
• PM traits do not currently drift endogenously over time.
• Psychological safety is a normalized simulation construct, not a validated psychometric measurement.
• Technical risk is a normalized state variable, not an empirical probability of failure.
• Several coefficients and time constants are modeling assumptions and require external calibration for empirical use.
• LLM policies introduce provider/model dependence and stochasticity.
• AnyLogic is required to execute the native model.

The intended scope is:

Simulation of engineering feedback degradation under different delivery-pressure, management-response, and governance conditions.

The model is not intended as a complete simulation of Product–Engineering conflict.

In particular, it does not attempt to fully model:

• product strategy formation;
• all tactics-vs-strategy conflicts;
• formal bargaining utilities;
• organizational politics;
• employee exit;
• compensation or performance systems;
• the full hierarchy of escalation.

The articles provide the broader sociotechnical argument. The simulation operationalizes one narrower hypothesis as an executable model:

repeated ineffective engineering feedback
        ->
weaker feedback channel
        ->
less visible disagreement

while

technical risk may remain high or continue to grow

The model should therefore be understood as a formal exploration of a mechanism, not as proof of the article's thesis.

When reporting an experiment, record at minimum:

• repository/model version or commit;
• AnyLogic version;
• simulation horizon;
• number of runs;
• PM riskTolerance;
• PM deliveryBias;
• CommittedStabilizationBudget;
• ErrorBudgetThreshold;
• AutonomyBoundaryClarity;
• LLM provider;
• exact LLM model;
• generation settings such as temperature;
• any manual changes to model coefficients.

For LLM-driven experiments, a single run is insufficient for robust comparison.

EngineeringConflictModel/
├── EngineeringConflictModel.alp
├── README.md
├── RESEARCH.md
├── screenshots/
│   ├── screenshot-ui.png
│   ├── screenshot-sd-diagram.png
│   └── screenshot-sd-running.png
├── experiments/
│   ├── baseline/
│   └── sensitivity/
└── results/

Git history should be used for model versions rather than keeping timestamped model copies in the repository root.

• Schelling, T. C. (1960). The Strategy of Conflict. Harvard University Press.
• Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.

Add the repository's actual license here once a LICENSE file is included. Do not assume a license from repository visibility alone.