The Dependency Leak | Article 2: The Dependency Map
I used to think that “Agility” meant being ready to pivot at a moment’s notice. I thought that if a project hit a snag, a smart engineer would just figure it out on the fly.
I was wrong. What I called “Agility” was actually Runtime Discovery. I was allowing my engineers to start building a system without checking if the required “Modules” were actually available in the environment.
The Surprise “Import” Error
In programming, you declare your dependencies at the top of the file. If a library is missing, the code fails at compile time—which is cheap. In an organization, we often discover dependencies at “Release Time”—which is incredibly expensive.
- The Late-Binding Failure: An engineer is 90% finished with a feature when they realize, “Oh, I actually need a new firewall rule from the Security team to make this work.” This is a Missing Dependency Error. The project hits a wall at the finish line.
- The Shadow Bottleneck: We plan a sprint for our team, but we don’t realize our work requires three “Pull Requests” in a repository owned by the Platform Team. We’ve unknowingly tied our Clock Speed to a team that doesn’t even know we exist.
- The Resource Contention: We assume the “DevOps” node will be available to help us deploy on Friday. We didn’t realize four other teams also made that same assumption. This is a Hardware Conflict. The human resource is over-allocated, and our project is the one that gets “Dropped.”
Why Velocity is Leaking
I see projects that look “Green” for three weeks and then suddenly turn “Red” on the final day. This is Discovery Latency. The team didn’t get “slower”; they just finally hit the external dependency they didn’t see coming.
The team isn’t “unorganized.” They are Under-Mapped. They are trying to run a program without checking if the “Drivers” are installed.
The Patch: The Pre-Flight Import Check
To fix this, I have to change the “Planning Logic.” We move from “Guessing” to “Static Analysis.”
- The Dependency Audit: Before a project moves from “Backlog” to “In Progress,” the engineer must list every External Node required for success. Do we need a database change? A security review? A new UI component? If it’s not on the map, the ticket doesn’t move.
- The “Blast Radius” Scan: We look at the map and ask: “Who else owns these modules?” We identify the “owners” of our dependencies and send an Initialization Packet (a heads-up) weeks before we actually need them.
- The Critical Path Visualization: I make the dependencies visible in our tracking system. If a task is “Blocked by [External Team],” it shouldn’t be hidden in a sub-task. It should be a System Warning that is visible to everyone.
Submit a Bug Report
How do you know if you have a Dependency Map leak? Look at your “Friday Deploys.”
If your team is frequently “Ready to Ship” but realizes at 4:00 PM that they are waiting on a “Sign-off” or a “Config Change” from another department, your map is broken. You are discovering your dependencies at Runtime, and it’s crashing your velocity.
Stop discovering your obstacles when you hit them. Map your “Imports” at the start so you can clear the path before you even hit the throttle.