Stocks-and-Flows Pipeline Diagnosis
Model any org process as stocks and flows, then find where reality disagrees with the model.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 93%
Systems thinking, applied operationally: represent a messy org problem (hiring, incidents, deploys) as stocks (things that accumulate) and flows (rates of movement between them), then pull the historical data and compare actuals against what the model predicts. The gap is the diagnosis. Larson's key discipline is the exit condition — the model exists to locate the fix, not to be perfected, and reality is never the thing that's wrong.
Origin
Systems thinking as stocks and flows comes from Donella Meadows' 'Thinking in Systems: A Primer', which Larson names as his first recommendation; he also cites Rachel Carson's 'Silent Spring' as the classic worked example (carcinogens concentrating up the food chain). Larson's contribution is the operational application to hiring pipelines and incident management at Stripe and Uber, plus the anti-pattern he learned by falling into it.
Core principles
- 01Stocks accumulate; flows move things between stocks at a rate.
- 02When the model and reality conflict, the model is wrong — reality is always right.
- 03The gap between model and actuals is where the learning is, and it points at the fix.
- 04A model is a means, not the work. Measuring forever without cutting produces no impact.
- 05Turning an abstract complaint into a stock-flow diagram makes it something you can work systematically.
How to run it
- 1
List the stocks
Name every place things accumulate in the process. For hiring: infinite potential candidates, sourced candidates, candidates past recruiter screen, past hiring-manager screen, at offer stage, accepted. Also count the resource stocks that drive rates, e.g. how many sourcers are dedicated to the role.
Pro tip Include the resourcing stocks, not just the pipeline stages — headcount of sourcers is what actually sets the sourcing flow rate.
- 2
Name the flows and their conversion rates
For each transition between stocks, define the flow and what governs its rate: sourcing, outreach and referrals as inflows; a conversion rate at each screen; an offer-extension rate; an offer-acceptance rate. Flows can run both directions (candidates drop out; fish reproduce).
Watch out A flow with no named driver is a guess. If you can't say what makes the rate go up or down, you haven't modelled it yet.
- 3
Pull the historicals and compare
Go to the system of record — Greenhouse or whatever the ATS is — and pull actual volumes at each stage. Compare how the historicals behave versus how your model expected them to behave, and find the drop-offs.
Pro tip The comparison, not the model, is the deliverable. Get to real numbers fast even if the model is crude.
- 4
Localise the failure to one flow
Read the drop-off pattern to identify which of the distinct failure modes you actually have. Larson's three hiring cases: (a) lots of candidates reach offer stage but few offers get extended — hiring managers can't reach conviction; (b) many offers extended, almost none accepted — a closing problem; (c) decisions and closes are both fine but too few candidates enter — a top-of-funnel problem.
Watch out The three cases demand opposite interventions. Fixing 'we're not rigorous enough on evaluation' when the real problem is a starved top of funnel makes things worse.
- 5
Stop modelling and go fix it
Once the model is close enough to localise the problem, stop refining it and go do the work. Set an explicit exit condition before you start so the analysis has a bottom.
Pro tip Ask yourself weekly: has anything actually improved, or have we only improved our measurement of the problem?
Watch out This is the trap Larson himself fell into at Stripe. Getting more accurate about a problem feels like progress and isn't.
In the wild
Stripe's API being down loses merchants money and loses Stripe merchants, so Larson's team did extensive analysis of incidents to understand why things weren't working. They built and refined the model of remediation, but got so caught up in the analysis that they lost track of whether anything was actually getting better. Larson counts himself, not the team, as the one stuck in the model.
→ The team was prioritising measurement rather than improvements. The realisation produced Larson's rule: measure twice, cut once — but you do eventually have to cut.
Instead of rolling out a big data-free change ('it feels like we're not hard enough on how we evaluate candidates'), model potential candidates → sourced → recruiter screen → hiring-manager screen → offer → accept, with a conversion rate on each edge, then pull the ATS historicals. Larson notes the common real cause two years prior was panicking hiring managers issuing offers to candidates who never passed the loop.
→ A complex, abstract, argument-prone problem becomes a specific broken conversion rate that one named person can be asked to fix.
Common mistakes
Deciding reality is wrong
Larson's observation is that some of the least successful but smartest people he's worked with were strong systems-thinking advocates. They find a spot where their model and reality conflict and conclude reality is wrong. The model is always the thing that's wrong; the conflict is the signal to go educate yourself, not to argue.
Modelling as a substitute for doing
You can keep improving a model indefinitely, and it always feels productive. Learning is a great use of systems thinking, but it isn't the whole job — at some point the model is close enough and you have to go make the change.
Applying the framework universally
Larson explicitly warns that no framework can be applied consistently and universally with good results. Stocks and flows suit staged, rate-driven processes; forcing it onto everything is how it becomes a liability.
Is it for you?
Best for
Engineering, product, or ops leaders facing a recurring, blame-prone process failure (hiring not converting, incidents not improving, deploys slow) where everyone has a theory and nobody has the drop-off data.
Not ideal for
One-off judgement calls, novel problems with no history to pull, or situations where you already know the fix and the modelling would just delay it.
From the transcript
“systems thinking is basically you try to think about stocks and flows so stocks are things that accumulate and flows are kind of the movement…”
“reality is never wrong reality is always right your model is always wrong if it's in conflict with with reality”
“then you can go to your your applicant tracking system like Greenhouse or or whatever and pull the the historicals”
“we weren't actually prioritizing improvements we were just prioritizing measurement”
From the episode
The engineering mindset
Will Larson (Carta, Stripe, Uber, Calm, Digg)