Industrialist Paper No. 4
The Latency Tax
By Andrew Kornuta • 7 min read
A buyer can do everything right and still lose weeks.
The drawing is approved. The budget exists. The part is needed to keep an assembly moving. The buyer sends an RFQ and waits, and while they wait nothing else can lock — material release, tooling allocation, fixture planning, inspection planning, test planning, schedule reservation. That's as true in textiles as it is in machining. The mechanism doesn't care what you make.
When you're building, time is not neutral. Time multiplies cost. I call that multiplier the latency tax: the price you pay when a work package cannot move through the network quickly enough to convert intent into a committed plan.
Latency is where schedules die
Every manufacturing program has a decision chain. Quote. Award. Material. Schedule. Work instructions. Inspection plan. Ship. If the quote slips, the whole chain slips. If clarification slips, the quote slips. If supplier qualification resets, clarification slips.
Anyone who has lived through a line stoppage understands this instantly, and the numbers get ugly fast. One Senseye study of large multinational industrial companies reported average downtime costs on the order of hundreds of thousands of dollars per hour, with automotive plants cited far higher in some cases. Another source summarizing Aberdeen Group research puts unplanned equipment failure at roughly $260,000 per hour on average, with large industrial operations facing materially higher figures.
You don't need those exact numbers to be true in your factory for the argument to hold. You need one fact: once a build is waiting on a part, time stops being a soft cost. Latency becomes a financial instrument, converting calendar days into expediting, overtime, rescheduling, partial builds, and risk.
The buyer's experience: "nobody can move fast"
Every time I've heard a buyer describe this as a lack of capacity, what they actually lived through was silence, then late quotes, then award pressure.
Here's an anecdote that shows up online constantly. A buyer asks why quotes take so long. The replies land on the same themes every time: too many RFQs, too much ambiguity, too much unpaid engineering, too many tire kickers, too much context trapped in people. That thread isn't an academic study, but we've all heard it, and it mirrors what procurement teams see at scale — when the inbox is noisy, response discipline collapses.
From the buyer's side the result is predictable. A quote that arrives late feels like no quote at all. A supplier who responds late gets filed as unreliable even if they're the most skilled shop in the region. And a supplier who asks questions gets treated as slow, even when those questions are the whole difference between a clean build and a quality escape.
So buyers do what rational buyers do. They shrink the vendor list. They route to incumbents. They route to whoever answers first. They lean on channels that feel fast. Paper 3 covers the offshoring escape valve in depth and I won't re-litigate it here. The point for this paper is narrower: when time becomes the dominant objective function, the network selects for speed signals rather than real capability, and that bill comes due later.
The shop's experience: latency is unpaid labor
On the supplier side, the buyer isn't waiting on a quote. The shop is absorbing translation work, and every RFQ carries hidden decisions that have to be made before a price can be real.
What controls, the model or the drawing, and which revision is correct? What does the datum scheme imply for fixturing and inspection? What do the finish callouts imply for process steps and verification? What do the tolerances imply for scrap risk, yield, and inspection cycle time? What certification chain and documentation burden are expected? And which assumptions here are safe versus career-ending?
That work isn't free — it's estimator time, programmer time, process planning time, and quality planning time. Even in a mature niche like moldmaking, an industry association report cites quoting turnaround on the order of days for many shops, alongside broader capacity and workforce constraints. The exact number varies by process and complexity, but the underlying reality is stable: quoting is part of production, and it consumes scarce engineering attention.
So the shop behaves rationally too. It triages aggressively. It deprioritizes ambiguous packages, prioritizes known buyers with predictable award behavior, and responds fast only when the work package is legible enough to price risk without gambling.
That's the core diagnosis. Quote latency is not a single-company problem. It's an emergent network problem created by ambiguity, qualification friction, and inconsistent incentive signals.
Time-to-clarity beats time-to-quote
Most sourcing conversations obsess over time-to-quote. I'm convinced the real bottleneck is time-to-clarity.
Clarity means the work package carries enough explicit structure that two competent teams will converge on the same manufacturing contract. The controlling artifacts are defined. Critical features are identified. Inspection expectations are explicit and acceptable assumptions are stated. Revision control is stable, special processes are named, and it's clear who owns resolving whatever ambiguity is left.
When time-to-clarity is short, time-to-quote gets short as a consequence. When time-to-clarity is long, time-to-quote is a mirage — a fast quote on an unclear work package is usually a deferred problem that resurfaces as change orders, rework, NCR churn, and schedule damage.
This is why "instant" is neither inherently good nor inherently bad. Instant quoting is a tool. It's powerful when the work package is bounded and honest and the supplier identity and constraints are real. It's destructive when it becomes a mechanism for exporting ambiguity into a part number and hoping the consequences land on somebody else. \<\<for more on "instant quoting" see bonus Paper No 4.5 below\>\>
Latency compounds because it stacks
Latency rarely arrives as one big delay. It arrives as a stack of small ones that cascade: the buyer waits for a first response, the supplier asks for clarification, the buyer routes questions to engineering, engineering responds late because the question isn't urgent inside their queue, the supplier updates the quote, procurement starts internal approvals, the supplier's schedule window closes, the buyer expedites or reroutes, and the program slips anyway. That cascade is why manufacturing feels slow even when the machines are fast. The speed of a spindle, a loom, or a pick-and-place line was never the constraint. The constraint is how fast the network can turn an unclear request into a committed traveler, router, or work instruction set.
Latency is also a governance signal
Incentives and measurement drive allocation. Visibility governs where the work goes. If the dashboard rewards award date and promised lead time, the system will select for promises rather than for stable execution, because promises are the easiest thing to produce on schedule and the hardest thing to audit in the moment. Buyers unintentionally train the supply base when they reward speed without enforcing clarity and consequence. Questions that would have prevented scrap and NCRs get treated as friction. Ambiguity gets broadcast as if it were demand. Then the actual award happens privately, to the incumbent who already knows the tribal context. Suppliers learn that lesson fast: the channel is noisy, questions are punished, and the only ways to survive are ignoring most requests or padding risk into price.
Shops train buyers just as unintentionally. With no immediate "received and triaging" signal, buyers assume the supplier is unresponsive and route elsewhere. When questions sit with no updates, buyers write the supplier off as unreliable even while real engineering work is happening. And when uncertainty is hidden inside price padding instead of stated as assumptions, the buyer can't compare quotes honestly, so the argument resurfaces after award as change orders, lead time re-openings, and schedule fights.
The network outcome is predictable: everyone optimizes for what is visible, not for what is true. Networks that outperform don't win by hoping for better behavior. They win by making response discipline, revision control, and assumption handling explicit, measurable, and consequential, so that speed comes from clarity instead of from bluffing.
What a serious buyer measures
If you want a sourcing network that's fast and reliable, measure the things that create real speed. Time-to-first-response is the acknowledgement that the packet arrived and is being triaged. Time-to-clarity is the interval from RFQ receipt to "we can build this without guessing." Question quality tells you whether supplier questions are pointed and bounded or chaotic and late. Quote confidence means explicit assumptions, explicit risks, and an explicit inspection plan. Award discipline captures how often RFQs become real POs, and how quickly. Change order rate is the percentage of awards that mutate because intent was unstable. And on-time delivery and yield outcomes are the scoreboard that matters after award.
Most of those aren't nice-to-haves. They're throughput controls, and incentives shift the moment they become visible.
Implications
The dominant cost in modern manufacturing is often decision latency, and it doesn't require a supply chain to appear — it exists inside fully vertical organizations just as readily as across a distributed network of players. Buyers experience that latency as "no capacity"; suppliers experience it as unpaid translation work. Time-to-clarity is the real lever, because fast quotes that defer clarity usually convert into schedule damage later. Latency compounds through cascades of small delays across engineering, procurement, suppliers, and quality. And the governance layer here is measurement: measure the wrong things and the network will optimize the wrong things, exactly as designed.
Next: Paper 5, Ambiguity Lives in People — where I'll argue that the "irreplaceable" veteran is often a walking ambiguity reducer, and show how buyers and suppliers can convert tribal context into routable work packages without turning every job into a folklore project.