In a company where you have a single product team working on a single product, life is simple. You do standups, you sit at the same table, you have lunch together. Communication is typically not a problem. Once you have 2 teams however, you have 2 standups, 2 tables, and maybe you have lunch together a few times a week. Now you have to start making an effort to make communication happen. I recently moved from a company with 3-4 product teams here to Amplify, where we typically run 8-10 teams across 2 continents. That’s a lot of missed lunches.
These days, you’re likely to be running your product teams as a loosely coupled system. This is at the heart of *nix operating systems, modern web architecture, and the open source ecosystem itself. This means that teams are mostly independent, making their own decisions about when and how to share information.
This is not a (very) new idea. It plays nicely with agile practices, rapid product development, and happy developers. In practice, the process of sharing code in a company of loosely coupled teams often parallels an open source ecosystem at it’s surface, but how do you make it work in your business?
My cutesy title “Bazaar in the Cathedral” is of course a reference to Eric Raymond’s essay about open source software development. In that essay, the cathedral refers to software “carefully crafted by individual wizards or small bands of mages working in splendid isolation”. When you are running a group of teams as an open source ecosystem, you want your organization to look like a cathedral, but run like a bazaar.
A Good Idea is the first requirement, and it may seem like an obvious one, but it is easily defeated through mandates. If your product teams have a mandate that they must use an internal project, the good idea becomes optional, and the advantages of open source development is lost. The idea does not need to be perfect at its onset, but it needs to have what Raymond calls a “Plausible Promise”, and that promise needs to be powerful enough to make other teams want to use it.
Ownership is a requirement that cannot be overlooked. A project without an active maintainer is a dead project. This is especially true within a company. As developers leave a company, the dead projects pile up quickly. You cannot succeed with individual people owning projects, you need a team to maintain each of them so that as people leave there is a continuity in maintenance. Even if a project isn’t being actively developed, as long as you have a product that uses it, you need a team to address issues as they arise. Dead projects don’t just decompose on github when you are running them in production, they come back to haunt you eventually.
Community, of course, is also key. Project maintainers need to be willing to document, lend assistance to newbies, and be responsive to requests. While project maintainers may be willing to help out another team on occasion, for the project to succeed they need to enable other teams to do it. If the bar for contributing to another team’s project is too high, developers won’t bother, and the whole system falls apart.
Evolution of a project is to be expected. Needs change, technology changes, and thinking changes. Project maintainers need to be ready to adapt, expecting their project to go through several major versions over the course of it’s lifecycle. Also expect that lifecycle to end once the purpose of the project diverges too far from the needs of the products.
Motivation is something you’ll need to consider as well. Teams will have their own product priorities (aka their day jobs), which will not always involve their shared projects. There are a few tools you can use to help with motivation. First, the same things that keep maintainers motivated in the open source world will work internally: pride of ownership, the respect of peers, and the sense of accomplishment. Second, organizations can make project ownership an expectation for career development. Finally, you can release an internal project publicly . That’s not always an option, but where possible it will be a powerful incentive for the team.
This post focuses on where you can use the social context of open source as a great tool for organizing your teams, but it’s only a start. You should definitely read Eric Raymond’s work (again), and if you haven’t already, look at the communities around your favorite open source projects for inspiration.