Corporate Name Calling & Collateral Damage
Anyone who knows me knows that I am a huge proponent of the ‘vCommunity’. Since I upped my game at VMWorld 2015, I have been addicted to not just consuming community resources, but also giving back. I decided that I wanted to get involved and help out. Towards the end of 2015, my local VMUG group was not looking for any sort of additional leadership help, so I did the next best thing – I started my own user group.
Even though the focus of my user group is different (but a lot of overlap with VMware), I found myself dealing with problems that I had heard a lot of VMUG leaders mention. Things like finding good sponsors, ideal locations, and, hardest of all, getting users to participate. I’ve been fortunate thus far that I’ve been able to fulfill these areas. In no small part, my connections from the vCommunity have helped as well.
The point that I am getting at is that running a user group is a labour of love. It isn’t something that we do to get rich (it is usually a volunteer position). We do it because we want to help people. But like almost everything else in the world, corporate politics can get involved.
Just got kicked out as #VMUG leader because I'm employed by #Nutanix. Thank you, #VMware. Are you planning to strip me of #vExpert as well?
— Anton Zhbankov (@antonvirtual) December 29, 2016
A few days ago, I was shocked to see that tweet come across my timeline. I figured that there must have been more to it than meets the eye, but after going through the thread, it appeared that VMUG sacked a 7-year leader, who is also an 8-time vExpert. Very odd indeed. Maybe this was just a one-off … But then I saw this earlier tonight:
Bummed, Just told I would not be allowed to "personally" be involved as a VMUG leader based on who I work for. VMUG used to be about users.
— Nathan Cox (@jncox) January 6, 2017
Another leader being kicked out of their leadership role.
WHAT IS GOING ON?
I have the good fortune of knowing quite a few VMUG leaders. Off of the top of my head, I can probably think of dozen or so. Over the last few months, I have been hearing grumblings about VMUGs approach as of late. In some cases, this came from casual conversations, while in other cases it came via some form of online social media. The overall trend that I noticed though is that there was a discomfort between a lot of local VMUGs and VMUG (the organization).
The common theme that I picked up on is that VMUG is getting a lot stricter with how things are run. Now, don’t get me wrong, I am a big fan of rules. Rules let us know what we can and can’t do, but they also have to be respected by both sides. It isn’t fair to agree to one set and then come in and drastically change everything up out of the blue.
The other big point is that one size does not always fit all. What may work for a VMUG in the Mid-Western US isn’t necessarily something that will work in Eastern Canada. Each VMUG has their own style, that’s what makes them unique. If you start dictating how they are run, and more importantly, what individuals are allowed to run them, you loose all of that. It turns the event into a generic, cookie cutter event. This isn’t devops.
WHY AM I WRITING THIS?
That’s a good question. VMUGs and the communities that go with it have been huge for me. I have not only learned so much from attending, but I have made new friends and pushed myself further and harder. So, why am I writing this? I think it is because ultimately I care. I care about the concept of VMUG; I care about the attendees; I care about the leaders who pour their heart, soul, and personal time and energy into these things.
I am not a fan of slander between companies. Personally, it leaves a bad taste in my mouth. With that being said, if Company A has a spat with Company B, you don’t punish Company B’s employees by not letting them volunteer for your community event. You may not let Company B speak at your event. And heck, if an employee from Company B who is running the event gets out of line, you deal with it. What you don’t do, however, is punish people for something that hasn’t happened.
Do I expect VMUG to reverse this apparent decision? Not likely. But I do hope that those who have been affected know that their plight isn’t just another tweet in my timeline.
It has always been the policy for VMUG to not have vendor side leaders. Those folks, myself included at one point, were allowed to be on a steering committee.
My guess. Increase in enforcement by new people at HQ who do not know who to trust OR there have been some vendors complaining. Can’t say whether they are doing so with justification or not.
Either way, it will have a negative impact on the organization as a whole. User Groups require passionate people as you say. Users deserve some insulation from corporate objectives. Always a difficult balance.
Not quite correct, Josh. It used to be the case, but there got to be so much “brain drain” in a handful of larger chapters (mine was a practical revolving door for a while) that the policy was modified to allow vendor/partner leaders by requiring 1+ customer leaders for every non-customer leader. It’s been that way for 5 years, or I’d have had to step down when I went to a VAR from a customer.
Thanks for the insights, Josh!
I think you bring up a good point that this seems to be an old rule, just un-enforced. I think the qualm I (and others) have with it is that it is now being enforced, but just for one vendor specifically.
I think a better approach would be to fess up to not enforcing this rule in the past, grandfather in current leaders, start enforcing it, and do regular performance / peer reviews.
I would be just as upset about this if it were any other vendor.
Interesting. Employment with what vendors disqualifies? Those that compete in the hypervisor space (Microsoft, Oracle, Nutanix, Citrix, …)?
Monitoring software vendors?
Consultants?
Hardware vendors?
DellEMC?
Seems a better idea to guide activity per policy & procedure. Rather than police participation and service roles.
It’s not just for one vendor. As Josh says, the policy has been around for a while. Did the VMUG leaders in question tell VMUG that they worked for a vendor?
As I held other volunteer roles at the same time as being a VMUG leader, I was aware of potential conflicts of interest when I elected to change employer 15 months ago so I told them all. Many voluntary organisations ask for and need transparency from volunteers and I have no problem with it. At the time, I informed VMUG of the change in my circumstances and was told that I would no longer be able to continue to participate in the steering committee of the VMUG chapter that I helped to establish. Whilst I would have liked to continue, I accepted it and stood down.
Shortly after, another VMUG leader I know told me that they thought that the rule wasn’t always strictly enforced, but unless a leader tells VMUG who they work for, how would they know?
Being a VMUG leader was a great privilege but you don’t have to be on the steering committee of a chapter to volunteer or help.
Just read over the guidelines for leaders. Guess it’s changed since I signed on.
Yes, I have. More than that, VMware had no problem with me as EMC employee for 3.5 years out of 7 I ran VMUG.
Starting early Dec I had discussions with VMUG management on changing 1 leader to 2/1 board of directors, where 2 is customer. But then Brad Tompkins called me via skype and specifically told me that Nutanix is special case. No sponsorship for VMUG, no sessions, no being co-leader. Thank you for your service, now GTFO. But they will allow me to visit VMUGs and be a listener. What a generous gesture!
Matt, I think there are a couple of different things at play now, and Nutanix employees that are involved in VMUG find themselves at the intersection of them.
As I mentioned in reply to Josh, there was a long-standing rule that only customers were allowed to be on the leadership team (distinct from a steering committee in that one advises while the other “decides” [and spends money]). That rule was amended to require a) the “top” leader (chief, president, whatever) must be a customer and b) 1 or more customer leaders for each non-customer leader. When the ratio rule was violated, a non-customer was supposed to step down; when the “chief” rule was violated, a replacement from the customer community was sought.
Sometimes, however, the time required to find a replacement for the leader dragged on; not because the leader wasn’t willing to give up the reigns, but because no one else was willing to step up and take his/her place.
The second thing is that VMUG has long banned “industry competitor” companies from participating in events as sponsors; by extension, their employees have been forbidden to hold roles at either the leader or steering committee level. You’ve never seen Microsoft, Citrix or Oracle in the sponsor list for VMUG, so when the Board decided to move Nutanix from “ecosystem partner” status to “industry competitor” status, it would naturally impact every employee involved in VMUG. Among other things, I suspect this decision was fueled by the apparent vigor with which Nutanix markets the alternative hypervisor…and the threat to VMware that it seems to represent. It will be interesting to see if a sweet little company that also has a competing hypervisor/HCI platform (Scale Computing)—but explicitly targets the “S” and lower end of “M” in SMB— will be branded in the same fashion, or left alone because they’re not perceived as a threat.
Finally, we have long-standing policies that have been poorly communicated or lax in enforcement being policed in a wide sweep at the beginning of the new year. Part of the big “hue and cry” may be the sheer number of Nutanix employees involved in VMUG; they’re all being swept out not just because of possible violations of the non-customer rules, but because of VMUG’s desire to remove perceived competitors from influencing chapter operations.
And this isn’t specifically targeting “just Nutanix.” My own chapter was under fire before the end of last year because VMUG HQ thought our leader ratio was in violation. Rather than take to Twitter and complain, we worked with HQ to make sure they had our profiles correct. It turns out that one of the companies represented on our leader team is flagged in a database at VMware HQ as a reseller; once we were able to explain that a) the leader in question had nothing to do with customer-facing operations and b) the “reseller” role was barely 1% of the business ops (and is one of the largest VMware *customers* in the US), our mix was certified again as compliant.
Now: Could VMUG HQ have been more transparent about the decision to relabel Nutanix? Yes.
Could VMUG HQ have given more lead time to the affected chapters so they could deal with the repercussions? Yes.
Is this the beginning of the slide down the “slippery slope” that takes away the apparent “independence” of VMUG as a community voice and instead being perceived as a mouthpiece for VMware Marketing? You bet.
Given that it appears that Turbonomic has also been “given notice” that it could find itself rebranded as a competitor—not of the hypervisor, but of the monitoring & management products in VMware’s portfolio—every other “ecosystem partner” that provides a product/service that can be considered “competing” will be wary of continuing to support VMUG.
And as at least one loud voice in the vendor community has expressed, partner sponsorship support is the fuel that the VMUG engine requires to run.
This is not a good sign of things to come.
Thanks for the awesome reply Jim!
I completely get what VMUG / VMware is doing. I don’t necessarily disagree with it, but I (and I think a lot of others) don’t like the execution.
Definitely a hot topic, and I really appreciate that you outlined your experiences.
Pingback: 2016, a year of industry friendliness | IT Should Just Work
Well, I agree that most people involved with user groups do it because they want to be involved and they are interested in the subject that forms the basis of the group. Some user groups are initially formed around a particular vendor’s technology like VMware or an open source software project that has attracted lots of interest like Linux. Informal groups with just enough structure are usually the most fun but it always takes the commitment of a core group of people to keep it alive.
For three years I was the nominal leader of the Boston chapter of the Novell-inspired CNE Professional Association. CNEs were people who had achieved a particular certification from Novell. Over time, the group evolved a national leadership team which decided to cultivate a larger membership by reaching out to a broader spectrum of network technology professionals and not just those working with Novell products. The CNEPA went national and changed its name to the Network Professional Association or NPA.
Things did not go that well for the NPA when Novell pulled back on some of the financing and the salaries being paid to the national leadership team became problematic. The energy and enthusiasm that formed the initial CNEPA groups was lost. The NPA still exists, but it seems to have faded into relative obscurity.
My advice is keep it local, keep it fun and as informal as possible with just enough structure to maintain its purpose and integrity. Most importantly, be welcoming to everyone interested in what you are excited about because over time people will “burn out” in the group’s leadership roles. New members should always be encouraged to step up and consider becoming more active in the group. Eventually, the group may fall apart, but nothing lasts forever.
User Groups (independent or otherwise) only thrive and survive because of the people involved and the passion they bring to them. I’ve always heard great things about VMUG’s and to me its strength has always been the greater leaders and committee supporters. I run an independent User Group and we have passionate people involved that are not customers but can put the user group first and leave their employee’s needs at the front door. These people make great additions to the community and its a shame for those people that they’re no longer welcome in helping organise VMUG’s.