Going Outside

Well, if you've been a regular reader of this blog, you'll probably remember one of my "Big Strategies" around all of this, e.g. let's get good at social media behaviors and skills "behind the firewall", and then -- when we venture outside the firewall -- we'll know what the hell we're doing out there.

That time is upon us, and some of the debates around this are interesting.

But, given our internal experience, I think we're well advantaged about how to think about the problem.

Going Outside

When people think about "enterprise 2.0", or social media, or communities, or whatever -- they tend to envision a world where they're talking outside the firewall.

Maybe it's customer communities, or partner communities, or influencer communities -- take take your pick, it doesn't matter -- but most people realize that there's incredible value in taking the conversation outside the confines of your four walls.

We've done well with corporate blogging so far (more to do), but we all are lusting after the vision of broad, engaging communities of people who care about the same things we do.

Marketing -- The Good And The Bad

The good news is that marketing people usually have these dreams first. 

Using whatever language and justifications that make sense to them, they paint a picture of being able to reach customers/partners/influencers more cost-effectively, being able to engage them in productive conversations, and so on.  And, they're right.

But, at the same time, they're marketing people, so they tend to taint their visions with traditional marketing concerns. (To be fair, I am a marketing person as well ...) 

How do we make sure that everything has a consistent look and feel? 
How do we make sure we're "on message"? 
How can we present our products and services in a favorable light? 
Can we generate leads from community members? 
How do we handle competitors and dissenters?

And so on ...

Based on what I've seen with other companies, it's very possible for these sorts of concerns to hamper any sort of productive community formation.

And, as we get into this, our priorities and visualization of what this might all look like is changing -- and for the good, I think.

Micro-communities vs. Macro-communities

Originally when we started on this journey, we were thinking in terms of perhaps a small number (3 or 4) relatively large external communities.  Each would have a consistent look and feel, each would have a neat and tidy organization, and so on.

Turns out that's not ideal -- maybe it's our Web 1.0 thinking influencing our Web 2.0 problems.

As we get into this, the picture that's emerging is very different -- we're seeing a large number of much smaller communities, each with their own identity, brand, flavor, etc.  Sure, we can use the same tools and platforms to create each; but it's clear that they're not going to want to co-habitate anytime soon.

At EMC, let's take our Channel Partners who resell our products and services.  Six months ago, I would have suggested a single community for all Channel Partners.  I would have been wrong.

What happened?  Well, our Latin America channel partner organization came along first and strongest; they didn't want to wait for anyone else.  The EMEA and North America guys had different ideas about the nature and the timing of their communities and; arguably; a partner in Brazil has very little in common with a partner in Detroit.

Of course, there are different horizontal categories of channel partners as well; distributors vs. resellers vs. system integrators; each with different concerns. 

Communities come together around passionate interests, which leads to a bottoms-up formation model, not a top-down one like we see with web sites.  Any attempt to pre-ordain their formation, or alignment, etc. will probably be an exercise in futility.

Another example is the fallacy I call "customer communities".

EMC has a very large and diverse IT offering.  I suppose that means that we also will have a very large and diverse community offering.

Sure, we have people in our customer communities that are interested in different products -- how to use them, and so on -- but there's more.  Some like to engage in industry-specific topics, e.g. finance, retail, aerospace, etc.  Others are more interested in the processes that run IT than the product technologies. 

Once again, we'll probably see a bottoms-up formation of many, many communities -- based on community participant interests, and not some pre-engineered community map.

Controlling The Chaos

That being said, there's two powerful arguments against letting everyone do their own thing.  One is cost (naturally), the other is confusion. 

When a passionate potential external community builder comes my way, and they start insisting on having "their" own platform tools that are different from everything else, I force them to take the point of view of someone outside our company who might want to participate in 10 or 20 different communities. 

Now, of course it's hard for them to envision why anyone might want to be a member of more than one community, but that's often the case in the real world.  Not to mention the fact that standing up individual environments, one for each micro-community, is very expensive.

Common Standards

So, the question remains -- how do we let these individual communities grow and flourish, yet retain a sense of consistency and coherency?  We've identified a couple of non-negotiable sticking points.

First, we want a common authentication mechanism for all external communities.  You should be able to register with us once, and be able to use that ID to access most any external community.  Now, I'm sure it's the case that we'll encounter a few situations where it makes sense to have an additional level of "gating", but we'll try and keep it to a minimum.

Second, we want everyone using the same software.  I can live with multiple instances; I can't live with distinct user experiences.  So we're going to be very firm on what package (and hosting provider) everyone has to use.  As a user, I should be able to navigate from community to community in a relatively seamless manner.

Third, we're going to have to add a layer of community navigation on top of all of this.  At a minimum, a web page that lists all the active communities, profiles who might be interested, and so on.

Combine these three attributes, and we'll probably have the best of all worlds, in terms of cost and consistency.

Getting The Balance Right

Overplay the centralized consistency and coherence card, and you'll hamper community formation.  On the other hand, letting everyone do their own thing will blow you up from a cost and consistency standpoint.

We're going to try and get the balance right between the two.  We want individual community builders to try their hand at creating vibrant gatherings around shared passions.  And we want all of our communities, taken together, to look reasonably consistent in terms of navigation and user experience.

We won't know for another six months if our thinking was right about this, but -- like everything else with this journey -- we'll see.

Comments

[John Prichard]

First of all inside a big company like yours (or mine), gets too focused around big customer classes/groups, products, designs or services. By opening up these narrow focuses to big conversations you get the full benefits of many lessons learned and specifically developed proficiencies spread across a wide audience. You get the benefits of the people in the big machinery feeling closer to each other by conversation. You also get the power of consistent group think. So you were right on to make one of your founding guide points "no private spaces" and to review the groups for how big the participation was going to be.

On the outside the need is opposite. A big company has a large and uninviting mass audience presence. So the smaller social group focused on specific customers needs makes sense because of the personal service aspects. So big groups is probably what you already have and small more interactive groups are probably more inviting.

I personally enjoy working with people that know a little about me especially if I were receiving a service from them. I have even gone so far as to wait another day for a service that could be rendered by any until the service provider returned from vacation.

John Prichard
prich@ti.com
Texas Instruments