In instrumented software-development settings, calendar lead time is dominated by coordination and waiting rather than by touch time: distributed work items took about 2.5x as long as colocated ones — with the paper's own modeling attributing the delay primarily to the larger number of people distributed changes involve (the distributed indicator itself is not significant once people-count and other factors are controlled), alongside survey-reported cross-site delays averaging ~2.4 days versus ~0.9 same-site — and WIP correlates directly with lead time in multi-year kanban field data.

• supportsprimary-checkedAbstract

  “One key finding is that distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is colocated.”

  calendar time, distributed vs colocated work items: ~2.5x longer (n = modification requests from two Lucent departments)

  Herbsleb, J., Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Transactions on Software Engineering, 29(6). link

• supportsprimary-checkedAbstract; elaborated in §3.3 Replication ("It appears that splitting work across sites slows the work down primarily because it requires the involvement of more people than comparable work accomplished all at one site.")

  “The data strongly suggest a mechanism for the delay, i.e., that distributed work items involve more people than comparable same-site work items, and the number of people involved is strongly related to the calendar time to complete a work item.”

  Herbsleb, J., Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Transactions on Software Engineering, 29(6). link

• contextualizesprimary-checked§3.2 Modeling MR Interval (Table 2 regression discussion); replicated for Department B

  “Surprisingly, given all other factors, distributed MRs do not have significantly longer intervals than single-site MRs.”

  Herbsleb, J., Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Transactions on Software Engineering, 29(6). link

• supportsprimary-checked§3.1 (delay survey)

  “Averaged over all 92 respondents, the mean number of local delays was 2.1 delays per month and the mean duration was .9 days. For cross-site delays, the mean number was 1.9 delays per month and the mean duration was 2.4 days.”

  mean reported work-issue delay duration, cross-site vs local: ~2.4 days vs ~0.9 days (duration difference significant, p < 0.02; count difference n.s.) (n = 92 survey respondents)

  Herbsleb, J., Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Transactions on Software Engineering, 29(6). link

• supportsprimary-checkedAbstract (via SINTEF publication record)

  “WIP correlates with lead time; that is, lower WIP indicates shorter lead times, which is consistent with claims in the literature.”

  WIP ↔ lead time correlation: direct correlation (n = 8,000+ work items, 5 teams, 4 years, one company)

  Sjøberg, D. (2018). An empirical study of WIP in kanban teams. ESEM '18 (12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement), Oulu, Finland. doi:10.1145/3239235.3239238

• contextualizesreport-derivedSeed report, §Core idea

  “Reinertsen's Principles of Product Development Flow built an entire operating doctrine on this point, observing that product-development queues are invisible inventory and that, per his practitioner surveys, only about 2% of product developers measure queues and only 15% know their cost of delay.”

  Reinertsen, D. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. not peer-reviewed

Counter-evidence not yet searched.

Queue waiting time grows nonlinearly with utilization — proportional to variability times ρ/(1−ρ), diverging as utilization approaches 100% — so systems that keep every resource fully loaded are mathematically committed to long lead times; for knowledge-work organizations specifically the support is theorem-plus-operations-data, not direct org-level experiments.

• supportsreport-derivedSeed report, Key sources table

  “Wait ≈ variability × ρ/(1−ρ) × service time; delay diverges near full utilization”

  Kingman, J. (1961). The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, 57(4), 902-904. doi:10.1017/S0305004100036094

• supportsreport-derivedSeed report, Key sources table

  “L = λW holds in any stable system, independent of distributions”

  Little, J. (1961). A Proof for the Queuing Formula: L = λW. Operations Research, 9(3), 383-387. doi:10.1287/opre.9.3.383

• contextualizesreport-derivedSeed report, §Core idea

  “Little himself, fifty years later, described its scope as far wider than the toy queues it was proven on”

  Little, J. (2011). Little's Law as Viewed on Its 50th Anniversary. Operations Research, 59(3), 536-549. link

• contextualizesreport-derivedSeed report, §Core idea

  “variability must be buffered by some combination of inventory, capacity, and time (Hopp and Spearman's buffering law)”

  Hopp, W., Spearman, M. (2008). Factory Physics (3rd ed.). Waveland Press (reissue of the McGraw-Hill 3rd edition). not peer-reviewed

• supportsprimary-checkedAbstract (MIT working-paper version)

  “Our analysis also shows that the location of the tipping point, and therefore the susceptibility of the system to the firefighting phenomenon, is determined by resource utilization in steady state.”

  Repenning, N., Gonçalves, P., Black, L. (2001). Past the Tipping Point: The Persistence of Firefighting in Product Development. California Management Review, 43(4). link

• contextualizesprimary-checked§1 Introduction, p. 1486

  “operating at high levels of utilization has many operational implications, including long waiting times”

  Kc, D., Terwiesch, C. (2009). Impact of Workload on Service Time and Patient Safety: An Econometric Analysis of Hospital Operations. Management Science, 55(9), 1486-1498. doi:10.1287/mnsc.1090.1037

• contextualizesprimary-checkedp. 67, Introduction. Pins the multi-server (GI/G/s) scope note: the s-server queue-length formula softens the utilization exponent, and via Little's law (Wq = Lq/λ, λ = sρ/τ — our algebra, direction conservative) the mean wait divides by the server count, so the essay's 1x/4x/9x/19x magnitudes price the single-server worst case only.

  “Here we derive the simple formula Lq≃ρ^√(2(s+1))/(1−ρ) from the careful observation of the ρ-Lq curves for various s values. Finally, we conjecture the approximation formula Lq≃((Ca²+Cs²)/2)(ρ^√(2(s+1))/(1−ρ)) from the analogy in the case of single server queueing systems.”

  Sakasegawa, H. (1977). An approximation formula Lq ≃ α·ρ^β/(1−ρ). Annals of the Institute of Statistical Mathematics, 29(1), Part A, 67-75. link

Counter-evidence searched: The main qualification found: Kc & Terwiesch (primary-checked) show service rates are state-dependent — workers accelerate under load in the short run — which softens the fixed-service-rate assumption behind Kingman's approximation without eliminating the divergence; Kingman is itself an approximation most accurate near saturation. Direct org-level tests remain model-based (Repenning), so the claim is held at moderate rather than the report's 'strong for queueing systems generally'.

Beyond a moderate optimum, higher individual work-in-progress and task switching lengthen completion times and degrade output: field data show diminishing-to-negative returns to multitasking, lab experiments show switching costs that grow with task complexity, and attention residue from unfinished tasks impairs performance on the next task.

• supportsprimary-checkedAbstract (via RePEc/IDEAS record)

  “We find that (1) more multitasking is associated with more project output, but diminishing marginal returns”

  multitasking → project output: positive with diminishing marginal returns; inverted-U with durations stretching past the optimum per full text (per seed report) (n = 1,300+ projects over 5 years, one executive-recruiting firm)

  Aral, S., Brynjolfsson, E., Van Alstyne, M. (2012). Information, Technology, and Information Worker Productivity. Information Systems Research, 23(3, part 2), 849-867. doi:10.1287/isre.1110.0408

• supportsprimary-checkedAbstract (JEP:HPP 27(4), p. 763)

  “Task alternation yielded switching-time costs that increased with rule complexity but decreased with task cuing.”

  Rubinstein, J., Meyer, D., Evans, J. (2001). Executive Control of Cognitive Processes in Task Switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763-797. doi:10.1037/0096-1523.27.4.763

• supportsprimary-checkedAbstract (via RePEc/IDEAS record)

  “it is difficult for people to transition their attention away from an unfinished task and their subsequent task performance suffers”

  Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Organizational Behavior and Human Decision Processes, 109(2), 168-181. doi:10.1016/j.obhdp.2009.04.002

• contradictsprimary-checkedAbstract (via SINTEF publication record)

  “WIP also correlates with productivity, which is inconsistent with the claim in the literature that a low WIP (still above a certain threshold) will improve productivity.”

  Sjøberg, D. (2018). An empirical study of WIP in kanban teams. ESEM '18 (12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement), Oulu, Finland. doi:10.1145/3239235.3239238

Counter-evidence searched: Downgraded from the report's 'strong': Sjøberg's field data (primary-checked) contest naive WIP-limit orthodoxy — higher WIP also correlated with higher productivity at that company, and the author calls for replication. A 2026-07-07 search also surfaced lab evidence that the mere perception of multitasking can improve engagement/performance. Claim text is scoped to 'beyond a moderate optimum' to reflect the inverted-U rather than a monotonic penalty.

Handoffs and approval steps are first-order sources of organizational latency, but they are not uniformly slow by nature: cross-site handoffs multiplied lead time ~2.5x at Lucent and heavyweight change-approval boards predict worse speed and stability, while Google's measured sub-4-hour review medians and clearly understood change processes show approval steps can be engineered to near-zero queue time.

• supportsprimary-checked§1.1, p. 2

  “The most frequent consequence of cross-site problems was delay in the resolution of work issues.”

  Herbsleb, J., Mockus, A. (2003). An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE Transactions on Software Engineering, 29(6). link

• supportsprimary-checkedExecutive summary, Key finding 6, p. 6

  “Heavyweight change approval processes, such as change approval boards, negatively impact speed and stability. In contrast, having a clearly understood process for changes drives speed and stability, as well as reductions in burnout.”

  Forsgren, N., Smith, D., Humble, J., Frazelle, J. (2019). Accelerate: State of DevOps 2019. DORA / Google Cloud. linknot peer-reviewed

• contextualizesprimary-checked§5.2 Quantifying the Review Process

  “In terms of speed, we find that developers have to wait for initial feedback on their change a median time of under an hour for small changes and about 5 hours for very large changes. The overall (all code sizes) median latency for the entire review process is under 4 hours.”

  median code-review latency at Google: <1h initial feedback (small changes); <4h overall (n = ~9M reviews logged over two years)

  Sadowski, C., Söderberg, E., Church, L., Sipko, M., Bacchelli, A. (2018). Modern Code Review: A Case Study at Google. ICSE-SEIP '18 (40th International Conference on Software Engineering: Software Engineering in Practice). doi:10.1145/3183519.3183525

• contradictsreport-derivedSeed report, §Evidence landscape

  “Kownatzki and colleagues found that three types of corporate control actually enhance business-unit decision speed — governance and speed are not simple opposites.”

  Kownatzki, M., Walter, J., Floyd, S., Lechner, C. (2013). Corporate Control and the Speed of Strategic Business Unit Decision Making. Academy of Management Journal, 56(5). doi:10.5465/amj.2011.0804

• supportsprimary-checkedHamel's companion summary of the same 7,000-response BMI survey, "10 Hard Facts About Bureaucracy", Fact #5 (globalleadership.org reprint; the hbr.org original is paywalled)

  “Two-thirds of respondents believe that bureaucracy is a significant drag on the pace of decision-making in their organization—a number that rises to nearly 80% in large companies.”

  share of respondents calling bureaucracy a significant drag on decision pace: two-thirds overall; nearly 80% in large companies only (n = 7,000+ self-selected HBR-reader responses (BMI poll))

  Hamel, G., Zanini, M. (2017). What We Learned About Bureaucracy from 7,000 HBR Readers. Harvard Business Review (hbr.org). linknot peer-reviewed

Counter-evidence searched: Counter-evidence is encoded directly: Kownatzki et al. found some corporate controls speed decisions, and the seed report notes there are few dose-response studies of 'N approvers → X days'. The claim text therefore asserts approvals as latency sources while conceding they can be engineered fast.

In large repeated DevOps surveys, short lead time clusters with high deployment frequency, fast recovery, and low change-failure rate — elite performers report 106x faster lead time and 7x lower change-failure rate than low performers — and this speed-plus-stability profile predicts organizational performance, though the evidence is self-reported, cross-sectional, and contested on outcome relevance.

• supportsprimary-checkedp. 21, Elite performers

  “Comparing the elite group against the low performers, we find that elite performers have… 208 times more frequent code deployments, 106 times faster lead time from commit to deploy, 2,604 times faster time to recover from incidents, 7 times lower change failure rate”

  elite vs low performers (four key metrics): 208x deploys; 106x lead time; 2,604x recovery; 7x lower change failure (n = 31,000+ survey responses over six years)

  Forsgren, N., Smith, D., Humble, J., Frazelle, J. (2019). Accelerate: State of DevOps 2019. DORA / Google Cloud. linknot peer-reviewed

• supportsprimary-checkedp. 17, How Do We Compare?

  “For six years in a row, however, our research has consistently shown that speed and stability are outcomes that enable each other.”

  Forsgren, N., Smith, D., Humble, J., Frazelle, J. (2019). Accelerate: State of DevOps 2019. DORA / Google Cloud. linknot peer-reviewed

• supportsreport-derivedSeed report, §Evidence landscape

  “consistently finds that elite performers achieve both speed and stability (106x faster lead time with 7x lower change-failure rate in 2019), which is exactly what queueing predicts and what a "speed comes from heroics" theory cannot explain: you cannot hero your way to a 106x difference”

  Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. not peer-reviewed

Counter-evidence searched: Counter-evidence per the seed report (not independently re-searched): Junade Ali's Survation polling finds engineers and the public rank delivery speed below security and accuracy; DORA itself warns against team-level comparisons; and Accelerate's causal claims rest on cross-sectional psychometric modeling. The claim text carries these caveats explicitly.

In packet networks, oversized and perpetually full buffers add latency without adding throughput and defeat the feedback signals congestion control depends on; managing queues by packet sojourn time against a target, and sizing backbone buffers down by roughly 99%, restores low delay with negligible throughput loss.

• supportsprimary-checkedAbstract

  “The consequences on router design are enormous: A 2.5Gb/s link carrying 10,000 flows could reduce its buffers by 99% with negligible difference in throughput”

  backbone buffer reduction at fixed throughput: -99% buffer (B = RTT·C/√n rule) (n = theory + simulation + experiments on real routers)

  Appenzeller, G., Keslassy, I., McKeown, N. (2004). Sizing Router Buffers. SIGCOMM '04, Portland, Oregon. doi:10.1145/1015467.1015499

• supportsprimary-checked§3 (Building Blocks of Queue Management)

  “It is not the queue length that should be controlled but the amount of excess delay packets experience due to a persistent or standing queue, which means that the packet sojourn time in the buffer is exactly what we want to track.”

  Nichols, K., Jacobson, V., McGregor, A., Iyengar, J. (2018). Controlled Delay Active Queue Management (RFC 8289). IETF, RFC 8289 (Experimental). linknot peer-reviewed

• supportsprimary-checked§2 (standing-queue example)

  “In the above example, the 5-packet standing queue can be seen to contribute nothing but delay to the connection and thus is clearly "bad" queue.”

  Nichols, K., Jacobson, V., McGregor, A., Iyengar, J. (2018). Controlled Delay Active Queue Management (RFC 8289). IETF, RFC 8289 (Experimental). linknot peer-reviewed

• supportsreport-derivedSeed report, Key sources table

  “Oversized, always-full buffers add seconds of latency, defeat congestion feedback, and get misdiagnosed as bandwidth shortage”

  Gettys, J., Nichols, K. (2012). Bufferbloat: Dark Buffers in the Internet. Communications of the ACM, 55(1), 57-65 (earlier version in ACM Queue 9(11), 2011). doi:10.1145/2063176.2063196not peer-reviewed

• supportsreport-derivedAs quoted in LWN article 496250 (2012-05-08)

  “rather than measuring queue size in bytes or packets, we used the packet-sojourn time through the queue”

  Nichols, K., Jacobson, V. (2012). Controlling Queue Delay. ACM Queue, 10(5); also Communications of the ACM, 55(7), 42-50. doi:10.1145/2209249.2209264not peer-reviewed

• contradictsreport-derivedSeed report, §Evidence landscape

  “Even networking agrees: the buffer-sizing redux literature emphasizes that under-buffered links lose throughput.”

  McKeown, N., Appenzeller, G., Keslassy, I. (2019). Sizing Router Buffers (Redux). ACM SIGCOMM Computer Communication Review, 49(5). linknot peer-reviewed

Counter-evidence searched: The boundary condition is encoded as evidence: the 2019 'Sizing Router Buffers (Redux)' retrospective documents cases where too-small buffers waste capacity, so the finding is 'right-size and manage by sojourn time', not 'buffers are bad'. Rated strong for the networking domain only: two distinct primary-checked supporting sources, replicated and deployed in production systems; the organizational mapping is a separate, suggestive claim.

The mapping of network bufferbloat onto organizational design — backlogs, approval inboxes, and roadmap parking lots as oversized buffers whose unbounded growth adds latency and destroys overload signals — is this essay's own theoretical construct: no peer-reviewed study applies bufferbloat to organizations, although each load-bearing component of the mapping has independent empirical support.

• contextualizesreport-derivedSeed report, §Where the latency actually lives

  “Gettys and Nichols emphasize that bufferbloat persisted for a decade partly because latency was misattributed to bandwidth — people bought fatter pipes when they needed smaller queues.”

  Gettys, J., Nichols, K. (2012). Bufferbloat: Dark Buffers in the Internet. Communications of the ACM, 55(1), 57-65 (earlier version in ACM Queue 9(11), 2011). doi:10.1145/2063176.2063196not peer-reviewed

• contextualizesreport-derivedSeed report, Key sources table (limitations column)

  “Validated in packet networks; "drop" has no painless org equivalent”

  Nichols, K., Jacobson, V. (2012). Controlling Queue Delay. ACM Queue, 10(5); also Communications of the ACM, 55(7), 42-50. doi:10.1145/2209249.2209264not peer-reviewed

• contextualizesreport-derivedSeed report, §Evidence landscape

  “This is the organizational analog of TCP filling an oversized buffer: pressure without drop signals just grows the standing queue.”

  Perlow, L., Okhuysen, G., Repenning, N. (2002). The Speed Trap: Exploring the Relationship Between Decision Making and Temporal Context. Academy of Management Journal, 45(5), 931-955. doi:10.5465/3069323

Counter-evidence searched: Searched 2026-07-07 for peer-reviewed or practitioner applications of bufferbloat to organizational design; found only networking literature and generic queue analogies (checkout lines, ponds), confirming the seed report's own admission that the mapping is analogical and untested. Substantive disanalogy noted by the report: packets are fungible and droppable, work items and people are not.

Past a utilization-determined tipping point, adding urgency or pulling resources forward without draining queues makes organizational latency worse — firefighting becomes self-reinforcing and urgency self-generating — with support from system-dynamics models, one 19-month ethnography, and hospital econometrics, but no randomized org-level test.

• supportsprimary-checkedAbstract (MIT working-paper version)

  “in product development systems there exists a threshold for problem-solving activity that, when crossed, causes firefighting to spread rapidly from a few isolated projects to the entire development system”

  Repenning, N., Gonçalves, P., Black, L. (2001). Past the Tipping Point: The Persistence of Firefighting in Product Development. California Management Review, 43(4). link

• supportsreport-derivedSeed report, Key sources table

  “The "speed trap": an internally generated need for fast decisions narrows attention and reproduces the urgency that caused it”

  Perlow, L., Okhuysen, G., Repenning, N. (2002). The Speed Trap: Exploring the Relationship Between Decision Making and Temporal Context. Academy of Management Journal, 45(5), 931-955. doi:10.5465/3069323

• supportsprimary-checkedAbstract, p. 1486

  “Long periods of increased load (overwork) have the effect of decreasing the service rate. In cardiothoracic surgery, an increase in overwork by 1% increases length of stay by six hours.”

  sustained overwork → length of stay: +1% overwork → +6h length of stay (n = cardiothoracic surgery patients, one hospital)

  Kc, D., Terwiesch, C. (2009). Impact of Workload on Service Time and Patient Safety: An Econometric Analysis of Hospital Operations. Management Science, 55(9), 1486-1498. doi:10.1287/mnsc.1090.1037

• contradictsprimary-checkedAbstract, p. 1486

  “We find that workers accelerate the service rate as load increases. In particular, a 10% increase in load reduces length of stay by two days for cardiothoracic surgery patients”

  short-run load → length of stay: +10% load → ~2 days shorter stay (n = cardiothoracic surgery patients, one hospital)

  Kc, D., Terwiesch, C. (2009). Impact of Workload on Service Time and Patient Safety: An Econometric Analysis of Hospital Operations. Management Science, 55(9), 1486-1498. doi:10.1287/mnsc.1090.1037

Counter-evidence searched: The short-run counter-effect is encoded from the same primary-checked source: people genuinely work faster under load before sustained overwork reverses the gain. Held at suggestive per the report's own 'theoretical / suggestive, with moderate support in specific settings' rating — the general org-level claim rests on models and single-setting studies.

Organizational slack shows an inverse U-shaped relationship with innovation — both too little and too much slack are harmful — so the optimal buffer level is interior rather than zero, consistent with the operations law that variability must be buffered by some mix of inventory, capacity, and time.

• supportsprimary-checkedAbstract (via Mendeley catalogue record)

  “there is an inverse U-shaped relationship between slack and innovation in organizations”

  slack ↔ innovation: inverse U-shaped (n = 264 functional departments, two multinational corporations)

  Nohria, N., Gulati, R. (1996). Is Slack Good or Bad for Innovation?. Academy of Management Journal, 39(5), 1245-1264. doi:10.5465/256998

• supportsreport-derivedSeed report, §Evidence landscape

  “including the buffering law — variability will be buffered by inventory, capacity, or time, whether you choose the buffer or not”

  Hopp, W., Spearman, M. (2008). Factory Physics (3rd ed.). Waveland Press (reissue of the McGraw-Hill 3rd edition). not peer-reviewed

• contextualizesreport-derivedSeed report, §Evidence landscape

  “Even networking agrees: the buffer-sizing redux literature emphasizes that under-buffered links lose throughput.”

  McKeown, N., Appenzeller, G., Keslassy, I. (2019). Sizing Router Buffers (Redux). ACM SIGCOMM Computer Communication Review, 49(5). linknot peer-reviewed

Counter-evidence not yet searched.

Approval hierarchies are not pure latency waste: consensus and hierarchical decision structures commit fewer errors of commission at the cost of more errors of omission, so flattening approval chains changes an organization's error profile rather than simply speeding it up.

• supportsprimary-checkedAbstract (via RePEc/IDEAS record)

  “increasing the consensus threshold required by a committee in charge of selecting projects leads to more omission errors, fewer commission errors, and fewer approved projects”

  consensus threshold → error mix: more omission, fewer commission errors, fewer approvals (n = 150,000+ stock-picking decisions, 609 mutual funds)

  Csaszar, F. (2012). Organizational structure as a determinant of performance: Evidence from mutual funds. Strategic Management Journal, 33(6), 611-632. doi:10.1002/smj.1969

• supportsprimary-checkedAbstract (NBER Working Paper 1334 page)

  “polyarchies accept a larger proportion of bad projects (compared to hierarchies) whereas hierarchies reject a larger proportion of good projects”

  Sah, R., Stiglitz, J. (1986). The Architecture of Economic Systems: Hierarchies and Polyarchies. American Economic Review, 76(4), 716-727 (NBER Working Paper 1334). link

• contextualizesreport-derivedSeed report, §Evidence landscape

  “Kownatzki and colleagues found that three types of corporate control actually enhance business-unit decision speed — governance and speed are not simple opposites.”

  Kownatzki, M., Walter, J., Floyd, S., Lechner, C. (2013). Corporate Control and the Speed of Strategic Business Unit Decision Making. Academy of Management Journal, 56(5). doi:10.5465/amj.2011.0804

Counter-evidence not yet searched.