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.
Written by Liam Tung, Contributing Writer
Man smiling making video call.

Micorosft ships new versions of Teams to everyone, but then enables the features separately.

Image: Getty Images/iStockphoto

Microsoft has explained why not everyone on the same version of Teams – even in the same organization – gets the latest features at the same time. 

A new Microsoft blogpost could help IT admins explain to one user who's complaining why they can't see latest video and chat feature in Teams, when their colleague in the same organization can. 

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. 

SEE: Top 100+ tips for telecommuters and managers (free PDF) (TechRepublic)

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.

After internal testing, Microsoft releases a new build to the organizations with pre-release access to Teams features via its Technology Adoption Program (TAP). Customers need to sign an NDA to participate. Then the update gets released to the public. 

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. 

SEE: Windows 10 toolbar: Here's how Microsoft is adding news, weather and traffic

Microsoft announced changes to testing Teams features in December. Teams users can pick one of three channels as part of the new Insider program. In addition to Beta and Private Preview, it added a Public Preview channel to the program.

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. 

Editorial standards