Overcoming Teams governance and adoption challenges

[MUSIC PLAYING] Biggest tip about Teams is to make sure that you understand the technology before you deploy. And that doesn't mean just to understand the client technology because the Teams client is pretty simple. Most people can pick it up and use it. If they've ever used Facebook, for example, they're going to be very familiar with Teams-- or Whatsapp, or whatever, any of these type of conversational messaging applications. They will be very familiar with Teams. They probably won't use Teams well, but they'll be able to use Teams. What I mean about understanding Teams is to understand all the backend stuff. And that means that administrators had better start understanding all the administrative functionality that's available. One of the challenges there is that it means that you have to know a bit about Exchange, a bit about Azure Active Directory, a bit about SharePoint, a bit about Planner, a bit about application management. Some PowerShell will be handy. And by the way, if you knew how to program the Microsoft Graph, that would be really good as well. But seriously, if-- what that means is that there's a lot of stuff that you can do. But you have to un-- I'm not saying that you have to understand how to do it all, but you have to understand the possibilities and understand what technologies are important. The folks that just plunge into Teams and say, oh, let's get things going and just do without considering how to use policies intelligently, for example, to control team creation, the naming of teams, team expiration, and stuff like that, they're the ones that are going to be complaining in a year or so's time when they have to clean up the sprawl. There's definitely challenges around the administration experience because it feels like sprawl by default. It's like you've turned this thing on, and now users are using-- some things haven't changed in terms of there's a number of different SAS applications that they're using. Maybe they're using Twilio for project management. Maybe they're using Box or Dropbox for their files. And now there's some SharePoint, and you might integrate with a flow to be able to pull in some stuff from Twitter into their channels, so that idea of the team can actually be kind of unified in this team's experience. From an administration perspective-- whoa-- it's a bit of spaghetti in terms of where all these other experiences are, but it brings those experiences in for the user. But on the admin side, that unifying experience has not necessarily come together. If you put Teams out in the wild, and "in the wild" meaning you're just going to point and say, hey, we've got Teams. Everybody use teams. Teams is good. It solves cholera, by the way, if you actually use it right-- what you'll end up with in a few months is an ungoverned sprawl. Governance has been said semi-famously before as the balance between runaway usage and users running away. If you make Teams too hard for people to use, you put too many controls on who can set up a new team and what customizations they can do, that information is going to find other outlets. So you definitely want to make sure that you're training and empowering people to do things. The risk is that you have team sprawl. If it becomes very easy for people to set up lots of teams, people will set up lots of teams. So regardless of whether you're using tools, or patterns and templates, and coded solutions, or just training around this, people need to understand that they should look to see if a team already exists before they go to create a new one. It's much easier to have a deep arsenal of content on a smaller number of teams than it is to spread 10,000 team sites across a 1,000 person organization, each of which has two files and three conversations. That density is really important. So governing towards what I like to describe as a "square team site," medium width and medium depth is probably the best solution to solving your business challenges with Microsoft Teams. In the same way inside Teams, if you don't know what you're doing, you could inadvertently share information to people that you didn't know, or didn't want, or didn't consider could be able to get that information, including guest users, including outside the organization. So again, it comes down to compliance never works without planning, and execution of a clear plan will always deliver better compliance results. But the thing that's really missing is adoption change management. And it's also how the-- fundamentally, the role of the IT professional in assisting the deployment is-- it used to be the responsibility of like kind of the, you could say, the learning group or the university inside of the organization that's in charge of training would be responsible for educating the users on how to use the tools. But it's not just about flipping the lights on. It's actually about helping them understand the context. It's digital transformation. So a lot of this is helping them understand how their work has changed and how those interfaces have changed. The urgency of getting things right with Teams, I guess, is that I think it's better to get things right from the start rather than try and clean the mess up six-- or six months or 12 months after the mess has started. Retrofitting policies on top of Teams, it can be done, but it's going to be more difficult than if you got the policies right at the start and made sure that the policy supported the business goal of deploying Teams rather than just being done on a wing and a prayer. It's always easier to get things right from start. [MUSIC PLAYING]