Good Dependencies, Bad Dependencies

Nobody likes dependencies. They are just an evil that slows us down and causes frustration. So we should get rid of them. Or should we?

At Spotify we sometimes said: “If teams like each other, we call it collaboration. If they don’t like each other, we call it dependencies." Of course this was a bit of a joke, but there’s also some profound truth in this expression: Dependencies have a bad reputation, something that we want to get rid of, because it slows us down. At the same time, teams will always be dependent on each other if they want to achieve great things. Why? In order to get a better understanding of dependencies, let’s look at a single team first and then come back to a setup with multiple teams.

Dependencies Within a Team

Let’s imagine we form a new software development team, which is supposed to build a consumer app. The team needs different specialist skills, so we recruit two app developers, two backend engineers and one frontend engineer. They all share the same goal (building the smartphone app, or maybe even achieving a certain impact through launching the app) and they are mutually dependent on each other. Meaning that they can only achieve their goal if they find ways to collaborate in an effective way so they can utilize their diverse skills. If they manage to do so, they will gain synergies (yes I know, it’s such a buzzword, but it’s actually exactly what we are looking for in effective teams) - the whole will be bigger than the sum of its parts. 

When the members have never worked with each other (or maybe even never have worked in such a cross-functional team at all), the interactions will feel uncomfortable or even awkward.¹ At first the perception might be that “I am doing my part, but the others are slowing me down, because I constantly have to wait for them.” But after a while, if they manage to form an effective team, the perception will start to change and team members will see their fellow team members not as obstacles, but as sources of great skill and knowledge, different perspectives and inspiration. This shift is often even visible from the outside: the team now works as a close-knit unit, they “move as one”. Objectively, nothing has changed about their dependencies: they are still dependent on each other to achieve their goal. But the perception is totally different. Instead of something that is tedious, frustrating and that slows us down, dependencies are now perceived as a source of strength. We will probably not even think of it as dependencies any more. 

Now imagine that they need screen designs which they cannot produce themselves. Every time they need such a design, they request it from the design team and have to wait. Again, this dependency on design will feel like a burden, because it slows the team down. Luckily, after a while the decision is made to add a designer as a full-time member to the team. Now they get the designs whenever they need them. The developers are still dependent on design, but they have found a mechanism (changing the team structure), which changes the perception of this dependency. Through better coordination with the designer, they can now achieve something they could not have achieved before.

Inter-team Dependencies

Now let’s get to a multi team setup, where teams are dependent on each other. We now have a very similar situation to the one we have just discussed. The dependencies between teams are neither “good” nor “bad”. They will be perceived as negative, if teams are repeatedly blocked while waiting for input from other teams. And this is exactly what happens in many organizations: work feels slow and frustrating, there is no good flow. But it doesn’t have to be this way. Like we have learned to see mutual dependencies as a source of strength within a team, we can learn to work as a team of teams, in which each team brings its unique skill and expertise, which enables us to achieve lofty goals, which no team alone could ever have achieved. The question then shifts from “How can we achieve this goal, despite being dependent on all these other teams?” to “How can we use our different strengths and areas of expertise to achieve this ambitious goal?” 

Building such a team of teams is not a simple task and needs deliberate effort, but it’s often worth it. Marcin and I have written a three part series on the key ingredients that are needed.

Reducing Dependencies

In this post I have tried to make the point that dependencies are not negative per se and that they can be perceived as either frustrating or empowering. They are even needed, if we want to work as a real team or team of teams. But of course there are cases where it makes sense to simply eliminate dependencies, because they cause a lot of pain and add little value. Think about some of the sign-off processes we all have seen in our organizations. There are also ways of reducing dependencies between teams, which require policy changes and / or the acquisition of new skills. Think about a model of strict code ownership, where no team is allowed to change code of another team’s system. This will often cause a lot of waiting and frustration. This dependency can be reduced by learning more about adjacent systems, building shared coding standards and mutual trust between teams. 
I just want to point out that just focusing on getting rid of all the dependencies can be too short-sighted.

Summary

Our natural tendency is to view dependencies as negative, something we need to get rid of. While some dependencies just seem stupid and should be removed right away, this approach seems overly simplistic, because it ignores the fact that interdependency is one of the defining features of teamwork, and it enables us to achieve great things together. If dependencies (either within a team or between teams) are viewed as positive or negative is to a large degree a matter of perception. And this perception is shaped by how well we have learned to leverage our respective strengths, or in other words: how well we have learned to work as a real team.

__________

¹ What we often can observe in this situation is that people with similar skill sets (e.g. backend engineers) will form sub-teams and separate themselves from the rest of the teams. Birds of a feather flock together, because we like similarity and it makes us comfortable being with people who are similar to us.