Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew".
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.
At my last job we had a version of our on-prem product where the company sold a super extension for a version that was supposed to go out of support. We had a small team (I think three people) whose only responsibility it was to ensure that version was supported, pipelines worked and we're ready to ship a big fix at needed. That was their responsibility but as long as that was covered they were allowed to work in their spare time on what they wanted as long as they saw value for the company in it. It was a good bargain. Everyone else was grateful the small team was doing the dirty work and the maintenance team was delighted they could use the remaining time working on things that had always bugged them, do research, etc. This was a few years ago and I forgot details but I vaguely remember that we got some really cool improvements and research from them. The people on that team also were really excellent and self-motivating which helped make this a success but also more expensive.
> where people didn't want to naturally migrate to the "future crew".
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.
I've experimented with a two-crew type system before (Red Team for feature development, Blue Team for stability and bug fixes).
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.
Sort of. I've worked with having a rota where engineers would spend a week handling support and bug reports which avoids many of the pitfalls with the entirely separate "two crews". I wrote a bit more about it in https://news.ycombinator.com/item?id=43337703#43339972 .
I would not want to migrate to the "future crew" given that "customer crew" getting enough resources (and adequately compensated). But even without separation it's typical that maintenance is starved while new features getting all attention and resources. I would guess separation on two teams would make it only worse.
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.