As systems scale, so do dependencies. How you handle them determines whether teams move or stall.
I’ve seen teams say they’re blocked by dependencies when they’re actually blocked by waiting for things to be perfect. It’s a common pattern and one that kills momentum.
On a recent distributed system I worked on, there were multiple teams, engineering, data, and infrastructure, building from scratch. As things progressed, I started hearing a familiar refrain:
“We’re blocked on schema design.”
“We’re waiting on infrastructure.”
So, I pushed on it: What is it you actually can’t do right now? What specifically requires another team to be finished?
The answer wasn’t the full system. It wasn’t even a finished schema. It was a good-enough schema we could treat as a contract.
Was it perfect? No.
Did we expect it to change? Absolutely.
But it was stable enough for teams to move forward independently. And that changed everything.
The teams stopped waiting.
They started building.
And more importantly, they started generating real feedback.
Engineering began working against the schema as it existed—not the one we hoped it would become.
As they used it, they uncovered gaps, edge cases, and improvements that wouldn’t have surfaced in design discussions alone.
That feedback loop was far more valuable than trying to get it “right” upfront.
A contract doesn’t need to be perfect.
It needs to be good enough to unblock progress.
The faster you start, the faster you learn.
The faster you learn, the better your system becomes.
Waiting for perfect dependencies is one of the fastest ways to stall a team.
Define the boundary. Move. Adjust.