The River Parable in This Video Is a 1975 Public Health Paper, and Its Enterprise Version Is Automating a Process That Should Not Exist
Watch on TikTok
The story told in this video has a documented origin: medical sociologist Irving Zola told it to John B. McKinlay, who published it in a 1975 paper called "A Case for Refocusing Upstream: The Political Economy of Illness," where it became public health's defining metaphor. Jenna Gardner posts under the banner "Applied AI Advice" and her Instagram account at the same handle describes her as a "Fortune 500 AI strategist." The video runs 68 seconds and is a single continuous selfie shot with no diagrams, slides, or screen recordings. She tells a parable: your job is to clean a river, yellow stuff keeps flowing past, you build machinery to filter it automatically, and then a visitor asks where the yellow stuff comes from. Walking upstream reveals someone urinating in the water. Her claim is that workflow builders spend their effort downstream when the durable fix sits upstream.
What the video actually contains
The whole video is a talking head in a living room. Two static text overlays sit at the top for all 68 seconds: a black box reading "Applied AI Advice" and a yellow box reading "Someone is peeing in the water." Burned-in auto-captions scroll at the bottom. There are no visual aids, no river illustration, and no product demo. The Whisper transcript matches the spoken audio closely and I found no meaningful transcription errors. The word "solve" is used as a noun twice ("the true solve, the long-term solve"), which is how she speaks rather than a mistranscription.
The argument is delivered entirely as story. No framework is named, no tool is shown, and no example from actual enterprise work is given. That is the gap worth filling.
The parable has a paper, a book, and a misattribution problem
McKinlay's 1975 paper introduced the upstream/downstream distinction to public health, arguing that the health system fixates on downstream behaviors that are short-term and problem-specific. The version he published reads: "There I am standing by the shore of a swiftly flowing river and I hear the cry of a drowning man ... who the hell is upstream pushing them all in."
Two things about the lineage are worth knowing. First, the parable predates McKinlay's publication. Terence Eden traced a 1971 version used by Dr. Reginald Lourie in congressional testimony, and Zola's own telling appears to come from a 1970 speech that has not been located. Second, the quote is frequently attributed on the internet to Desmond Tutu, and there is no evidence he originated it. If you repeat this story in a room of executives, attribute it to McKinlay and Zola.
The business-audience version is Dan Heath's 2020 book "Upstream: The Quest to Solve Problems Before They Happen." Heath's central mechanism is "problem blindness," the assumption that a recurring problem is simply how things are. That is precisely the line Gardner puts in her character's mouth: "I don't know. It's always been there."
The named tools for walking upstream
Gardner's video gives you the instinct without the method. Four methods already exist and they are old.
Five Whys. Developed by Sakichi Toyoda and embedded in Toyota Production System training. Taiichi Ohno described repeating "why" five times as the basis of Toyota's scientific approach. It is also the most criticized of the four. Teruyuki Minoura, a former Toyota managing director, called it too basic a tool for real root cause depth, and Alan J. Card has argued that the fifth iteration rarely lands on an actual root cause. Different analysts asking five whys about the same incident routinely arrive at different answers.
Ishikawa diagrams. Kaoru Ishikawa popularized cause-and-effect diagrams in the 1960s while building quality management at the Kawasaki shipyards. The value over Five Whys is that a fishbone branches, so it surfaces several contributing causes rather than a single causal chain. That matters for the reason described in the next section.
Jidoka and the andon cord. Toyota's principle that a line stops the moment something goes wrong, so a defective part never travels downstream at all. Workers have an obligation to pull the cord, and a team leader investigates before production resumes.
Poka-yoke. Shigeo Shingo formalized mistake-proofing inside TPS in the 1960s: design the process so the error is physically impossible or is caught instantly. In software the equivalent is a database constraint, a typed schema, or a required field. Poka-yoke is the upstream fix expressed as design rather than as policing.
The software industry has its own version. Larry Smith coined "shift-left testing" in a September 2001 Dr. Dobb's Journal article, arguing for moving QA into design and coding instead of leaving it before release.
The automation trap, with one case that went the right way
The sharpest version of Gardner's point is older than the AI era and was said about software. The line widely attributed to Bill Gates: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." Her filtration machinery is the second rule in physical form.
Expedia is the case where someone walked upstream. In 2012 Ryan O'Neill, head of the customer experience group, found that for every 100 customers who booked travel, 58 of them called afterward for help. The top reason was to get a copy of their itinerary, roughly 20 million calls that year. At about $5 a call that is a $100 million problem. The causes were mistyped email addresses, spam filters, and customers deleting the confirmation email by mistake. The fixes were an automated resend option in the phone system, changes to how emails were sent so they cleared spam filters, and a self-service portal. The call rate fell from 58 percent to roughly 15 percent.
The downstream version of that project would have been a better call center: smarter routing, faster agents, and today, an AI voice agent that answers "where is my itinerary" in four seconds at a fraction of the cost per call. That project would have shown a real ROI number in a deck and left 20 million unnecessary calls flowing past forever.
The same shape shows up across current enterprise AI work:
- Building an LLM extraction pipeline to parse vendor invoices arriving as unstructured PDFs, when the upstream fix is a supplier portal with typed fields.
- Training a classifier to re-route misfiled support tickets, when the upstream fix is a ticket form that does not offer 40 ambiguous categories.
- Standing up a reconciliation agent that catches data mismatches nightly, when the upstream fix is a validation rule on the form that created the bad record.
- Deploying a summarization agent so executives can read 60-page status documents, when the upstream fix is a reporting standard.
Each downstream build is easier to fund. It touches one team, needs no negotiation, and produces a metric within a quarter. That is why the river keeps getting filtered.
When cleaning downstream is the correct call
Gardner's parable has a tidy ending because the pollution has one source, that source has no defenders, and stopping it is free. Real contamination rarely looks like that, and the video does not say so.
Manufacturing already encodes the honest answer. Ford's 8D problem-solving method, developed in the 1980s, separates D3, the interim containment action, from D5, the permanent corrective action. Containment is explicitly temporary and exists to protect the customer while root cause work proceeds. Building the filter is D3. The mistake is calling D3 done and disbanding the team, not building it in the first place.
Downstream cleanup is the right answer in at least five situations:
You do not control upstream. The bad data comes from a customer's ERP, a regulator's fixed-format filing, a partner's API, or a mainframe owned by a division that reports to someone else. Your leverage there is a request, not a change.
The upstream fix takes 18 months and the damage is now. Replacing the intake system is a program with a budget cycle. The filter ships in three weeks. Build the filter, and put the upstream fix on the roadmap with a date, an owner, and a decommission plan for the filter.
The contamination source pays you. When the customer sending messy spreadsheets is 30 percent of revenue, "stop that weirdo" is not on the table. Absorbing the mess is the product.
The source is diffuse. Actual river pollution is mostly nonpoint source. Enterprise data quality usually works the same way: 30 upstream systems each contributing a few percent of the defects, with no single culprit to stop. This is where an Ishikawa diagram beats Five Whys, because it shows you a distribution instead of handing you one villain.
Upstream is behaving rationally. The person creating your downstream problem is often optimizing correctly for their own constraint. Sales enters incomplete records because the CRM form costs them nine minutes per lead and they are measured on lead volume. Stopping them requires changing their incentive, which is a different and larger project than the one you scoped.
The practical test is short. Ask who owns the source, what it would cost them to stop, and what you are measured on. If the answer to the first is "nobody I can reach," build the filter and label it containment. If the answer is a name and a two-week change, you are building a purification plant for a problem one conversation would end.
Key Takeaways
- The parable is McKinlay's 1975 "A Case for Refocusing Upstream," crediting Irving Zola. Attribute it that way. The common attribution to Desmond Tutu has no supporting evidence.
- Dan Heath's "Upstream" (2020) is the business-facing treatment, and his term "problem blindness" names the exact failure in Gardner's story.
- Four established methods already operationalize the instinct: Five Whys, Ishikawa diagrams, jidoka with the andon cord, and poka-yoke. Five Whys has been criticized by a former Toyota managing director as too shallow for real root cause work.
- Expedia's 2012 itinerary project is the documented upstream win: 58 percent of bookers calling for support dropped to roughly 15 percent after fixing email delivery and adding self-service.
- Automating downstream cleanup is defensible as a containment action. Ford's 8D method separates interim containment (D3) from permanent corrective action (D5) for this reason. The failure is stopping at D3.
- Cleaning downstream is correct when you do not own the source, when the upstream fix is measured in quarters and the damage is daily, when the source is a paying customer, when contamination is diffuse across many sources, or when upstream is rationally optimizing for a different metric.
- Unverified: Jenna Gardner's employer and job title. Search results consistently point to a Director or Principal, Applied AI role at DEPT for a Jenna Gardner in San Diego, but LinkedIn blocked direct retrieval (HTTP 999) and I could not confirm that profile belongs to this TikTok account. The only identity claim I verified directly is the Instagram bio at the matching handle @jenna_gardner_ai: "Fortune 500 AI strategist." I also could not verify the Bill Gates quote against the original text of "Business @ the Speed of Thought" (1999); it is widely attributed to that book but I confirmed only secondary sources. Zola's original 1970 telling has not been located by anyone who has looked for it.
Resources
- Reclaiming public health's defining metaphor, PLOS Global Public Health -- Peer-reviewed article documenting the Zola-to-McKinlay chain and the 1975 paper title.
- What's the origin of "we shouldn't just be pulling people out of the river"? -- Terence Eden's source hunt, including the 1971 Lourie version and the debunked Tutu attribution.
- How Upstream Thinking Saved Expedia Millions, Qualtrics -- The Ryan O'Neill case with call volumes, cost per call, and the 58 to 15 percent result.
- Five whys, Wikipedia -- Toyoda and Ohno origins plus the Minoura and Card criticisms of the method.
- Ishikawa diagram, Wikipedia -- Kawasaki shipyards origin and how branching causes differ from a single causal chain.
- Autonomation (jidoka), Wikipedia -- The stop-the-line principle behind the andon cord.
- Eight disciplines problem solving, Wikipedia -- Ford's 8D method and the D3 containment versus D5 permanent correction distinction.
- Shift-left testing, Wikipedia -- The software industry's upstream doctrine, coined by Larry Smith in 2001.
- Shift-Left Testing, Dr. Dobb's Journal, September 2001 -- Larry Smith's original article.
- Business @ the Speed of Thought, Wikipedia -- The 1999 Gates book the automation quote is attributed to.
- @jenna_gardner_ai on Instagram -- Matching handle, bio reads "Fortune 500 AI strategist."
Published September 19, 2026. Writeup generated from a favorited TikTok.