Re: Manage automatic creation of direct reports group

I respect what Microsoft is doing here with trying to drive adoption of Groups. I think direct reports is a great use case for Groups, so I get the idea behind it.

I have issues with how it is being implemented though, mainly the non dynamic nature. I've read the reasonings for it in this thread, but remain unconvinced. IT at most organizations already have enough things to maintain; now you're asking them to maintain group memberships or to teach end users to do it themselves.

Here's my main piece though; all of us on here stay updated with these changes. We will turn this on or off as needed. In reality, most admins never read their message center messages and won't see this. Instead, it will roll out for them next month, there will be a crazy period where they try to disable it while end users are confused. No one looks good in this scenario; not the IT team, not Microsoft, and certainly not Groups. Let's not tarnish the name of Groups this way.

We've been told many times (see almost every Ignite slide deck) that Microsoft will listen to our feedback. Well please listen now; hold this change back, at least for now. Not for the people on this thread, but for the ones who won't see this until it's too late.

Re: Manage automatic creation of direct reports group

I agree with many points mentioned in this thread. From the engagement in this thread, I believe that it is very clear that Microsoft a struck a nerve here with the community, possibly mostly admins and respective community managers in their organizations.

I hope they deduct that this feature is not release ready in its current state. When you start to auto populate stuff it gets very tricky, as there is not a "one size fits all" approach for every organization out there, therefore additional customization options are necessary for this work, which simply do not exist yet.

The current documentation and comment like "you can change the displayname later" are just highlighting the stuff that DOES work, but do not the stuff does still NOT work since the very inception of Office 365 Groups, like changing URLs, alias, ... the devil's always in the details ;)

Re: Manage automatic creation of direct reports group

Yikes what a nightmare:

Beginning in April 2017, managers who have 2-20 direct reports, do not already have a direct reports group, and have permissions to create groups in Outlook, will automatically have a private group created for them with their direct reports. The manager will be added as an owner, and the direct reports of the manager will be added as members by default. The group will be named "<Manager's Name>'s direct reports", but that can be edited.

And also all the governance with quitting, new members etc. If there's one roll out which should have been opt-in, it's this one. Are Microsoft trying to bump adoption numbers somehow with this plethora of auto creation of groups? I know we will inform our customers about this and make sure they do the needed Posh.

Re: Manage automatic creation of direct reports group

Perhaps I'm naive but I don't think this drive is motivated by raw adoption but a means to raise the visibility of Groups to a large customer base. We, in this community, are not representative of the sheer scale of Office 365 deployment. It's that scale that Microsoft's Planning Group is addressing here. That said, as always, this community had given great feedback to Microsoft that needs to be taken on board. What works for an SME is not going to work for a multinational corporate. Quite incidentally, and relatively quietly, the release of the Invite functionality for Groups seems much more useful for users in a larger environment. As a simple start, and stated here many times, is to start with Opt out as default. It is the right thing to do.

Re: Manage automatic creation of direct reports group

I agree. I'd really like to have a master switch in our tenant where I can set it so new features like this are off by default. We're a large organization and constantly turning things off is tiresome. We need to control the deployment to our organization -- smoother roll outs will not only make us look better but also Microsoft as well!

Re: Manage automatic creation of direct reports group

After thinking about this plan for several days, I conclude that it is flawed and will cause more bother than it is worth. I confirmed my feeling that few companies have the necessary accuracy in AAD to make this worthwhile by asking Cogmotive to run a query against their dataset of Office 365 mailboxes. Without compromising user confidentially in any way, they discovered that only 45% of the mailboxes they record for reporting purposes have the necessary ManagedBy property in place. This is a plan that works for companies that pay attention to AAD, but not for others.

I also have huge doubt about the way that Microsoft is using customer data to generate new objects for the GAL. That seems dubious under EU data protection guidelines.

In any case, here's the article:

Microsoft plans to auto-generate Office 365 Groups for managers to enable them to collaborate better with employees. Sounds good, until you realize that the reporting relationships stored in Azure Active Directory drive the process. And we all know how reliable that information really is.

Re: Manage automatic creation of direct reports group

Very well put, and agree with your findings.

Our "ManagedBy" is 100% (integrated AD with our HR system, changes update in AD every 3 hours, and sync to AAD every 30 minutes), however I received an email from a Microsoft PM that stated our organization didnt qualify for auto-creation because:

From email:

"Before creating any groups in the organization we have special logic that verifies whether an O365 Group has been created with the manager and reports already or not...a Group will only be auto created when the organizational structure is set up for the company, and it appears that we don’t have the proper information to auto create these groups in <my company>".

Re: Manage automatic creation of direct reports group

Unrelated to the main topic, but equally important to many of us. @Jeff Medford the way replies and threading work in here is making very active posts like this very difficult to follow. I'm left scrolling through the entire thing to find the new replies, and other than the time they were posted it is very hard to pick them out from the crowd. Maybe a known thing you're working on, but wanted to give the feedback and a real life example.

Re: Manage automatic creation of direct reports group

Chris,

2. Refers to that fact that by default only group owners and members of a private group can even see the content, making it difficult to judge if people are using them. You can add yourself as an owner but it takes time to take effect. No part of a computer system should be locked out to the people managing it. Having them not searchable and unrecoverable only adds to them problem.

5. Refers to the fact that Microsoft are pushing groups all the time time but the UI is disjointed to the users. How does someone navigate from a group to a central intranet site etc?

Re: Manage automatic creation of direct reports group

I would certainly prefer it to be dynamic if we were going to leave it turned on, but I can understand why it isn't and probably never will be from a Microsoft level. Office 365 is what now, over 90 million users or something? Imagine the overhead of a dynamic Groups membership process running at a high enough frequency to not cause gaps for that amount of people.

Perhaps a good opportunity for some documentation and guidance around the requirements from a license perspective, and the actual steps for turning on dynamic membership for this scenario using Azure AD features and what not. Give people a way to convert this into something valuable if they don't agree with the base functionality.

This whole thing may have been a bit heavy handed, but this is only going to keep happening in various forms. We all signed up for stuff like this when we embraced Office 365. I've learned to go with the flow and keep my ear to the ground, where in the past I didn't have to pay much attention because no one could impact my environment but me. That is no longer true.

Most definitely some learning to be had here for the Groups team in the future.

Re: Manage automatic creation of direct reports group

@Christophe Fiessinger can you confirm my thinking on something here... when it states "automatic group creation"...we are talking about an Office 365 Group (I've seen this stated as "connected group"). So this isn't just a Group in Outlook (a distribution list on steriods)? This is a fully fledged security group, distribution list, plus you'll get a OneDrive for Business folder, SharePoint site, Yammer group, Planner plan etc. etc. provisioned as well? This seems like a lot of moving parts that may not get used and sit stale and most likely be innaccurate membership.

Obviously this isn't that big of a concern I think. At hyperfish we're seeing that most organizations don't have the manager field populated for users, around 40% of users we've analyzed do. We can clearly help with completing and ensuring up-to-date manager fields.

Re: Manage automatic creation of direct reports group

To be fair to the original question:

1. Microsoft originally presented the Files component of Office 365 Groups as an extension of OneDrive for Business. It's only relatively recently that the emphasis moved to SharePoint (where the files always were, even if the labeling indicated otherwise).

2. Microsoft makes a very big thing about the ability of Office 365 Groups to replace email distribution groups. While I agree that the two objects are not close to be the same, you do make lots of noise about being able to use Office 365 Groups in the same manner as email distribution groups, so I understand where the confusion arises. And email-enabled security groups function in some part like the identity part of Office 365 Groups, so again it's easy to see where confusion might come from.

Re: Manage automatic creation of direct reports group

Not to name drop or anything, but I replied to Jeff Teper's recent tweet about some new, fun stuff coming to SharePoint and OneDrive with a comment referring to how badly this auto-creation of Direct Reports groups is. He kindly replied and it is interesting but begs a question and an opinion:

Re: Manage automatic creation of direct reports group

Can you say something about how the system goes about to detect if a Group is already in place for a manger and the direct reports? If I have existing O365 Groups set up, what parameters does it look at to avoid creating a duplicate ones?

Re: Manage automatic creation of direct reports group

Yeah we will be turning this off as well, I can see it creating more headaches than helping. We allow our users to create groups when needed, but auto creation of groups is a no go. This really should have been an opt in, not an opt out rollout.

Re: Manage automatic creation of direct reports group

David Rosenthal wrote:

We all signed up for stuff like this when we embraced Office 365.

Not really. We signed up for a service that grows and evolves, but we didn't sign up for Microsoft to make changes to our data (and throwing a bunch of objects into our GAL automatically is a change to our data).

Sure, we signed up so that things like Groups, Planner, or Teams get added to the service whether we asked for them or not, and it's acceptable to just go with the flow when admin portals change, PS modules get replaced, intelligent editor features get added to Word, etc.

But we didn't sign up for Microsoft to automatically create everybody a personal Planner plan, or ever team a Team, or inject an un-deletable Archive folder into every mailbox, or create every manager a Group as in this case.

Re: Manage automatic creation of direct reports group

Yep, I get it, and probably why Microsoft is stepping back on this. They overstepped a bit, we all barked, and now they are rethinking. That is considerably better than the "old" Microsoft I would say.

There is a positive hidden inside all this negative in this thread is all I'm saying.

Re: Manage automatic creation of direct reports group

As an FYI - I submitted the following user voice which I think really speaks to the core of this issue. I believe that tenant admins should have the ability to decide how they are going to consume Office 365 and whether or not features are enabled/disabled by default.

Re: Manage automatic creation of direct reports group

I like the general idea @Jared Matfess but I fear this would cause a significant slowdown in innovation and the introduction of new features and products within Office 365.

Default on solves two important items for Microsoft:

Usage data across a broad set of tenants with varying characteristics. Microsoft immediately gets a look at how many users are using the new thing, how many are maintaining their usage, how they are actually using it, where they are using it, where they are trying to use it but failing, when and where users are abandoning, etc. This lets them iterate quickly based on quantified data from a representative sample, instead of just the grumpy community members who shout the loudest.

Internal ROI when a larger status meeting rolls around and that team's VP asks "What did you build, how much impact did it have, and what did we learn as a team?" If the answers to impact and learning are soft and/or not representatitve, eventually that team is going to stop getting approval to build things rapidly and are going to end up with more process on them to go do "research" for much longer periods of time about what the customer wants. Not saying research is bad, but 3-6 months of delay even for smaller features is how you end up stagnating and getting disrupted by competitors.

Believe me though, I understand the concerns as my own org struggles with these types of things on occasion.

A compromise I think I could get behind would include two things:

Easier ways to turn off things via UI. Not every org has PowerShell gurus on call to rapidly make changes, especially smaller orgs. A UI switch should be made available for any new major tool or any feature that would introduce additional data into OUR tenant. Default would still be on, but only takes a few clicks to turn it off.

Forced communication to Global Admins. It should become a requirement to have valid contact methods stored in the system for someone to become Global Admin of a tenant. Business email, personal email, phone number, etc. Without these stored, verified, and periodically re-verified by Microsoft, Global Admin permissions will not be granted. This needs to become a push, not a pull like the message center. This stuff is far too important to rely on someone looking at some list of messages in one single spot that they may not spend that much time in on a daily basis. Shove it in their faces in any and all channels and make them acknowledge receipt and understanding. IMO, Global Admins who aren't aware of these big changes automatically showing up in their tenants should not be Global Admins in the first place.

This would allow things to be turned off easily if desired, but forces attention and understanding of new things coming. A switch to turn all new things off by default would just reinforce lazy Global Admin behavior and allow them to ignore new things completely and sit happily in their silo maintaining status quo.

Probably somewhat controversial, but if status quo is really what you are looking for or is required by some sort of ultra strict regulations, Office 365 may not be the best home for you. Those with these conditions should have stayed on-prem. People seem to forget that Office 365 is a SaaS offering that changes rapidly. This is not an IaaS lift and shift.

Re: Manage automatic creation of direct reports group

I don't think anyone minds innovation and new products showing up. What they do mind is when changes are introduced in a manner that compromises their data (like new objects in the GAL) without their say-so. An opt-in arrangement would have satisfied a lot of the issues here. Being able to control new features through the GUI is also a reasonable ask, but I fear that the speed of the cloud means that some things will just have to be managed through PowerShell, especially when they are one-off operations like turning a feature on or off.

As to the grumpy community members (I am a proud member of this band), one of the reasons for grumpiness is when you see the same mistake being made time after time. Microsoft did not socialize this change sufficiently well to understand the consequences of going ahead. I believe that this is understood. I just hope that we don't have to have another outburst of grumpiness when the same mistake is made again.

Re: Manage automatic creation of direct reports group

I do like your compromise of being able to enable/disable all features with the UI - that should honestly be a no-brainer.

What I'm struggling with is two of your comments:

1) Your comment on usage data (basically their telemetry). Sure they have the ability to measure but I find that this automated data collection method misses simple user experience issues such as not being able to quickly grab a URL for a Document within the Modern Library experience. The "grumpy community" folks still need to bang their drums to get folks on the product team engaged and responding to poor user experiences.

2) The comment about this not being lift & shift and organizations that have tough requirements should remain on-premises. Let's think about the current enterprise landscape - if you're a company of decent size, then you have dedicated Microsoft account representatives managing your relationship. Their incentives are 100% on pushing customer to consume cloud services - Azure & O365. Every month these sales staff are not only pushing cloud, but they're even helping to develop the business cases to help push their customers along. Nobody is talking about what it's really like being in the cloud and consuming Office 365 - the focus is all on the benefits and not some of the realities such as features getting pushed. There should also be some level of choice for automatically opting out of changes if you know that you have an organization that requires additional handholding. I would also add that Microsoft's new process of releasing "MVP" (minimally viable product) and then fixing a few weeks/months later creates even additional overhead of trying to support a premature product.

There's honestly Pro's & Con's for both keeping it the same vs changing, I just happen to be more in favor of giving paying customers choice vs forcing change.

Re: Manage automatic creation of direct reports group

The telemetry is getting pretty good these days. I think with modern ML techniques it should not be that hard to spot a "lost" user based on their previous and next actions. It is time to apply the "AI" that Satya champions so much.

That being said, I agree that the community aspect is important to point out the "Really?!?" type things, like the original issue that started this whole thread. Let's not forget that Microsoft did step back on this feature to re-evaluate after considerable pushback. Where I have issue with some of the "grumpy" community is the language used sometimes. Go back and read this thread and it feels like Microsoft is committing war crimes. "This is one of the worst ideas I've seen come out of Redmond for years, if not ever. And that's saying something." Is that really necessary? Do we think that whatever PM was in charge of this feature is going to want to engage with a community that says things like that about them? Taking a stance like that makes them engage because they have to, not because they want to.

There are people behind these features. Some more practiced than others, and some who need our guidance a lot more than others. I think we've all, myself included, spent too much time combating internet trolls and it has changed our default language for the worse.

As for the lift and shift stuff, I challenge my Microsoft account team pretty hard quite often. Too often I see people treat them with kid gloves because "They're Microsoft" but I certainly don't. I have small business ownership and sales in my background, and turning difficult clients into good relationships is part of the job description. No different for sales/account people at Microsoft. I think they actually dread emails from me because they know I'm not going to settle for sales and marketing fluff and they'll actually have to get me some answers or I'm going to go around them to the respective PG I'm interested in. I think these account teams are the last remnants of the Ballmer era whose time for change will come. The "selling seats" model needs to die IMO. It is time these people get incentives for selling the best solution that fits the business need as measured by adoption, engagement, and customer satisfaction. Do that well and the seats and revenue come automatically.

Re: Manage automatic creation of direct reports group

I didn't see anything in this forum that I thought was over-the-top commentary on this topic. If anything, it was measured compared to some of the expressions I saw elsewhere, including those shared privately with Microsoft. No one insulted anyone's mother or cast aspirations about the circumstances of their birth. No one said that the individuals behind this decision had brown smelly bovine emissions for brains. It was all in good taste. Healthy debate is fine as long as it stays within acceptable boundaries... and the Microsoft PMs that I have met have seldom been shy, retiring types who cannot accept criticism. The good ones (and I have met many over the last 25 years) take criticism of products as part of the ebb and flow of development.

I accept that decisions are taken in the best spirit possible. However, two things get in the way of some of the decisions that we have seen inside Office 365. First, (as in this case) an unreasonable assumption that Office 365 tenants use AAD in the same way that Microsoft does. We don't. Second, a rush to move people to use Office 365 Groups that is sometimes over the top.

Telemetry often guides decisions and it is very useful in terms of user features. But this is not a user feature. It's something that goes to the heart of organizational structure within companies and it affects the view that people have of that structure. The telemetry failed in terms of telling Microsoft how people use AAD and it cannot tell Microsoft how people use Office 365 for business purposes. The old adage that even the most skilled and experienced consultant only has 50% of the solution holds true here. The 50% controlled by Microsoft (the code and the ability to flight it to tenants) is perfectly good. The other 50%, which is the context in which companies run Office 365 to assist them in business operations, was lost. Understanding context is extraordinarily difficult, but that's the trick that turns ideas that are potentially good into ideas that are absolutely brilliant.

Re: Manage automatic creation of direct reports group

So our tenant organisational config says this is enabled although the number of mailboxes is way more than 50,000. I don't see any direct report groups created for any users so is it something that is coming or not working because we have too many users?

Re: Manage automatic creation of direct reports group

Greg Lamb wrote:

So our tenant organisational config says this is enabled although the number of mailboxes is way more than 50,000. I don't see any direct report groups created for any users so is it something that is coming or not working because we have too many users?

It's being rolled out to a very limited number of customers currently and not to any with more than 50,000 mailboxes.

Re: Manage automatic creation of direct reports group

I was really fortunate to have Christophe on the Hyperfish Podcast which was published today talking about this topic. Would highly recommend it for those interested in the discussion that happened in this thread.

Re: Manage automatic creation of direct reports group

I got around to listen to the interview you had with @Christophe Fiessinger and I do get the points about giving new managers a collaboration group to handle their team.

From a document management perspective however, having a group for the team where the owner changes if the manager is switched out makes more sense. This of course requires procedures to switch out owners/members when you change position.

So, I'd rather try to fix the procedure to automagically make sure people are members of a Group set in some org/project structure - instead of letting the manager be the boss. Which leads to: if you indeed has this in place, the auto-groups would never be provisioned in the first place :)

Ideally a new Group would be autoprovisioned based on the rules set in the support article, but the name/e-mail would not be tied to the manager by name, but to the manager by position/role (if possible at all). I think this actually might be the real issue. Then, if you switch out the manager, the old one onboards the new one in the existing group.