The Dependency Leak | Article 0: The Logic of the Leak

I see it constantly: I build a high-velocity team, I patch their focus, I protect their energy, and then I watch them park their “Race Car” at an Organizational Toll Booth.

It is as if I have a high-performance application that runs perfectly on its own, but it has to make a Synchronous Blocking Call to an external legacy database every five seconds. No matter how fast my local code is, the total “Response Time” of my team is now dictated by a system I don’t own.

The “Blocked” State
In software, a thread that is “Blocked” consumes memory but does zero work. In an organization, a team waiting on an external dependency is a Resource Leak.

  • The Deadlock: My team needs a security review to ship. The Security Team has a two-week queue. My team is now a Zombie Process—they are “alive,” but they can’t move forward. They “Thrashed” their local focus to get the code ready, only to hit a “Permission Denied” error at the finish line.
  • The Surprise Import: We are 90% done when we realize we need a schema change from the Data Team. This is a Late-Binding Failure. The project crashes because the external dependency wasn’t declared in the initial “Import” list.
  • The Priority Mismatch: My team’s “Highest Priority” is a “Low Priority” for the team we depend on. This is a Routing Error. The organization is fighting itself, with one department’s “Green” status causing another’s “Red.”

Why Velocity is Leaking
I see leaders tracking “Sprint Velocity,” but they ignore External Latency. If a five-minute code change takes three weeks to deploy because of “Review Queues” in other departments, the team isn’t slow—the Architecture of the Organization is broken.

The team isn’t being “lazy” when they start three new features while waiting for the first one to be approved. They are Context Switching because the “Blocking Call” has forced them to.

The Blueprint: 6 Patches for External Latency
In this series, I will walk through the 6 patches I use to stop my team from idling at the toll booth:

  1. The Interface Agreement – Building against “Mocks” so we don’t have to wait for the other team to finish their code to test ours.
  2. The Dependency Map – Identifying every “External Call” before the sprint starts to avoid the surprise at the finish line.
  3. The Priority Sync – A leadership-level handshake to ensure the team we depend on actually has the “CPU cycles” to help us.
  4. The Self-Service Patch – Empowering my team to write the code in the other team’s codebase (Inner Source) to bypass their queue entirely.
  5. The Asynchronous Roadmap – Ensuring the team has “Local Tasks” to process so they don’t idle while the “External Response” is pending.
  6. The Escalation Protocol – A “Timeout” for disagreements. If two teams can’t align in 48 hours, it’s automatically moved to a higher-level “Router” for a decision.

Submit a Bug Report
To debug your external network, you have to measure the Propagation Delay.

Look at your “Definition of Done.” How many days pass between “Code Complete” and “In Production”? If that gap is filled with “Waiting for [Other Team],” your organization has a Dependency Leak.

You don’t need faster engineers; you need to reduce the number of blocking calls.

2

Leave a Reply

Your email address will not be published. Required fields are marked *