The theory of constraints is indifferent to which stage you wish were the slow one. Throughput is set by the slowest stage, full stop. When engineering capability outruns customer readiness, every additional unit of engineering speed evaporates at the customer's door.

Example: Picture a factory that doubles its press line while the loading dock stays the same size. The pallets stack up against the wall. The plant did not get faster. It got fuller.

Absorption is the rate at which customers can integrate a change, understand it, and pull value out of it. Deployment is none of those things. A feature behind a flag is not a feature in a customer's hands, and a feature in their hands is not a feature in their workflow.

Example: A new module ships to every account on the same Tuesday. Six weeks later, a third of those accounts have never opened the page. The release went out. The capability did not arrive.

A feature that ships and is not absorbed is not a zero on the ledger. It enlarges the surface, dilutes the documentation, confuses the support queue, and adds attack surface no one is paying attention to. The cost shows up as churn, support load, and incident hours — never as a line item anyone owns.

Example: A team adds three settings to a screen customers used to navigate without thinking. Tickets rise, satisfaction slips, and the next security review pulls in two surfaces nobody is using. The release made the product worse for the people already there.

Internal velocity and external rollout are two different clocks. Engineering ships continuously into a hardened trunk. Customers receive capability on their own readiness curve — segment by segment, account by account — not on a uniform calendar that pretends every customer is the same customer.

Example: One cohort receives a capability the week it is built. Another receives it after their next training cycle. A third opts in when they choose. The build pipeline never slowed. The arrival did, on purpose.