Code Sharing and Collaboration

Recently I spoke about a topic that is discussed a lot here at OVO; how to get our teams to collaborate across codebases. We want our teams to be empowered to take end to end responsibility to solve customer problems. This means removing blockers, knowledge silos, and enabling collaboration in any codebase.

Too often we see the following pattern. A team (Team 1) with a well defined team goal and backlog, finding that there is work needed in another team’s codebase/domain in order to achieve their goal. What follows is some discussion and prioritisation with that second team (Team 2) to get them to pick up the needed work. During this time Team 1’s ability to complete work tends to drop to nothing as they get blocked by Team 2. Then at some later time team 2 picks up the work and the problem gets solved. See cute gif below:

This is a very common pattern . As a software engineering manager a large part of my job in previous roles has been working out how to try and foresee the risk of this happening and ensure we get these dependencies prioritised before the teams become blocked. There is a whole host of manager magic that goes into making these problems go away, and if they succeed then the work will smoothly sail its way to completion, with the people who understand the codebases best doing the code changes.

Though, as you may be able to tell from my slightly biased statements, there should be a better way. What if the first team was able to complete the changes in other team’s codebases themselves. We would still need a period of discussion and the team’s productivity should be expected to dip, but in the long run the work can still be completed faster than waiting for prioritisation. A moderately different gif to describe this pattern:

In this model, not only is Team 1 able to balance their own work and own the changes across the needed flow but they are also learning about other parts of the system that they rely on for customer value. We would also then expect Team 1 and Team 2 to maintain a higher standard of code quality as they need to be prepared for others to start from scratch and deliver value in a short period of time.

Obviously, this model needs some prerequisites to work well.

1. The first and most important is that all teams are open to receiving contributions. It is a big mindset shift to have a whole tech department that embraces innersource, and it impacts all the other prerequisites.
2. The code is well documented and readable, it is also important that decisions which have caused it to come into being can be followed by a newcomer. This means that contributors can make changes with confidence without worrying about what hidden fundamental workflows they are breaking with their changes.
3. Testing and deployment of the project is well maintained, easy to understand and use. Contributors are not going to understand the ins and outs of the entire repo and architecture, and your testing should prevent them from making changes that break functionality or SLOs. The contributors will also want to test their changes themselves so having an easy to use local dev setup will save time in the long run.
4. The maintainers of the code are identifiable from the repo. This is often overlooked, but yelling “Which team maintains tools_config” is not a method that will scale.

An important final point is the removal of the word ‘ownership’. This concept no longer helps you when you are trying to create a culture of collaboration. Instead, move to a Maintainers/Contributors model. A good definition of these terms I found on the github intro to inner source, I feel they probably know what they are talking about:

Maintainers: Developers, product managers, and other key decision makers within your company who are responsible for driving a project’s vision and for managing day-to-day contributions.

Contributors: Developers, data scientists, product managers, marketers, and other roles within your company that help drive software forward. Contributors are not necessarily part of the direct project team but help build software by contributing code, submitting bug fixes, and more.

Now all you need to do, is go out and take your teams and product on a journey to get your teams working better together. There may well be an upfront cost, but the benefits of clean easy to use code are felt by the maintaining as well as the contributing team, and the goal of more efficient teams is something we should all feel prepared to put effort in to.