Two philosophies for deploying Microsoft Teams in an organizationAlex Fields
IT admins throughout the world subscribe to one of two worldviews today:
- Control mindset: IT’s job is to control and restrict, and of course, to protect the clueless users from all of those scary threats out there in the world today (including themselves)
- Empower mindset: IT’s job is to educate and empower the end-user, and to give them a good experience, all while taking steps to ensure that their privacy and safety is as protected as it can be, yet without causing them too much friction in the process
I subscribe to the latter view. And I often have to butt heads with IT folks over this fundamental break in ideology. Usually this happens when well-meaning people are coming from a legacy or hybrid architecture, and have not yet embraced the concepts of the modern network, or realized what it means for them and their jobs.
In particular, Microsoft Teams is one application that really irks these “legacy admin” types. They hate that users can just go freely create Teams which then provisions multiple objects within “their” services. They hate that people can manage permissions and data outside of IT. They hate that external sharing is so open and commonplace. They hate that third-party tools can so easily and seamlessly be folded into one app and thereby become normalized within an organization’s workflow.
Do you know what all of these complaints have in common? They are all admin-centric concerns, not user-centric ones. In fact, when the user’s capabilities to do any of the above is hindered in any way, the result is going to be user frustration and proliferation of Shadow IT throughout the organization.
But, just to articulate this point further, let me describe some of the admin-related concerns and how an admin who falls into the “legacy” or “control” camp would implement Teams.
Control mindset (legacy admin personality type)
The first thing that the legacy admin will do in this case, is to begin by limiting privileges. First, they will take away rights to create teams. This can be accomplished by restricting who has rights to create Office 365 Groups (which teams depend on for their existence). They will either keep that control inside of IT, or in some cases, they may also nominate department heads or power users who they trust.
This step is done for two reasons. First, because they can’t stand the idea of so many different groups and other objects being created freely in their pristine environment. They see nothing but clutter and hardships in their future for managing a sprawling mess of groups, SharePoint sites and other perceived “debris.” The other reason is, imposing the limitation keeps the provisioning process dependent on IT.
Second, IT will decide the structure, or at least be heavily involved with deciding the structure of the “teams” within the organization. This structure is usually following some kind of standard departmental / hierarchical (think org-chart) design.
The structure is imposed for two reasons, the first of which is to contain the work content. The belief is that work generally only happens (or should happen) in these silos, and that the content within the silos needs to be tightly controlled using an access control list, like you would have with a file server in the past. Permissions have historically followed these groups and the departmental “drives” or shares that are out on the network. Hence it must be the same in modern apps like Teams.
The third thing that a control-minded admin might do is limit the ability to communicate with or invite external users, or at least keep this pretty tightly controlled. You wouldn’t want certain data sets to become accidentally exposed to the public if an external user were invited into a Team for instance.
Last, they will want to disable the use, wherever possible, of third-party apps, since they are only responsible, and only want to remain responsible, for supporting the “known” universe of Office 365.
Empower mindset (modern admin personality type)
Let’s see how the modern admin handles all of these issues differently, yet empowers the end-user in the process.
First, they will absolutely not take away rights to create teams.
Sure, they might help their people understand the concepts behind teams and channels in the beginning to get users feeling comfortable (e.g. lunch-n-learn format). But after those initial introductions, it is up to the end-users–they can self-organize teams and projects, and work with who they want to work with and when.
Nor will the modern admin control the number or structure of teams.
Attempting to direct and control the structure of teams is useless, for the same reason that any central planning in government and economics tends to fail: formal structures and conformity to pre-defined hierarchies stifle creativity and keep walls up between people of disparate groups. Also, users who feel frustrated by not having the ability to work more freely and collaborate how and with whom they choose aren’t going to comply with the corporate policy anyway–they are going to get around IT using something outside of corporate control, like Slack for example.
For some of the same reasons, restricting apps and sharing can be a tricky business. We can’t predict all of the creative energy or possible inputs for certain ad-hoc projects, ideas or inspirations. Some people may have content in other work groups that they belong to, or in outside accounts that they have, and if sharing that repository to the rest of their teammates is useful, then why make it difficult for them?
Instead, we will use education and all of the modern tools within Microsoft 365 to properly shepherd and manage the open environment. For instance, rather than worry about clutter accumulating, the modern admin can simply implement a retention policy against Teams and libraries which have not been modified in over 12 or 18 months (as an example).
When it comes to sharing data in other locations outside of Office 365, this can be solved in various ways via a number of technologies that we already have available to us in Microsoft 365.
We will start with data classification and labeling. This gives users a quick way to protect their most sensitive data from unintentional prying eyes. Now even if external guests are invited into a Team where sensitive documents are being shared internally, those outside eyes will not be able to view the contents, since the documents are marked as confidential. Users can also use the Azure Information Protection client to encrypt both documents and emails that are being sent to external users.
Taking it further, Microsoft Cloud App Security can help us to identify all of the “Shadow IT” apps out there, and to start bringing them under management if we wanted to. Now the modern admin can apply the same policies and protections to those outside apps, as we have with the Microsoft ones that are already sponsored by IT. At that point, it is even possible to create conditional access policies against these applications. Sweet!
Don’t panic. The examples above serve to show that you really do not have to give up anything in terms of manageability or security as an IT admin, and yet your users will have much more freedom to move about the environment, creating relationships and sharing content however they please. The open model of sharing implemented by the modern admin allows any user in any department to rise up and have a voice, and a platform, from which to self-organize and share ideas.
On the other hand, if you try to limit the ability for others to create impact and have a voice in your organization, you’re just going to lose visibility and control–because everyone wants the open “empower” model anyway, and there are easy third party alternatives available freely on the internet. Worse yet, by implementing a “control” model, you might be creating an environment where people don’t want to work.
Wouldn’t you rather be someplace where your voice is easy to project, and you can be heard by others? Where you are free to share your work out loud, however you choose to do it?
I rest my case.