I’ve written previously about my thoughts on team structure. I’m a fan of product-centric teams — multidisciplinary teams that embed members from functional groups on the same team, all working together to create and ship a software product.
Team Evolution
At some point, a team might grow large enough that you want to split into smaller groups, each with a primary focus. You’re still building a single product, but now you have a collection of product-centric teams working on specific features. How did you get here?
- Teams get harder to manage and coordinate as they grow in size.
- Product-drivers feel like it’s a struggle to get development focus on their features.
I’ve been able to work in both situations: single product-centric team, and multiple feature-based teams. My preference is still the single product-based team. The downsides of feature-based teams outweigh the advantages.
- Teams become silos and stop focusing on the product as a whole.
- Issues without a clear owner become someone else’s problem.
- Cross-team communication becomes more difficult as more groups are created.
- Individual team ambitions inadvertently dilute the primary focus of the product.
Conway’s Law tells us that organizations tend to build products based on the organization’s structure. Using several small teams, with a focus on specific features, will have an effect on the final product. It might not be a desired effect.
Mindful Divisions
I’m not suggesting teams grow beyond 7 to 10 people. There is plenty of literature, and experience, that tells us that would be bad, and even less efficient. But how you divide teams is important. Some divisions are more natural than others:
- By platform (Desktop, Android, iOS, Web): Make sure there is some product consistency across platforms.
- By front-end / back-end: Make sure both sides are part of defining the interaction APIs.
- By application / UI widgets: Make sure both sides are part of defining the component APIs.
These separations are clean and easier to identify.
Feature Survival
Single product-centric teams bring us back to the issue of product-drivers fighting for development focus. I think this is a good thing.
When features are implemented through a single team, you need to be good at prioritizing. It shouldn’t be easy to add every little feature to the product. By making all features compete for priority, you make sure the best features get the attention.
I believe this makes the product stronger.