In my career, there are 2 kinds of team structures I've worked with and I prefer on over the other. Here's an overview before we talk about my preference.
Speciality-based
In this structure, teams are split around specialization - design, frontend, backend, cloud etc. This works pretty well in some places until the engineering org gets pretty big. Once that inflection point is hit, teams start becoming bottlenecks for each other.
Think of teams like design, cloud infrastructure, release engineering, platform engineering - teams that operate in a support role for other teams. They tend to automatically be overloaded because they service every other team in the org. To circumvent the load, they begin to rely on a lot of process to manage the workload.
- Did you make a JIRA ticket for that?
- What's a blocker for your team is 5th on our list because there's a lot of blockers ahead of you.
The other downside of this setup is it lends itself to a very waterfall-like approach. Teams gravitate towards taking and assigning ownership, which leads to turf wars, blame games and an attitude of "not my problem".
I'm sure there are places where this works really well and I can be proved wrong but in my experience, it's really hard to get this setup to be a collaborative team structure.
Pod structure
A pod consists of people with cross-functional skills working together on a business vertical. This usually looks like:
- A couple frontend developers
- A couple backend developers
- 1 UX designer
- Led by 1 PM
This type of structure works great because teams can independently explore ideas and ship features without much concern for what else is going on. It really enables the whole team to work as an independent unit led by a PM who prioritizes work based on their roadmap. It's liberating because you get to ship features fast. It's highly collaborative so developers can provide input on design and PMs can make room for tech debt and architectural work that's not strictly on their roadmap.
However, things such as UX research and larger design initiatives become harder because those projects usually happen one step ahead of development. Since that can be a little difficult to coordinate, usually designers would have an additional group they are a part of, that integrates within the design org.
This setup also means you expect a really solid cloud / platform / infra team and have all those things figured out and in place before the pods can execute. It's really intended to enable rapid development and shipping. Where it really falls apart is if you have a team structure like this but they still share the codebase with other pods - that tends to get nasty.
Small teams, small codebases
The concept of a small independent team should also reflect in the codebase they are working on. It needs to be small, decoupled and independently deployable. If that is not available, this team structure falls apart because you will constantly run into integration issues, conflicting methodologies. One big concern is how to enforce overall code architecture / style issues because it conflict with how fast teams are able to move - meaning you add developers, they ship features but if you are trying to impose any kind of guidelines or guardrails, you become the bottleneck.
My preference
I like the pod-style because that was the most satisfying roles I've had. Primarily because I was able to ship fast. It builds a sense of ownership around the team - when the collaboration-mode kicks in, it's magical.
However, I have been a part of this setup where the codebase was a deterrent. That's why I strive to break down big monoliths, frontend or backend and create smaller, independently deployable units that enables this kind of team structure to thrive.