Microsoft Teams: Here's why your colleagues get new features before you do
Teams feature envy: IT admins now have a way to explain why some colleagues get new features first. It's not a mistake but part of Microsoft's deliberate testing processes for new Teams updates and features.
Martin Rinas, a Microsoft principal program manager, explains that due to the complexity of supporting so many people, connectivity types, and device types, every update includes "feature flag configurations". These feature flags let the company ship new versions of Teams to everyone, but then enable the features separately.
Some of the complexities include supporting hundreds of millions of people across the world. These days, those users are remote working and learning on network connections of varying quality. Plus, Microsoft needs to support the app for the web, Windows, Mac and Linux, as well as iOS and Android.
Microsoft's "orchestrated" roll-out strategy consists of shipping a new version of Teams with the code for the new features in the update. The second step involves enabling features through the feature flag.
"Both activities happen progressively, but at different times. We first ship the build with the feature flags turned off. We progressively roll out the build to users, wait for the build to be picked up and used by users, and reach certain penetration rates," explains Rinas.
Microsoft then monitors, using scorecards, key performance and usage metrics between the prior build and new build to ensure it hasn't introduced any bugs that causes crashes or break features.
"Once we have scorecards and confidence in the version, we can then begin to progressively enable our feature flags – making the new features available for users," says Rinas.
"For our larger, external customer-facing rings, this is a multiple step process that usually happens over a few days," he said.
Rinas explains that Microsoft rolls new features and version out gradually in tranches, and this approach considers the worldwide user pool and is not necessarily approached at an organization or tenant level.
"It gives us the best cross section of use cases, hardware configurations, software configurations, network topology, bandwidth availability, etc., to validate our changes and the user experience they provide – but this does mean that co-workers on the same build can see differences in their features," says Rinas.
"Rolling out feature flags by organization introduces the potential to bias our results with similar hardware, bandwidth, and usage patterns, so we focus on getting a cross section of users and usage patterns with our rollouts."
Rinas recommends admins can join the Teams Public Preview program as way to give a subset of users exposure to new features before everyone else.
As explained by ZDNet's Mary Jo Foley: Beta is for early adopters and IT pros who want to test features; Private Preview is for those who want more stability so they can validate; and Public Preview is for those who want to evaluate and build features before broad deployment.