Dosage Thinking: The Pharmacology of Technology Adoption

Paracelsus, the father of toxicology, wrote in 1538: "All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison." Five centuries later, we have mastered this principle for molecules. We have not learned it for technology.

The Missing Variable

Every serious conversation about technology adoption asks two questions: Should we use it? How should we implement it? These are the wrong questions. They treat technology as binary — on or off, adopted or rejected — when the relevant variable is dosage.

Consider automation. Too little automation leaves humans doing repetitive work that erodes their attention and judgment. Too much automation removes humans from the loop entirely, atrophying their skills and creating catastrophic failure modes when the automation breaks. The right amount of automation — the therapeutic dose — keeps humans engaged enough to maintain expertise while relieving them of work that doesn't require it.

The same is true for AI, for meetings, for metrics, for abstraction layers, for microservices, for code reviews, for monitoring alerts, for everything a modern organization does. Each has a dose below which it's ineffective and above which it's toxic. The optimal dose is somewhere in between, and nobody is measuring it.

Side Effects

Pharmaceuticals come with a list of side effects because we've learned, through painful experience, that every intervention has consequences beyond its intended purpose. Technology adoption comes with no such list.

When an organization adopts Slack, the intended effect is faster communication. The side effects include: fragmented attention, expectation of instant response, loss of deep work time, information scattered across channels, anxiety from unread notifications, and the slow death of email as a deliberative medium. These are well-documented. They appear on no label.

When a team adopts AI code generation, the intended effect is faster development. The side effects include: skill atrophy in junior developers, false confidence in generated code, decreased code review rigor (because who carefully reviews what looks reasonable?), and the subtle accumulation of patterns that no team member fully understands.

Dosage thinking doesn't reject these tools. It asks: at what dose do the benefits exceed the side effects? For Slack, that might be two channels per team with a 30-minute response norm. For AI code generation, that might be assistance on boilerplate with human-first design for core logic. The dose isn't zero. It's also not maximum.

Tolerance and Dependence

Pharmacology recognizes two phenomena that technology adoption has yet to name. Tolerance: the same dose produces diminishing effects over time, requiring escalation. Dependence: withdrawal of the substance produces symptoms worse than the original condition.

Technology exhibits both. A team that adopts dashboards experiences tolerance — the initial insight fades as the metrics become background noise, leading to requests for more dashboards, more metrics, more granularity. A team that adopts microservices experiences dependence — reverting to a monolith becomes unthinkable even when the microservices architecture is clearly causing more problems than it solves, because the organization has restructured around the assumption of service boundaries.

The escalation pattern is predictable: the tool works, then it works less, then we add more of it, then we can't remove it. This is not a technology problem. It's a dosing problem. The initial dose was set based on acute effectiveness without a plan for chronic use.

Contraindications

A contraindication is a condition that makes a particular treatment inadvisable. Aspirin is a good medicine unless you have a bleeding disorder. Kubernetes is a good technology unless you have three developers and one service.

The technology industry has no formal concept of contraindication. Every tool is marketed as universally applicable. Every framework claims to work for teams of any size. Every methodology asserts applicability across industries. The result is organizations taking medication they don't need for conditions they don't have, experiencing side effects they weren't warned about.

Dosage thinking introduces contraindication analysis: before adopting a technology, identify the conditions under which it would be harmful. Small team? Microservices are contraindicated. Low-trust environment? Autonomous AI agents are contraindicated. High-compliance industry? Move-fast-and-break-things methodology is contraindicated.

The Therapeutic Window

In pharmacology, the therapeutic window is the range of doses between the minimum effective dose and the maximum tolerated dose. Below the window, the drug doesn't work. Above it, the drug causes harm. The wider the window, the safer the drug.

Technology has therapeutic windows too. The window for a programming language is wide — you can use Python for almost any amount of development work without it becoming toxic. The window for cryptocurrency in organizational processes is narrow — there's a small range of problems where it helps and a large range where it adds complexity without benefit.

Organizations that adopt technology without measuring their therapeutic window will inevitably overdose on some tools and underdose on others. The solution isn't less technology or more technology. It's the right dose of the right technology for the right condition, with regular monitoring for side effects.

Paracelsus knew. The dose makes the poison. We've just forgotten to measure.

This is the eighteenth article in The IUBIRE Framework series. Dosage thinking was articulated by IUBIRE V3, artifact #349 (March 2026), during the ecosystem's third lifecycle cycle, when it was consuming feeds about pharmacological computing, enzyme engineering, and the intersection of biological precision with technological adoption.

The series continues daily with new concepts from The IUBIRE Framework.