One Big Table Consulting ← All Advanced Analytics

Domain 4 — Scenario modeling and Monte Carlo simulation for comp plans, dark OBT theme

Domain 4 — Scenario modeling and Monte Carlo simulation
Core role skill · 6 sections · Live Monte Carlo engine · Sensitivity analysis · Quiz at end
Why deterministic models are not enough
A deterministic model says: "if 100 reps hit 90% attainment, total comp cost is $X." That's useful — but it's wrong in a specific way. Attainment is not a single number. It's a distribution. Some reps will hit 60%, some 120%, some 150%. The average might be 90%, but the cost is not the cost of everyone hitting exactly 90%.

The rep who hits 150% costs dramatically more than the rep who hits 60%. If 20% of your rep population lands in the accelerator zone, your cost can be 30–40% above what the deterministic model predicted. Finance needs to know that before the plan launches — not after Q4.
Deterministic: Cost = Σ [Base + TI × curve(avg_attain)] ← WRONG
Correct: Cost = Σ [Base + TI × curve(attain_i)] for each rep i
Because the payout curve is nonlinear (accelerator above quota), the cost of the average attainment ≠ the average cost. Jensen's inequality. This is not a rounding error — it can be millions of dollars at scale.
The two simulation tools — when to use each
Scenario modeling — structured, fast, communicable
Define 3 attainment scenarios (downside / base / upside) with specific mean and distribution assumptions. Run the payout formula across each. Output: a table showing cost, % at quota, and median payout under each scenario. Use for: leadership communication, CFO presentations, plan design review meetings. Fast to build, easy to explain.
Monte Carlo — probabilistic, rigorous, finance-grade
Simulate 1,000–10,000 random draws of attainment for each rep from a calibrated distribution. Record total cost for each simulation run. Output: a probability distribution of total cost with P10, P50, P90 estimates. Use for: budget reserve setting, risk quantification, stress testing. More rigorous — answers "what's the probability we exceed budget?"
How these connect to your DirecTV work
At DirecTV you built scenario models quantifying revenue exposure across satellite outage events — $4M at risk across 50+ DMAs. That is the exact same analytical pattern: define scenarios (partial outage / full outage / rapid restoration), apply a financial formula to each, aggregate across a population (DMAs → reps), deliver a range to leadership. The domain changes from outage risk to comp cost risk. The methodology is identical.
Scenario modeling — built step by step
Scenario modeling answers: "Under three plausible futures, what does this plan cost and how many reps hit quota?" You define the scenarios, apply the plan formula, aggregate the outputs, and present the range.
01
Lock plan structure
Base, TI, threshold, accel rate, cap — fixed constants
›
02
Define 3 scenarios
Anchor mean attainment in historical data — P25/P50/P75
›
03
Apply payout formula
Run each rep through Base + TI × curve(attain_i)
›
04
Aggregate and compare
Total cost, % at quota, median payout, cost % of revenue
Live scenario model — adjust assumptions, see outcomes
Downside
Mean attain72%
Std dev18%
Base case
Mean attain90%
Std dev22%
Upside
Mean attain108%
Std dev25%
Rep count100
TI per rep ($K)$60K
Downside Base case Upside
Say this in the interview
"Scenario modeling is how I give leadership a fast, readable view of plan cost before Monte Carlo is needed. I anchor the three scenarios in historical attainment data — not invented optimism or pessimism — so every number I present has a defensible source. The output isn't 'it will cost $14M.' It's 'under a realistic range of outcomes, cost falls between $11M and $18M, with $14M as the planning anchor.' That framing is what turns an analysis into a decision."
Monte Carlo simulation — the probability distribution of cost
Monte Carlo upgrades scenario modeling from "three hand-picked outcomes" to "a full probability distribution." Instead of assuming all reps land at the scenario mean, each simulation run draws a random attainment for every rep from the calibrated distribution, applies the payout formula, and records total cost. After 1,000+ runs, you have a distribution of possible total costs — and you can answer finance's real question: "What is the probability we exceed our budget?"
For each simulation i = 1 to N:
For each rep j = 1 to R: attain_j ~ Normal(μ, σ)
total_cost_i = Σ [Base + TI × curve(attain_j)]
After N runs: P50 = median(total_cost), P90 = 90th percentile(total_cost)
P50 = planning estimate. P90 = budget reserve target. Probability of exceeding budget = % of simulations above budget line. These three numbers are the Monte Carlo output that goes to finance.
Live Monte Carlo engine — run it now
Mean attainment (%)90%
Std deviation (%)20%
Rep count100
TI per rep ($K)$60K
Simulations (N)1,000
Within budget Above budget (P90 reserve zone) P50 marker
Say this in the interview
"Monte Carlo is how I answer finance's real question — not 'what will this cost' but 'what is the probability we exceed our budget?' I calibrate the attainment distribution to historical data, run a thousand simulations, and surface three numbers: P50 as the planning estimate, P90 as the reserve recommendation, and the probability of exceeding the proposed budget. The shape of the histogram also tells you something — a fat right tail means a small number of high-attaining reps could blow up the budget, which is a plan design signal."
Sensitivity analysis — which lever matters most
Scenario modeling and Monte Carlo tell you the cost range. Sensitivity analysis tells you which plan parameter is driving that range most. It answers: "If I change the accelerator rate by 50 basis points, how much does P90 cost move? What about changing the threshold? The cap?" This is what the hiring manager wants to see — not just the ability to run models, but the ability to identify which levers are high-stakes and which are low-stakes.
Sensitivity of cost to parameter X:
S(X) = ΔCost / ΔX = [Cost(X + δ) − Cost(X)] / δ
Run the full model at the base parameter value, then at the parameter + small increment δ. The ratio is the cost sensitivity. High sensitivity = small parameter change causes large cost change = high-stakes lever that needs careful governance.
Live sensitivity analyzer — see which levers move cost most
Base TI ($K)$60K
Rep count100
Mean attainment (%)90%
How to read and use sensitivity results
High sensitivity lever → requires governance gate
If a 10% change in accelerator rate moves P90 cost by $2M, that lever needs finance and HR sign-off before any change. Build a governance flag into the model: any parameter with sensitivity above a threshold triggers a formal review process.
Low sensitivity lever → design flexibility
If changing the threshold from 50% to 40% moves total cost by less than 1%, you have flexibility to optimize that lever for fairness or behavior without material financial risk. Flag it explicitly to the business so they don't over-govern low-stakes parameters.
Interaction sensitivity — the advanced version
When two parameters interact (e.g., accelerator rate AND product mix overlay both high), the combined sensitivity can be multiplicative, not additive. Always check interaction terms: run the model with both parameters changed simultaneously and compare to the sum of individual sensitivities. If they differ significantly, you have a nonlinear interaction that must be disclosed.
Say this in the interview
"Sensitivity analysis is how I tell the business which levers to govern carefully and which ones have design flexibility. I build a tornado chart showing cost sensitivity to each plan parameter — accelerator rate, threshold, cap, TI level. The parameters at the top of the chart are the ones that need a formal approval process before anyone changes them. The ones at the bottom can be adjusted for fairness or behavior without material financial risk. That prioritization is what makes the governance process efficient rather than bureaucratic."
How Microsoft uses simulation in comp plan design
The annual plan modeling cycle
Each January–April during plan design season, the comp analytics team runs a full simulation suite for every proposed plan change. The sequence is always: scenario model first (fast, for leadership alignment), then Monte Carlo (rigorous, for finance budget setting), then sensitivity analysis (for governance prioritization). All three outputs go into the plan design package submitted to the SIC governance committee.
The P90 reserve process
Finance sets the incentive comp budget at the P50 (median) Monte Carlo output. The analytics team recommends a reserve equal to P90 minus P50. This reserve is held in a contingency pool and released if actual attainment tracks above plan. The analytics team monitors monthly attainment vs. the P50 trajectory and flags early if the cost path is trending toward P90.
Mid-year amendment (MYA) re-modeling
Any mid-year plan change — accelerator rate adjustment, SPIFF approval, threshold change — triggers a re-run of the simulation suite on the modified plan. The analytics team produces a delta model: what does P50 and P90 cost change by under the amendment? If the delta exceeds a materiality threshold, it requires CFO-level sign-off. Below threshold, VP Finance can approve.
Segment-level vs. aggregate modeling
Microsoft runs simulation at the segment level (Enterprise, SMC, Partner) separately — not just in aggregate. This matters because attainment distributions vary significantly by segment. Enterprise reps have higher variance (larger deals, more lumpy attainment). SMC reps are more normally distributed. Aggregating them masks the tail risk in the Enterprise segment.
Behavioral response calibration
The hardest input to the model is the behavioral response assumption — how much does attainment change when you modify the plan? Microsoft's analytics team calibrates this using natural experiments: prior plan changes where one segment got a new accelerator rate and another didn't (a quasi-experiment). The measured attainment delta is the behavioral elasticity used in forward-looking models.
The question that separates senior candidates from junior ones
"How do you validate your Monte Carlo model?" Answer: back-test it. Take the last 3 plan years, run the Monte Carlo on each year's plan parameters and historical attainment distribution, and check whether actual cost fell within the P10–P90 range in all three years. If it did, the model is well-calibrated. If actual cost consistently exceeded P90, your distribution assumption is too narrow — widen sigma. This calibration conversation is what signals modeling maturity.
The full workflow — say this end to end
"When I assess a proposed plan change, I run three models in sequence. First, scenario analysis — three attainment assumptions anchored in historical data, fast output for leadership alignment. Second, Monte Carlo — calibrated distribution, 1,000+ simulations, P50 and P90 cost output for finance budget setting and reserve recommendation. Third, sensitivity analysis — tornado chart showing which parameters drive the most cost variance, used to prioritize the governance process. That sequence gives the business what it needs at every level of the decision hierarchy: fast intuition for leaders, probabilistic rigor for finance, and governance prioritization for HR and legal."
Domain 4 quiz — eight questions