In software development there is a pendulum that swings back and forth between “ownership teams” and “feature teams.”

To have ownership teams you just take all the services and deal them out to the dev teams by expertise, interest, or randomly. That’s it! Tickets are assigned to whichever team owns the service in question. Teams are responsible for their services, including all updates, code quality, and technical debt. The teams become expert in their services, so tickets are handled efficiently. This is how developers would prefer to organize. The developers can estimate their tickets well as they are familiar with the codebase, they can complete their tickets ahead of schedule, and leave the afternoons free for playing connect-four. This is why you really only see ownership teams in practice when management has been hands off for a while. Ownership teams are also known as “component teams” and there are plenty of articles that equate component teams with “waterfall” planning.

The main issue with ownership teams is that they become a bottleneck. For a project manager to create a timeline, they will have to first organize the tickets, then determine to which team they will be assigned, and then look at the backlog for each team, compare the priorities, and then figure out when the tickets could be completed. You know, they would have to manage the project, and ain’t nobody got time for that. The other issue with ownership teams is knowledge siloing. If only one team knows how to work on a service it becomes a risk to the company if team members leave the company, get sick, or go on vacation.

Feature teams are set up so that each team will have a mix of capabilities. A team might have developers, data engineers, designers and QA all on the same team. The idea is to create a fungible unit that can take on tasks across the entire organization without specializing in a certain area. With feature teams, it’s easy to plan a project- now the PM can just take the tickets, get T-shirt sizing on them, deal them out to the teams and hit the gym. Feature teams are also good at spreading knowledge around the company, as each team will get to work on a variety of services.

Now life is wonderful! We are shipping so many features. The tickets have to be padded to allow for the team to ramp up knowledge on the system, but there are no bottlenecks. At most a ticket has to wait one sprint in order to be prioritized. The PMs are hitting the gym every day; they look great and they feel great. The one little issue is that developers aren’t a fungible resource. Feature teams are going to create technical debt and bugs. Feature teams aren’t actually familiar with the codebase, they’re just doing their best. Even a great feature team will become “surgical” in their work, trying to make the smallest possible change to get their ticket accomplished in an unfamiliar codebase.

Once the feature teams have caused enough regressions and the support queue has grown large enough the pendulum will start to swing back towards ownership. Feature teams will move to a hybrid of feature and ownership and will be assigned services, and everyone will agree with the best of intentions to spend a good percentage of their working time on tickets to address the technical debt. If the bugs and technical debt get too high it could be that the managers are put on performance review, leading to a lassez-faire approach, and letting the dev teams run the show.

So it goes.