Three ways to manage dependencies
I share my thoughts on three types of dependencies and on how they are managed differently.On Thursday I said that cross-functional teams aren’t the only valid team structure which sparked a discussion on LinkedIn about dependencies.
So today I want to share my thoughts on three types of dependencies (with my own invented names), and some comments on how they are managed differently. This is by no means intended as an extensive list!
- Tightly-coupled dependencies
These are (should be) dependenciees that are core to your team’s business goals. And this is where cross-functional teams shine. If you’re building a feature that requires close communication between a React developer and a Ruby developer, then this is perfect!
- Peripheral dependencies
This is dependency that your team needs, but isn’t core to the business goals of the team. A simple example from my past would be my team building an email filtering product that integrated with a third-party CMS system. That integration was a clear dependency, but if we had hired a CMS integration engineer onto our team, she would have sat idle 51 weeks out of the year. Instead, we consulted with an engineer who worked for the CMS company once or twice per year when we needed their expertise.
- Platform dependencies
These are often overlooked as dependencies, but if they were to disappear your team’s ability to function would be severely limited. This can be everything from the operating system on your work laptop, to your ticketing system, to your cloud provider. These dependencies are charictarized by almost exclusive one-way communication, or a “pull” relationship. That is, your team pulls in an update (to your operating system, for instance) when you wish to. There’s typically no coordination with the provider of the dependency. In the rare cases that you do need to communicate with the provider of the dependency, it’s probably through a helpdesk or ticketing system of some sort, and it’s probably impersonal.
