team structures

most companies scale teams and “territory” (namely, codebases) in an unstructured, evolutionary, ad hoc way. i once watched a talk about scaling while staying agile, and it inspired me to illustrate this with a specific hypothetical structure.

let’s say we have an organization which can have one or more services and one or more product teams (called “pods” in the aforementioned talk).

• product teams are a team of developers who all work off the same backlog, and are fungible within that backlog. processes are utilized to maintain this. for instance, whenever they’re ready for work, product team developers take the next item in the backlog. and they’re full-stack within that organization. whenever they work on a user story (“feature”), they directly edit any necessary code from within any of the services in their organization.
• services are generally defined as running binaries/processes. every service gets its own code repository. if services need to share code, they do it via versioned packages. in principle, if two services share code module X, then X could live within the repository of either service, but it’s considered cleaner to give that shared code its own repository. services only communicate via versionable APIs. they don’t directly access databases. i.e. every non-versioned storage device is owned by exactly one service.
• it’s fine for a product team to be the only one within their organization that works on a given service, serviceX. they remain in that organization so long as they’re free to directly modify the code of any other services within that organization which need to interact with serviceX. if bob works on serviceX and it requires a change to serviceY, but he’s expected to put in a request to another product team to make that change, then serviceX and serviceY cannot exist within the same organization. it’s expected that services will sometimes grow in scope and complexity until such API separation is desirable, at which time they’ll be broken off into a new organization.

there are some minor caveats, but in general i believe a coherent set of organizational principles like this can be beneficial as companies scale beyond the standard two-pizza team.

an example of a caveat

a ruby on rails application will often have jobs which are part of the same codebase as the rails web application, and therefore have the same database models and access the same database. however, they run in separate job runner processes. effectively they’re separate running instances of the same “binary” (the same codebase), but they run the jobs rather than the web server.