The recently announced Office 365 feature that will automatically create Groups based on manager/reports relationships in Active Directory reignited the debate about new features being enabled by default. The discussion in the Microsoft Tech Community was robust, and outlined many flaws in the proposed feature. But regardless of the merits of that particular feature, the discussion brought up the point that defaulting new features to “enabled” (or opt-out) is the wrong approach for many customers.
The issue is a big enough concern that a Uservoice item has been opened to collect votes from the community.
Tenant administrators should have the ability to specify whether or not new features such as Teams, Sway, etc. are enabled by default within their tenants. Just like there’s the ability to set a tenant to receive First Release, Admins should be able to specify how changes are introduced to their environment. It’s great that there are PowerShell commands to turn features on/off but it would be much easier to either set these new features to be off by default, or enable Admins to enable when organizations are ready to absorb those changes. Functionality like Teams is absolutely fantastic, but without the right change management planning it becomes confusing for users. For Tenant Admins that either ignore announcements of new features, or are unavailable to turn them off when they become available – this is an appropriate solution to enable organizations to effectively manage how they are consuming Office 365.
As I wrote in my article on managing change in Office 365, changes can create a burden for support staff, especially front line staff who will be hit with a wave of new questions when something changes. For organizations that have strict controls around change management, being able to control the deployment of new features is essential. I’ve heard from customers who use the ITIL framework, and they say that Office 365 has increased their costs because every single change needs to be managed in that framework. For them, being able to disable new features like Teams, or Focused Inbox, or Groups is essential. And while most new features can be disabled on a per-tenant or per-user basis so that the roll out can be managed through their change control processes, others such as the change in email sending behavior for Groups have no opt-out mechanism and are basically enforced on all customers. The ITIL organization has no choice but to adapt to those enforced changes.
The burden on IT departments is one side of the issue. There is also the impact that adding more complexity and variance to Office 365 will create. Taking the example of the email sending behavior for Groups, if that was presented as an option, that means more code is required to deal with Groups that have the option set one way or the other. The more code and complexity involved, the more development, testing and support costs are incurred, and the more risks there are of bugs surfacing. A service as large and complex as Office 365 is only possible when things are consistent and predictable across the entire environment.
We also need to consider whether innovation in Office 365 would slow down if adoption rates plummeted due to features being disabled by default. It should come as no surprise that one of the reasons new features are enabled by default is so that they are adopted faster by customers. For customers with minimal IT support, being able to use Teams, or StaffHub, or Bookings without needing an IT person to switch it on for you first is a positive thing. If features were always opt-in, those customers would simply miss out. And it’s entirely feasible that some IT consultants doing one-off projects to migrate customers to Office 365 would flip the switch to disable new features, with the justification that it’s for the good of the customer, and then walk away. I have no special knowledge of Microsoft’s internal decision making process around development of new features, but I assume that it would be difficult to justify investment in features if adoption is going to be limited.
This is an issue with no clear answer. If the option to disable all new features by default were made available, where do you draw the line on what constitutes a feature vs a change? If you call Teams a feature, and the Groups sending behavior a change, customers will still be caught out by unexpected changes if they’re not paying attention. That brings us back to what is perhaps the core of the issue – tenant admins who “either ignore announcements of new features, or are unavailable to turn them off when they become available.” Should we be advocating a change that caters to admins who are ignoring announcements? Or should the onus be on them to get with the program and deal with the reality of cloud services?
Clearly some folks are unhappy with the current situation, hence the Uservoice suggestion above. What do you think? Should there be an option to opt-out of all new features by default? Would you use that option for your own Office 365 deployments?
I think we are missing the forest for the trees, here. If you don’t want new features forced onto you (and I am one of those people who don’t want it!), then purchasing and using Office 365 is the wrong call. Regress to a standard version of Office, and simply stop purchasing upgrades. Why we continue to give Microsoft money for the sole purpose of downgrading a product with every new release is absolutely wild. I can’t recall a single “must have” feature delivered with office within the last decade.
Sure, teams is nice. But Skype worked just fine before that, and we didn’t need to replace it.
Microsoft Word is so feature-rich that for most people the best “enhancement” is to start removing confusing features.
And don’t get me started about the stupid UI-breaking behavior of the widgets stuffed into the title bar simply because Microsoft can do it.
There are other considerations to these unannounced, “on-by-default” changes a well. If something is enabled by default, there compliance and security implications to consider. It’s not about the end user until it reaches the point of deployment. We find that most customers can vet new features through the use of the “Targeted Deployment” model described in the documentation below. This, combined with notification of changes surfaced via the Message Center should be enough to stay apprised of and manage these fast-paced changes. Interested to know your thoughts, though!
https://docs.microsoft.com/en-us/office365/admin/manage/release-options-in-office-365?view=o365-worldwide.
I think this perspective is far too IT-centric. You discuss the burden on support staff, orgs and their Change Management/ITIL challenges,etc. Then you consider the cost/pain/slowdown of innovation to Microsoft of baking in variability in Office 365. Lastly, you echo the false belief that changing MS release behavior is for the benefit of Tenant Admins “that either ignore announcements…or are unavailable to turn them off”. Where are the users in all this?
Impact to the users should be the first consideration, beyond just thinking that a feature or change would be really handy to users, if only they knew it. Consider a typical organization (with typical imperfect/inaccurate AD data content), and typical managers who are managing their direct reports via a number of communication tools- email, phone, IM chat, face to face meetings, and policy documents. Could a Feature like MS Teams help consolidate all those tools into a single location? Sure, that’d be great. But, first and foremost in these users’ minds every day is “my office is in the same location, my stuff is in the same location, I work with my staff in the same way”.
But if all of a sudden, these managers are presented (via email notice) with this tool, in which the very first thing they would have to do is clean up the membership, then wonder what about all the old emails, documents, meeting notes, etc., how do they get those into this shiny new location? The managers will either clamor for help or ignore the tool. And all the users won’t care about the burden to support staff or the disruption to these wonderful IT CM/ITIL processes, and certainly won’t care that MS gets to have a unified feature set enabled throughout Office 365. And blame IT that “they’ve rolled out this new thing again that I don’t know how to deal with”.
The solution is really fairly simple, and is more or less already available in Office 365: the First Release functionality. Perhaps they should change the name to Automated Release.
Here’s the advantages:
1. It could be enabled by default for new tenants; if structured IT orgs want to disable it or enable for limited test/pilot groups, they can, in one setting. Smaller orgs without structured (or any) IT can leave it as is. **This solves MS’ issues with consistent environment and innovation adoption.**
2. As new features/changes come out, these would honor the Automated Release settings. And, IT departments would be able to test/pilot/demo the changes, and orient their support staff, then roll out the changes to the org. **Solves IT issues with CM and ITIL processes, support burdens.
3. The users have a consistent environment to work in, where changes are announced, explained/understood, and then released, unless they have signed up to be a part of the pilot groups, or unless the company is agile enough to not worry about changes taking place with minimal notice/understanding.
Ultimately, #3 is the key consideration.