As systems scale, so do dependencies. The question is not whether they exist. It is whether teams know how to work through them.
I’ve seen teams say they’re blocked by dependencies when they’re actually blocked by something else: nobody wants to move until the boundary is finished.
That is a costly mistake.
On a distributed system I worked on, multiple teams across engineering, data, and infrastructure were building from scratch. As the work moved forward, I kept hearing the same thing:
“We’re blocked on schema design.”
“We’re waiting on infrastructure.”
So, I pushed on it: what is it you actually cannot do right now? What specifically requires another team to be completely finished?
The answer was not the full system.
It was not even a finished schema.
It was a schema stable enough to act as a contract.
That is the distinction teams miss. A hard dependency is something you truly cannot proceed without. Most of what teams call blockers are softer than that. They are unfinished interfaces, incomplete decisions, or provisional contracts that are still usable.
Was the schema perfect? No.
Did we expect it to change? Absolutely.
But it was stable enough for teams to move independently. That changed everything.
The teams stopped waiting and started building. More importantly, they started generating evidence.
Engineering worked against the schema as it existed, not the one everyone hoped it would eventually become. And once they did, they found the things that design discussions never surface on their own: gaps, edge cases, naming problems, and assumptions that did not survive contact with implementation.
That is the real value of moving early.
A provisional contract does more than unblock execution. It turns abstract coordination into real signal.
Most teams optimize for getting the dependency right before anyone starts. What actually matters is establishing a boundary that is good enough to learn against. Because until something is used, most of the risk is still theoretical.
A contract does not need to be perfect.
It needs to be usable.
Waiting for perfect dependencies is one of the fastest ways to kill momentum. Teams do not stall because every dependency is hard. They stall because they treat incomplete as unusable.
Those are not the same thing.
Define the boundary.
Use it.
Adjust from evidence.