Team Dependencies

One of the toughest things you will face in your career is not the code, it’s the dependencies between teams. In a small company, this will be fine, you can message Bob and ask for that latest API change. In larger companies, teams are typically broken into 10 or fewer developers who maintain a certain repo or part of the company codebase, maybe a few repos. This means that if I need the latest API changes, I can still message Bob, but Bob might tell me that they are waiting on the latest changes from another codebase. This is the nature of larger companies and large codebases. There are many teams and many people involved, all of whom have their deadlines and pressures. This can be enormously frustrating, especially when you are a customer-facing application, you will have more and more dependencies the closer you are to a customer.

Take for example the addition of a date of birth field in the UI. Your team is responsible for the UI, so you create a ticket to add another field on signup that collects this information. In a well-designed system, adding a field to a signup form that already exists should take maybe a day at most. Now the real complexity comes when you then have to send that data somewhere. Your company might have a structure where its UI → Customer API → Internal API → Database. This leads to many dependencies if each of these teams then has to individually edit their code to add this field, or the capability to have this field. Here in lies the problem with large companies and many teams. To get this change through from start to finish, your manager tells the business it will take 6 months to complete. 6 months they say, to add one single field to a signup form, lots of swearing ensues. Your manager explains the complexities of implementation, the teams, their deadlines, and the complexity of changing a database. Sure enough, 9 months later, much longer than expected, the field is ready for users. It’s gone way over budget and way over time, just to add one field. This is obviously a contrived example, but the point remains the more teams you have spread out over more repositories, the more communication is required and the more things that can go wrong. Dependencies are a killer for any deadline. This doesn’t even consider the fact that your team has been instructed to add one field, but now you have to force all these other dependencies to complete work for you. Which affects their deadlines, their projects and makes them angry. Again, this is a contrived example, yet I see similar things frequently happening in large companies.

Well, what is the solution? I have been thinking about this for some time, I think the only real solution is to have teams that consist of people across the major dependencies. Microservices have numerous benefits and often microservices are done in many repositories, having a team that can access each of the services to add their code removes the dependencies. Instead, the team that needs the feature has to get it done, they can’t simply throw their hands up and say well Bob’s team didn’t do the work, we are blocked. Instead, you create teams which consist of people from all parts of the organisation. You could have a few frontend developers who have worked on many of the frontend repos, or at least enough to get the user DOB field in. Then you have a developer from the “Customer API” team, again one from the “Internal API” team and lastly a database guru. You have one developer from each section or each dependency that you would have previously relied on. Now what would have been many teams, is one, and they all have control over each part of the application. Thus, reducing the number of dependencies reduces the amount of pain for the team. In this manner, you could reduce the time from the eventual 9 months to a month (or some other significantly smaller number). You have less communication issues, you have someone who knows about each part of the stack, and each person has the same deadline!

The business delivers features faster, people still get to specialise in the area they want to or try new things, and there isn’t this huge communication issue. Put simply, having more teams increases the amount of communication that has to happen, but it’s how you split these teams up that really determines if it will be a pain or a pleasure.

Companies that have many teams in silo always produce toxic results. Teams hate each other, in fact, it gets downright nasty because one team is reliant on another and that team is busy working on something else. This results in both teams getting pressure from their managers for different reasons, then both teams complaining to their mangers' manager that each team is terrible. Then mangers push on them the deadlines of both teams simultaneously. It results in both teams hating each other, not working well, and generally creating an awful place to work in. No team wants to produce bad software, full of bugs, and delivered late. Teams aim to do their best work, they just need the organisation to support this. I think this too often becomes the norm, and it really allows poor culture to grow. I have seen people have breakdowns because of the stress of it all. This might have been one of many reasons, some of which personal, but the point remains. If you can remove these kinds of stresses from the workplace and increase the time to market, why wouldn’t you?