Self forming teams at scale

Actually, this team is responsible for both TFS (major releases 1-2 years, minor releases quarterly) and Visual Studio Online which is a hosted service and releases once every three weeks. Pretty much everyone on the team works on both products because they share a very large percentage of their code.

Source: I'm the guy closest to the camera in the picture. Oh, and we're hiring if anyone is interested.

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.

I feel that continuous and frequest releases do not serve the end user.

It can take time to find and fix subtle bugs. Adding new features introduces new subtle bugs.

Even as a developer, for me to grow happy with a tool often means that Apple will crush my joy by altering thatntool in a way that makes no sense to me.

Today's "UX" is particularly tragic. I find so many user interfaces that make no sense. Perhaps thats because there isnt enough time to solicit feedback from end users.