Law 3 — Dependencies Tax Flow

Every dependency adds delay, coordination cost, and fragility.

Law 1 ("If it is not used, it does not exist") established that unused delivery has no reality.

Law 2 ("All additions increase entropy") showed that complexity naturally accumulates unless systems actively remove it.

Law 3 explores one of the primary mechanisms through which entropy damages execution: dependencies.

Modern organisations rarely collapse because engineers suddenly lose competence. Most systems slow down because they accumulate invisible taxes over time, and dependencies account for a large share of that burden.

A dependency almost always sounds reasonable in isolation. Security wants validation before release, platform teams want ownership over pipelines, QA wants formal approval, product wants alignment, and infrastructure teams want controlled provisioning.

None of these decisions sound irrational when viewed independently. In fact, most originate from legitimate local optimisation. Security wants safety, QA wants stability, platform teams want consistency, and leadership wants visibility.

The problem emerges when the organisation accumulates those optimisations without maintaining a systemic view of flow. Entropy no longer comes only from technical complexity but from the growing coordination pressure generated by the system itself.

Over time, work stops flowing smoothly and the organisation starts operating like a convoy permanently constrained by its slowest vehicle.

The Hidden Nature of Dependency Costs

Dependencies rarely appear explicitly on roadmaps or quarterly plans. They usually hide inside:

• waiting time
• coordination meetings
• approval chains
• context switching
• shared ownership
• fragmented responsibilities
• handoffs
• blocked environments
• specialist bottlenecks

Most companies measure activity, delivery volume, or utilisation. Very few track waiting time, coordination latency, blocked flow, or bottleneck propagation across the system.

That blind spot matters because constraints govern throughput. Goldratt understood this decades ago. Systems improve when organisations identify bottlenecks, protect flow around them, and continuously reduce their limiting factors.

Many modern organisations instead optimise locally while ignoring systemic constraints altogether.

That mistake changes everything.

A developer may complete implementation in two days while the feature itself only reaches production several weeks later. In most cases, the delay does not come from coding effort but from the dependency graph surrounding delivery.

In some organisations, the customer signal never even reaches engineering cleanly. It circulates between go-to-market, product, management, and prioritisation layers until the original problem becomes diluted, reinterpreted, or politically reframed.

By the time engineering receives the request, teams no longer solve the customer's problem directly. They solve an organisational interpretation of it.

Dependencies Compound Non-Linearly

Dependency growth does not scales linearly.

Small teams with few dependencies often move at remarkable speed because communication paths remain short and decision loops stay tight. As organisations expand, interaction surfaces multiply and coordination overhead grows faster than execution capacity.

A useful mental model comes from networking theory. In fully connected systems, communication paths grow exponentially with participants. Organisations behave similarly. Five teams do not create five interactions. They create dozens of potential coordination paths.

Every additional dependency introduces:

• new scheduling constraints
• additional feedback delay
• ownership ambiguity
• prioritisation conflicts
• operational fragility

Most organisations analyse themselves statically through org charts, reporting lines, ownership maps, or architecture diagrams. Yet operational complexity does not emerges from static topology alone.

Complexity emerges dynamically through interaction density, dependency frequency, synchronisation pressure, and feedback propagation. Two organisations with similar structures may exhibit radically different operational behaviour depending on how decisions, work, and coordination actually circulate through the system.

In practice, the dependency field matters more than the static map.

At some point, the system spends more energy coordinating work than executing it.

That is when organisations start mistaking process intensity for operational maturity.

The Toyota Lesson

Toyota understood something many modern technology organisations gradually forgot: flow matters more than local optimisation.

A machine operating at maximum utilisation while starving downstream stations does not improve throughput. It damages the overall system. The same principle applies directly to engineering organisations.

This also explains why supply-chain companies such as FuturMaster still thrive decades later. They apply supply-chain principles to themselves. They understand that queues, bottlenecks, propagation delays, local optimisation, and distorted signals eventually damage the entire system.

Many technology organisations, despite operating complex delivery systems themselves, still manage engineering as disconnected local functions instead of treating delivery as an end-to-end flow problem.

A central platform team serving fifteen product teams often becomes a hidden tax collector. Every request enters a queue, every queue introduces waiting, and every delay increases uncertainty across the system. That uncertainty then generates meetings, escalations, reprioritisation, and emotional friction.

Leadership often reacts by introducing additional governance, approvals, and coordination layers, which in turn create even more dependencies. The loop reinforces itself until coordination overhead starts consuming a meaningful share of delivery capacity.

Educated Examples

Example 1 — The Shared QA Bottleneck

A company centralises QA under one team in order to “improve quality”. Initially, the model appears efficient because standards become more consistent and processes gain visibility.

After six months:

• developers stop testing deeply because “QA will catch it”
• QA becomes overloaded
• releases queue for validation
• priorities conflict across teams
• rework loops increase
• bugs return late in the cycle

Leadership often concludes that the solution requires more QA capacity. In reality, the dependency model itself created the slowdown. Quality moved downstream instead of becoming systemic and embedded into daily engineering practice.

Example 2 — The Platform Ticket Trap

A platform team builds tooling intended to accelerate delivery. Over time, however, product teams cannot:

• create environments
• deploy services
• configure observability
• manage permissions
• create pipelines

without opening tickets.

The platform team gradually becomes overloaded, product teams complain about slowness, and platform engineers spend increasing amounts of time managing prioritisation rather than improving enablement.

The company eventually creates an internal bureaucracy around access to platform capabilities. The original goal focused on leverage, but the result becomes dependency concentration.

Strong platforms reduce dependencies through self-service capabilities and clear interfaces. Weak platforms centralise operational control and unintentionally become bottlenecks.

Example 3 — The Executive Approval Spiral

A company experiences several failed launches and leadership reacts by introducing additional approval layers.

Releases now require:

• architecture review
• product sign-off
• security validation
• operations approval
• management visibility

Risk initially appears lower because additional controls create a stronger sense of supervision. Delivery speed then collapses as teams start batching changes together in order to justify expensive release processes.

Larger batches increase operational risk, failures become harder to isolate, and leadership responds with even more controls. The organisation slowly enters a self-reinforcing fragility loop.

This dynamic explains why elite engineering organisations tend to deploy continuously. Smaller batches reduce dependency coordination costs and shorten feedback latency at the same time.

The Physical Symptoms of Dependency Saturation

Dependency-heavy organisations often exhibit the same operational symptoms regardless of industry. Leaders usually interpret these signals independently instead of recognising them as manifestations of the same systemic problem.

Common symptoms include:

• growing review queues
• recurring “quick sync” meetings
• roadmap inflation
• permanent reprioritisation
• increasing stakeholder counts per initiative
• platform intake forms and approval workflows
• release trains compensating for coordination instability
• rising lead times despite additional hiring
• more reporting activity than delivery visibility
• overloaded experts acting as human routing layers

At that stage, highly skilled people spend growing amounts of time compensating for structural inefficiencies instead of producing customer value.

Engineers become coordinators, managers become routers, meetings behave like synchronisation protocols, and planning slowly turns into dependency management.

The organisation pays increasingly expensive people to absorb friction generated by its own operating model.

Dependencies Also Damage Morale

Most morale problems presented as “culture issues” are actually flow issues. Engineers rarely enjoy spending weeks waiting for:

• approvals
• environments
• reviews
• coordination
• missing decisions
• overloaded experts

People gradually lose ownership when they cannot move work forward autonomously, and energy declines once effort no longer correlates with visible progress.

That is why highly dependent organisations often compensate with:

• motivational language
• alignment workshops
• transformation programmes
• process theatre
• excessive ceremonies

The system itself generates frustration.

Culture merely reflects it.

In mature dependency-heavy organisations, teams gradually stop optimising for customer outcomes and start optimising for internal survivability.

Work gets shaped around approvals, reporting structures, rituals, dependency expectations, and political navigation rather than around the original customer signal.

At that stage, the organisation no longer behaves primarily as a delivery system. It behaves as a dependency preservation system.

Dependency Reduction Is a Strategic Discipline

Strong organisations systematically reduce unnecessary dependencies, not recklessly but deliberately and continuously.

That often means:

• pushing ownership closer to teams
• automating approvals
• reducing handoffs
• embedding quality upstream
• enabling self-service platforms
• simplifying architecture
• shortening feedback loops
• clarifying decision boundaries

The objective does not involve organisational isolation. Healthy systems still require collaboration, shared context, and collective ownership. The difference is that mature organisations avoid turning collaboration into mandatory synchronisation at every stage of delivery.

That distinction matters because synchronisation cost scales rapidly with organisational complexity.

The Warning Sign Most Leaders Miss

A dangerous moment appears when organisations celebrate utilisation instead of throughput. Everybody looks busy, calendars remain full, roadmaps continue expanding, and tickets keep moving across boards while customers still wait for outcomes.

That pattern usually signals dependency saturation. The system has started consuming its own capacity through coordination overhead.

At that stage, adding more people often worsens performance because every additional actor introduces new communication paths, synchronisation requirements, and planning overhead.

The organisation starts scaling complexity faster than execution.

At that stage, the system starts chasing its own tail. Teams create coordination layers to manage the noise generated by previous coordination layers, then hire additional people simply to absorb the operational friction they created themselves.

Revenue per dollar invested gradually declines because an increasing share of organisational energy no longer produces customer value. It merely sustains internal synchronisation.

The system slowly cannibalises itself.

Information Entropy

Dependencies do not merely slow execution. They also distort information itself.

Customer intent, urgency, ownership, priorities, and accountability gradually degrade as signals propagate across organisational layers.

Every handoff introduces interpretation. Every coordination layer introduces filtering. Every approval layer reshapes incentives.

Over time, organisations stop responding directly to reality and instead react to internally reconstructed versions of reality.

That distortion explains why some companies continue optimising metrics, rituals, and reporting structures long after customers already experience visible pain.

The system no longer senses reality clearly.

Closing Reflection

Dependencies are never free. Every dependency introduces some form of tax into the system. Certain taxes remain justified because they reduce meaningful risk or improve resilience, while many others simply accumulate through habit, organisational inertia, fear, or local optimisation disconnected from systemic consequences.

Most organisations believe scaling problems come from insufficient process, insufficient alignment, or insufficient coordination.

In reality, many systems collapse because they accumulate more coordination than throughput.

The organisation quietly slows down, not because people stopped caring, but because the system created too many places where work, decisions, and information must stop and wait.

That is the real meaning of Law 3.

Dependencies tax flow.

Eventually, the organisation no longer scales delivery. It scales the cost of talking to itself.