How to manage team dependenciesDon't manage your dependencies. Eliminate them.
Don’t you just hate ’em?
You can’t build that next big feature yet, because you’re waiting on a dependency from the graphic designer. Or the architect. Or the backend team.
Or you have built the feature, but you can’t deploy it yet, because of a dependency on the release engineer. Or the testing team. Or some other feature built by some other team.
How do we manage all of this complexity?
Pro tip: Don’t!
Don’t manage your dependencies. Eliminate them.
This is the concept behind the idea of a “cross-functional team” that has been made popular by frameworks such as Scrum.
Instead of waiting on the backend team to build your API… put the backend skills you need directly on the team, and let the team build that capability directly. And instead of waiting on the testing team to get back to you in a few days… get those testing skills on your team!
If you’re managing dependencies, you’re probably doing it wrong. Dependency management should be a last resort.
Not all dependencies are created equal
What makes the Linux kernel as a dependency less problematic than another team in your company as a dependency?
Cross-team dependencies should be low-context
Cross-functional teams or highly specialized teams? Both can work, but the latter requires low-context dependencies.