Dependencies: the good, the bad and the ugly
At the risk of ruffling some feathers, I would like to suggest that dependencies are not in and of itself necessarily a problem. For instance, they can surface a kind of healthy conflict that needs managing, so that broader, more holistic aspect might be considered when it comes to prioritization.
A simple example might come handy. Let’s imagine that there are two teams, A and B, and each of them have currently options identified as their own priorities, with an idea of cost of delay associated to it:
Team A options:
(1) 150k “money”/”time”;
(2) 50k “money”/’time”;
Team B options:
(1) 40k “money”/”time”;
(2) 35k “money”/”time”.
For the sake of simplification of the argument, let’s imagine there’s not a considerable difference in effort for each team to decide to go for one or the other of their own options. So looking purely from their own little silos as prioritization they know what to do, starting from the top, with an opportunity for the company to achieve a combined outcome of 190k next.
Now let’s imagine there’s a caveat. And Team A cannot finish any of their options (1) without help from the Team B (and by help we mean a considerable dependency that needs instensibe collaboration). From an overarching organization standpoint, what’s best then? Should Team B start any of their options or perhaps consider focusing on helping out Team A, who have two options that sum up to be considerably bigger?
It’s probably not necessarily the only one, but a big aspect that turn to be a good thing about dependency is precisely this forcing of broader thinking in terms of leverage for achieving more value in an organization.
Obviously the assumption here being that there’s a good enough reason for things being like they are, on why Team A and B necessarily have to be separate. That’s when things can get interesting, if not more complicated.
Chances are that sometimes the answer to that question is not as clear-cut. And being separated should be challenged. If that’s the case, not doing so (challenging the team’s separation), not taking the opportunity to simplify things up is when dependencies start becoming a bad thing.
Maybe you have seen that for yourself, but organizations can get quite used to cope with dependencies through processes and whatnot, arguably for not being willing to have the deeper and harder discussion that should lead into simplifications that are darn sure possible. Be it from a technical / architecture standpoint, or even by better aligning the organization setup with (the current) strategy, just to name a couple of the usual suspects of source of simplification.
Buying and fully relying upon a sort of “wholesale” supposed solution to deal with the complexity through process, like some of the (in)famous agile scaling frameworks is when things may go beyond the bad, and look more like a ugly thing.
So the real question is not whether dependencies (should) exist or not. But rather whether they exist for a fair and good enough reason, and not just as a kind of excuse for not dealing with some hard conversations and need to change.
That’s why for quite some time now I’ve been looking at the general issue of dealing with dependencieas as a sort of 4 step thing:
We should avoid dependencies which can be avoid (with better architecture, with adjusting organizational structure to better align with strategy when possible).
We should work relentlessly to evolve with new insights, going back to 1.
We should grow the service-orientation of the organization so that all the remaining dependencies can be dealt with organically for the most part (think of service-levels, reliability in delivery patterns of cycle / lead time).
Actively manage dependencies when truly needed (when all the previous steps won’t do the trick).
Surely much easier said than done, but a trouble pretty much worth having… And to be clear, steps 1 and 2 are not to be considered lightly either, it’s an advocate for constant unnecessary change, like regular constant reorgnizations. It’s much more nuanced and adaptive than that, what I am alluding to. It’s relentless, not reckless.
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.