To depend or not to depend
Managing dependencies is often portrayed as a key challenge product teams, or for any software development context for that matter, face. I personally believe the underlying theme is part of some of the most fundamental questions any organization need to hustle with:
To which extent I am willing to accept overlap, risk duplication of efforts, so to enable more autonomy for the teams to deliver things independently; or the other way around: accept that things will tend to take longer because I want to make sure things are (fully) aligned.
At its simplest form, you can think of that as a kind of spectrum – from "fully aligned to ensure things are kept streamlined at the cost of slower moving" to "fully independent and faster, at the cost of possible duplication and accepting additional complexity". In reality, it works more like a polarity tension, and organizations might adjust their approach depending on context, including temporarily (what makes most sense now).
All of that it's just to point out that the discussions on managing dependencies is relevant. But I feel like it's often taken from the from angle, one that assumes there's only way to go about it, which is with some kind of process.
I think that's shortsighted, or if you want to go with a harsher version, some could say borderline "lazy management". Because here's a better way of thinking about it, starting with a principle:
Don't fix with process when you can simplify and making things more robust for the long run with technique.
If/once you embrace that principle, then I think there's a simple playbook we can sensibly derive from that. Let me walk you through that.
1. Avoid unnecessary dependencies
I believe a very simple thought experiment can help to land the criticality of avoiding unnecessary dependencies.
Imagine you are dependent on 4 different services (or other teams) to deliver something that has a clear time sensitivity to it (i.e., "fixed date risk profile"). Imagine there's not much room to adapt to changes in plans (by when you can expect the depending items to be available), thus we can simply say there's a binary "game" at play: it's either you get on time (or earlier) or too late, so theoretically 50-50% chance.
Now, if you simply compound that chance in the 4 times opportunities you have, you can derive that the theoretical chance that all dependencies will be met on time is below 10%. And while reality might not be as binary or even so harsh in terms of chances to deliver in time, still the overarching point holds, and I don't think anyone would be comfortable realizing that's what you're possibly against (even from a pure theoretical basis).
Thus, the very first sensible move to deal with dependencies is just not to have to.
By being deliberate about when you should spare it. For instance, by not adding unnecessary complexity (with dependencies) for things which are on early stages, where you don't quite know yet whether things will turn out in the way envisioned or will have to be highly adapted anyway. Rather take that burden of having to adjust in due time, when there's less uncertainties, accepting the likely level of refactoring that would follow.
2. Relentlessly simplify to reduce dependencies over time
Once you avoided unnecessary dependencies, chances are that there will still be a bunch of cases where you can't just avoid it. That's when you should rely upon engineering excellence so to over time be able to avoid more dependencies, or at least to be able to deal with them more elegantly (which also alludes to the next item).
Now, full disclaimer: I am far from being a specialist on the matter. But I think I know enough conceptually about that to claim that there's a lot of technical discipline that can be leveraged to accomplished that. For example, by defining clear standard interfaces and conventioning that interactions should be only done that way, including elegantly dealing with the transitions of versions, etc.. Or by redefining services boundaries so that independent things are better isolated.
3. Should there be still dependencies that may need managing, make it by default manageable with a service-oriented approach
For as good as you may be in simplifying things and ensuring a technical discipline that allows to handle dependencies elegantly, chances are that there might still be scenarios where you need to make changes to happen concurrently in different services or pieces of the product. The next sensible play then is to make sure that managing those are not an overburden, because by default they can be naturally managed.
This is possible when you embrace a service-oriented approach in managing work. Where different services or teams have SLAs - service level agreements (or at least SLEs - service level expectations) in place, and delivery patterns of cycle time and lead time are known and statistically stable (i.e., predictable). So one can know what to expect when you made sure something you need surfaced and is committed by someone else, and you know you can trust to be delivered timely with good confidence – and assuming that is a manageable timeline for you as well, then it should all be fine.
4. Actively manage the exceptions
In the, hopefully, rare occasion none of the above will help you to handle all dependencies more elegantly or by default, with technique, then by all means have some process in place to manage those exceptions. They likely can be lightweight processes, being only needed in some situations. And because of that you go can much deeper on the exceptional cases, and maybe learn something new that can retrofit as you go along.
Note: It's not linear, nor one-off, but a playbook you can iterate over and over again
The obvious implication is that this isn't a one-off exercise, but a playbook that you keep getting back to, and can make things better as you go along. Like a dynamic adaptive system, going around the playbook over and over again.
It will take considerable time and effort – but quite likely worth the trouble.
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.