The Bathtub Analogy
To understand any system, start by finding the Stocks.
1. Stocks (The Tank)
A Stock is an accumulation of something at a point in time. It is what you would see if you froze the system and took a snapshot. Stocks are nouns — they are things that pile up or deplete.
- Everyday examples: Water in a bathtub, money in a bank account, unread emails in your inbox.
- Engineering examples: Tickets in a JIRA backlog, containers running in a cluster, technical debt in a codebase, trust within a team, error budget remaining in an SLO.
2. Flows (The Pipes)
Stocks only change through Flows. A flow is the rate of movement of stuff into or out of a stock over time. Flows are verbs — they are actions that happen continuously.
- Inflow: The faucet turning on (filling the tub). New tickets being created. New engineers being hired. New features being requested.
- Outflow: The drain opening (emptying the tub). Tickets being closed. Engineers leaving. Features being shipped.
The net change in any stock is simply: Inflow minus Outflow. If your team creates 20 tickets per week (inflow) and closes 15 (outflow), the backlog (stock) grows by 5 tickets per week. This is arithmetic, but it is powerful arithmetic because most people stare at the stock ("the backlog is huge!") without examining the flows that created it.
The Critical Insight:
You cannot change a stock directly. You can only change the flows. If you want to reduce the JIRA backlog (stock), you cannot just "wish" it lower. You must either slow down ticket creation (reduce inflow) or speed up ticket resolution (increase outflow). This sounds obvious, but watch how many incident retrospectives focus on the stock ("we had too many alerts!") without ever examining the flows ("why are we generating so many alerts?" and "why is our alert resolution so slow?").
Stocks also act as buffers. They decouple inflows from outflows. A message queue (stock) lets producers (inflow) and consumers (outflow) operate at different speeds without breaking. A deployment pipeline with a staging environment (stock of validated builds) decouples the rate of code commits from the rate of production deployments. Understanding where your system has buffers — and where it doesn't — is essential for designing resilient architectures.
Key Point: Stocks change slowly because they are accumulations. This is why organizational culture is so hard to change (it is a stock of habits, norms, and trust built over years), and why a single good sprint cannot erase months of accumulated tech debt. Senior engineers internalize this: they focus interventions on flows, not stocks, and they set expectations accordingly about how long change will take.