I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.
I think the book captures a solution to this with:
> Engineers rotate between the crews on a regular basis. The Microsoft blog post referenced above recommends swapping some team members between the two crews every week.
> Define the customer crew as a temporary team. This can mean either that the customer crew itself doesn't exist full-time (perhaps for only one week per month), or that team members are constantly rotating between the customer and feature crews.
> Has anyone worked in a "two crews" system where there wasn't resentment?
yes. I've worked for a few places where the teams are fully distinct and it works well. In games think Engine team vs Game team. Even on the Game team at one of my previous roles the way it worked was you'd get put on a feature which might take 6-12 weeks to ship, and then there'd be some maintenance work/updates/tech debt after that. Your primary focus was the thing you just shipped but you'd also have the time to go back to some of the previous stuff and work on that too. During that time, the other team would be on the same rota, and after 6-8 weeks you'd on-ramp to a new feature and repeat.
Rather than treating these as fixed teams, we treated them as workstreams that people rotated between every sprint (every two weeks).
It worked for about 3 months, until it didn't - by then we had grown enough to organising the teams around the business capabilities or domains instead.