The Dependency Leak | Article 4: The Self-Service Patch

I used to think that “Ownership” meant staying in your own lane. I told my team: “We build the app, the Platform team builds the infra, and the Security team writes the policies.” I thought I was creating clear boundaries to prevent “Spaghetti Responsibility.”

I was wrong. I was actually creating Permission Silos. Every time my team needed a minor change in a “Foreign Module,” they had to submit a ticket and wait. I had turned my engineers into Supplicants rather than Builders.

The Logic of the Bottleneck
In a monolithic system, if one function is slow, the whole program crawls. In an organization, the Ticket Queue is the ultimate bottleneck.

• The 5-Minute Change, 5-Day Wait: My engineer knows exactly which line of code needs to change in the Platform repo to fix our build. It’s a 5-minute fix. But because they don’t have “Write Access,” they have to open a ticket. This is I/O Throttling. The system is capable of high speed, but the “File Permissions” are forcing a crawl.
• The Context Serialization Tax: The external team doesn’t know why we need the change. My engineer has to write a 3-page “Justification Packet” (the ticket) just to get a 1-line change approved.
• The Knowledge Gap: Because my team isn’t allowed to “see” inside the other team’s codebase, they treat it like a Black Box. When it breaks, they can’t debug it. They just sit and wait for the “Experts” to arrive.

Why the “System” is Idling
I see teams that are “Blocked” on trivialities—a missing environment variable, a config tweak, a small CSS update in a shared library. This is Autonomy Latency. We pay for “Full Stack” engineers but force them to act like “Partial Stack” employees because of organizational “Access Control.”

The team isn’t “unskilled.” They are Disempowered. They are Ferraris being held back by a “Valet” who lost the keys.

The Patch: The Inner-Source Protocol
To fix this, I have to move from “Ticket Queues” to “Contribution Agreements.” We move from “Do it for me” to “Let me do it for you.”

1. The “Write-Access” Handshake: I negotiate a protocol with other teams: “My engineers won’t just ask you for changes; they will submit the Pull Request themselves.” We treat their repo like an Internal Open Source project.
2. The Fast-Track Review: Because my team did the “Processing” (the coding), the external team only has to do the “Verification” (the review). This turns a Blocking Call into a Background Process for them, making it much more likely to get merged quickly.
3. The “Standard Library” Education: I encourage my engineers to learn the “Basics” of our dependencies. If we depend on the Data Team, my devs should know how to write a basic Migration. We are increasing the “Instruction Set” of our own team.

Submit a Bug Report
How do you know if you have a Self-Service Leak? Look at your “Ticket Lifecycle.”

If you see engineers “waiting” for more than 24 hours for a change that takes less than 1 hour to execute, your permissions are too tight. You have a Lock Contention problem.

Stop being a “Customer” of other teams and start being a “Contributor.” The fastest way to get a dependency resolved is to realize that, with the right permissions, you are the dependency.