|
It turns out that at a certain point, features start requiring integration in the system. Let's take a hypothetical SaaS that provides workflow management for a domain. Let's say there are about 125 engineers. Workflow can't be 60 engineers, so it's really 12 teams, given teams of 5. One takes the notifications engine and builds emails and slack notifications. They have an API for other teams, but this feature requires a new feature from the notifications system. That's a relatively light touchpoint, but two teams are involved in a dependent relationship. Now let's say there's a partner integration team. This team provides an external API to ease integration with tools such as Salesforce. This team has a full backlog, and it's a complicated subsystem that doesn't do well as common code. (External APIs also require governance.) So, this feature requires work from the external API. To call this feature finished, this team needs to be able to input and export to other systems, but is not the primary feature of the application. So, you have a second team involved. Third, you have an internal support team that handles tech support and setup for clients. This team now has work to do to onboard clients. And there's the team that does the work in the workflow. As such, this org could need four teams to get a feature done. Now, you could say that such a team could use common code ownership to get things done, but then you have 125 engineers that have to understand a series of systems and not step on each other, systems that they only work in occasionally and change by the time they need to get in again. I've worked in a common code startup and it works... up to a point. It is definitely slower to have to onboard continuously in other code areas in which you don't have domain experience, even if the documentation is spectacular (and it better be!) |