[adamtait]

Same. Changing teams every two years seems like a long time. Not mentioned in the post, but I would bet that in Microsoft-land, the release cycle is about two years so it gives a natural transition point. Let's say that an engineer takes 4-6 months to ramp-up on a new team, that still gives 18 months of full productivity. I'm sure that engineers reach 80% of the learning curve was traversed at 12 months.

The fact that it takes them 3-4 days to decide the next round of teams seems very long, in spite the post's insistence that it's short.

I'm interested in environments where teams chose a much shorter cycles. I think shorter cycles would present a different set of challenges, like reducing ramp-up times and cycle decision times. It may also be easier, like reducing the risk of a single cycle decision.

I have heard reports from a company with ~50 engineers who had 2 week cycle times, which was basically their sprint time though releases would have much more frequently. They had the advantage of a mostly homogeneous language and development environment. There kept in up for more than two years, at which point the company pivoted, no longer had a homogeneous dev environment and were doing more greenfield and less support/optimization/incremental-improvement. All reports were great. People were always surprised how the team would even out the teams when put in a single room, where the teams and choices were clear to everyone.