What codebase and CI/CD prerequisites enable LeSS feature teams?

WHAT THIS TESTS: Whether you recognize that organizational structure follows technical capability. LeSS feature teams are cross-functional and cross-component, so the codebase and pipeline must eliminate the friction that traditionally justifies component teams. Interviewers want to see you connect team topology to engineering practices rather than treating agile adoption as purely a process change.

A GOOD ANSWER COVERS: Four prerequisites in priority order. First, continuous integration that is actually continuous, meaning trunk-based development with sub-10-minute build and verify cycles so that multiple teams can integrate into main many times per day without chaos. Second, comprehensive test automation at unit, integration, and acceptance levels so that any team changing any component gets fast feedback on whether they broke something they do not own. Third, architecture and code health practices that reduce cross-component coupling, using evolutionary architecture, clean code, and possibly strangler fig patterns to break down monolithic component boundaries so teams do not need specialized gatekeeper knowledge to make changes. Fourth, shared code ownership mechanisms such as pair programming, mob programming, or collective code review backed by coding standards so that no individual or team becomes a bottleneck.

COMMON WRONG ANSWERS: Suggesting that feature teams can succeed with better documentation, more coordination meetings, or interface contracts while keeping component silos. Proposing long-lived feature branches or GitFlow because teams are large, which destroys the integration rhythm that makes shared ownership possible. Claiming that each feature team should own a slice of the architecture, which misses the cross-component mandate. Ignoring the Definition of Done and suggesting that integration or hardening sprints can handle cross-team work.

LIKELY FOLLOW-UPS: How would you migrate a component-team organization to feature teams without stopping delivery. What do you do when one component is a legacy monolith that only two engineers understand. How do you handle code review throughput when every team can touch every repo. What metrics would you watch to know if the technical prerequisites are actually working.

ONE CONCRETE EXAMPLE: A telecom billing system has separate component teams for rating, invoicing, and taxation. To move to feature teams, they first collapse all repositories into a monorepo with trunk-based development and a CI pipeline that runs 4000 unit tests in under 8 minutes. They add contract tests between bounded contexts and use the strangler fig pattern to isolate the legacy taxation engine. After 6 months, any of the 5 feature teams can deliver an end-to-end pricing change because the architecture and pipeline removed the need for taxation specialists to approve every commit.

Source: less.works