I’m sure that the Microsoft Teams development group will smile at the protestations of Slack CEO Stewart Butterfield even if the Wall Street Journal thinks it “intensifies a war of words.” After all, Slack has its own problems to sort out given a sharp decline in its stock price following recent results. According to a recent Recode article, while Slack is loved by startups, customers that pay big bills prefer Teams.
But what the Teams development group should worry about is a growing feeling in some customers that it is an application that’s hard to manage. That’s not a reputation that Teams needs to have at this stage of its evolution.
Part of the reason why people consider Teams hard to manage is the chaotic sprawl of teams that can so easily accumulate inside deployments. If you’re not careful and don’t restrict the ability of users to create new teams, it’s easy to build up a mass of teams that exist with no good reason.
The root cause of this problem lies in an attitude within Microsoft surfaced in late 2014 when they launched Office 365 Groups. The laudable idea advanced by Microsoft was that Groups facilitated end users by making it easy for them to collaborate, but to make this possible it was necessary to remove any restrictions on group creation.
Those of us who lived through the public folder mess of the 1990s knew what would happen. We protested long and hard that Microsoft’s desire to enable collaboration would founder on the rocks of user ineptitude. If you allow people to create objects like groups, teams, or public folders they will. And they’ll create objects without thinking. The net result is a mess that administrators must clean up. We’re still doing that for public folders 23 years after their launch.
Microsoft compounded the problem by launching Office 365 Groups with no management tools. Or at least, management tools that weren’t up to the job. They then further exacerbated the issue by insisting that policies to control creation, naming, and expiration are premium Azure Active Directory features. A good case can be made that the expiration policy is a premium feature, especially now that it is becoming activity-based, but naming and creation?
To be fair, the issues around the extra cost to use group policies have decreased with the push for Office 365 tenants to adopt the Enterprise Security and Mobility Suite or move to Microsoft 365. But there are still many Office 365 tenants who won’t pay to use what might be considered basic management facilities.
The decision to base Teams on Office 365 Groups meant that the embedded problems carried forward when Microsoft launched Teams in preview in November 2016 and released to general availability within Office 365 in March 2017. Good arguments exist for Teams to use Groups, not least the ability to pick up important features like guest access, but the decision assisted the lingering management problems obvious in Groups to spread to chat-based collaboration.
Since 2017, the Teams development group have worked hard to build out a management framework based on a set of policies controllable through the Teams Admin Center and PowerShell (alas, only through the horrible Skype for Business Online PowerShell module). There’s lots of goodness here because policy-based management gives you control at an account level. However, an argument can be made that Teams has too many policies; more importantly, Microsoft’s habit of enabling new features by turning them on for everyone out-of-the-box means that administrators have lost control over the introduction of new functionality to their end users. The recent introduction of urgent messages is an example. Deciding that it’s a terrific idea to enable a policy to quiz end users with satisfaction surveys is another.
The settings needed to disable new features often turn up in the policies managed through the Teams Admin Center some time before features are visible to end users. As Figure 1 shows, the policy setting to control the creation of the much-awaited private channels feature is already available in the Teams policy. It could therefore be argued that tenant admins have the chance to block new functionality if they wish, but only if they remember to check the minutiae of policy settings every week.
Enabling new features by default certainly means that end users see features as soon as the software is upgraded. The downside is that help desk, documentation, and administrators are often blindsided when Teams starts to do something different.
What’s worrying here is that when you strip away the large Teams deployments reported by Microsoft, the average number of Teams users in the half-million organizations who have deployed the app is relatively small at around 27. It could be that this reflects the make-up of Office 365, which does support many small companies. It could also mean that many organizations are still making their mind up about Teams before launching a full deployment.
Remember that the size of the Office 365 base at some 200 million active users is much larger than the 13 million active users of Teams. There’s lots of growth inside Office 365 for Teams to exploit, far more than Slack can dream of. But before that growth explodes, perhaps the Teams development group could reflect on its management philosophy and improve the current situation. It wouldn’t hurt.