Team A is blocked for three weeks waiting on a small change from Team B. What are the options and what does each cost?

What is being tested

Whether you can enumerate the realistic responses to a blocking dependency and price each.

The options

1. Wait. Costs three weeks of A's delivery, and it recurs. Multiply across an organisation and this coordination cost dominates delivery.

2. Escalate to reprioritise B's backlog. Costs B's priorities and creates a precedent that escalation works, so escalation becomes the mechanism. Corrosive over time and it does not scale.

3. A contributes the change to B's codebase — InnerSource. A does the work; B reviews and accepts. Costs B review time and requires the practice to exist. This is usually the best answer.

4. A works around it — duplicating the functionality, or building an unnecessary abstraction. Costs duplication and long-term divergence, and it is what teams do by default when the other options are unavailable.

5. Change the boundary. If A repeatedly needs changes in B's service, the boundary may be in the wrong place. Costs a refactor and possibly a reorganisation.

What InnerSource requires to be real

The critical constraint is review capacity, not tooling:

• Maintainers who review external contributions with a defined response expectation. This is real work and must be resourced.
• Discoverability — code searchable, ownership clear.
• A contribution guide per repository: how to build, test, and what will be accepted.
• Tests good enough that a maintainer can accept a change from someone unfamiliar with the code.
• Recognition, so maintaining a widely-used internal component is visible and valued.

Declaring InnerSource without funding maintainership is the characteristic failure: contributions arrive, nobody reviews them, they go stale, contributors stop trying, and the practice is discredited while the original bottleneck remains.

Where it works and where it does not

Works for shared libraries, platform components, tooling, and services with many consumers and a stable interface.

Works poorly for code with deep domain complexity where an outside contributor cannot reason about correctness, and for components under rapid architectural change where contributions conflict continuously.

The diagnostic question

How often does this happen? A one-off is a coordination problem; a pattern is an architecture problem.

If A is blocked on B every month, the boundary is wrong, and InnerSource is treating the symptom. Fixing the boundary — merging the components, moving the capability, or giving A what it needs directly — is the durable answer.

What a strong answer adds

That option 4 is what happens by default when nothing else is available, and it is the most expensive option because the cost is invisible and permanent. Making options 3 and 5 genuinely available is how you stop paying it.