Posts Tagged ‘FeatureTeams’
[DevoxxGR2025] Component Ownership in Feature Teams
Thanassis Bantios, VP of Engineering at T-Food, delivered a 17-minute talk at Devoxx Greece 2025 on managing component ownership in feature teams.
The Feature Team Dilemma
Bantios narrated a story of Helen, an entrepreneur scaling an online delivery startup. Initially, a small team communicated easily, but growth led to functional teams and a backend monolith, complicating contributions. Adopting microservices split critical components like orders and menu services, but communication broke down as features required multiple teams. Agile cross-functional teams solved this, enabling autonomy, but neglected component ownership, risking a “Frankenstein” codebase.
Defining Component Ownership
A component, deployable independently (e.g., backend service or client app), needs ownership to maintain health, architecture, documentation, and code reviews. Bantios stressed teams, not individuals, should own components to avoid risks like staff turnover. Using the Spotify matrix model, client components (e.g., Android) and critical backend services (e.g., menu service) are owned by chapters (craft-based groups like Android developers), ensuring knowledge sharing and manageable on-call rotations. Non-critical services, like ratings, can be team-owned.
Inner Sourcing for Speed
Inner sourcing allows any team to contribute to any component, reducing dependencies. Bantios emphasized standardization (language, CI/CD, architecture) to simplify contributions, focusing only on business logic. He suggested rating components on an inner-sourcing score (test coverage, documentation) and dedicating 20% of time to component backlogs. This prevents technical debt in feature-driven environments, ensuring fast, scalable development.