Moving Outside The Firewall

In my last post, I offered up the analogy that our journey was like an airplane trip, and -- at least for our internal effort -- we were at cruising altitude.

I was a bit premature.  Now we're about to land, and connect onward to another leg of our journey -- going outside of the firewall.  There'll be a bit of chaos as we get off one flight, and on to the next ...

And it's going to be nice to get back to cruising altitude soon ...

One Of Our BIg Ideas

As we approach this whole topic of social media proficiency at EMC, one of our guiding principles was the whole notion of "inside out", e.g. develop internal proficiency first, then venture outside armed with (a) knowledge of how this stuff works, and (b) many more willing participants.

We didn't want to have an external presence that was unconnected to the inner workings of our company.  Ideally, our notion of a "big conversation" would extend outside of our firewall to reach many, many others.

Well, we have arguably achieved some degree of internal proficiency.  Now it's time to go outside.

But we had to get organized first ...

A Centralized Function

We could easily have hundreds of internal functions who each wanted "their" community outside the firewall.  Indeed, a few "intrapeneurs" have gotten ahead of us, showing the potential of this approach.

But there are corporate interests at stake here, right?

I mean, we'd like to have a relatively consistent (and high quality) experience across all of our communities.  And there has to be an "outside in" view of all of this, organized by the needs of participants, rather than the needs of the individual community sponsors.

I've also noticed that there's a natural "expanding universe" tendency with some of these early efforts -- rather than narrowly focusing in on their initial constituency, they tend to be very broad in their intent and scope -- meaning that community formation rates are very poor.

And, let's face it -- building thriving external communities is very hard work.  It takes a lot of effort, and it doesn't come naturally to everyone.

So, early on, we decided we would need a centralized function that acted as a sort of enabler and consistency creator across all of the communities we could envision.

But where to build it?

Add-On, or Standalone?

Initially, we had hoped that we could build such an external community function alongside our traditional e-marketing activities.  We got started with the same group who does our web site as well as several other internal platforms, and tried to make a go of it by simply adding on to what we already had.

Frankly speaking, the results were suboptimal.  I don't think it was the specifics of the people or the organization involved; I think the difficulty arose in achieving that singularity of focus that's needed to get really good at something that's really hard.

Our internal e-marketing team had a lot going on -- this was just another important project in the big scheme of important projects.  It was hard to get the focus we needed.  So we retrenched, and came up with another approach.

A Diamond In The Rough

Turns out we went another way -- we found an internal group that was already proficient in building and running an external community, and we decided to extend their charter substantially.

The EMC Developer Network has been a thriving community of developers who want to develop their software using EMC's tools, not unlike other software development ecosystems.  Not only was their community up-and-thriving, but they'd learned what makes communities tick, how they develop and grow, had a nice platform, and so on.

We convinced this team that they could not only look after their important community, but they could create a parallel function to help coordinate these external community activities across the company.  That's a big leap, and not to be undertaken lightly.  You don't want to lose focus on the community that you've already built in your quest to become the corporate focal point for all external community work.

I think we got lucky that we had these skills in place, and that they were very proficient.  The alternative idea of "building from scratch" was not appealing in the least.

A Schema For Meta-Community

Our lead for this team quickly jumped on a key point: unless we had an organizing paradigm that made sense to outside participants, things could get very chaotic very quickly.

The trick was to avoid an overly restrictive taxonomy or heirarchy (lots of discussion why that's a bad thing), yet help people navigate to the areas that aligned around their interests.  And it had to be what our audience was interested in, and not necessarily what we were interested in.

The resulting proposal schema ("EMC Community Network") has the right "feel" between organized and loose, and -- based on what I can see -- will bring a relatively consistent experience to the table, while still allowing the dynamic, free-flowing nature essential to community development.

I also liked that the organizing principle was what our audiences were interested in, and not necessarily how EMC viewed the world.  Hard to get that external perspective, but it's oh-so-essential in this stuff.

But There Are Other Interests On The Table

This free-standing external community development organization can't live in a vacuum.  For example, it's pretty clear that whatever they do are part of the overall web experience that the company delivers, hence we're going to need some strong involvement from our e-marketing team.

Likewise, there will be IT-specific concerns around security, risk and technology integration.  So they're part of the team as well.

We came up with a "working committee" structure that will allow this externally-focused community development group to focus and deliver, but hopefully ensure that other stakeholder needs are accounted for and discussed.

So far, so good.

This Structure Vs. Other Alternatives

I'd go so far to say that this sort of structure might be workable for other companies as well.  The free-standing team gets focus and passion, yet has to tie in with other functions who have a vested stake.  I'm pretty sure the "driven by IT" approach won't work in many circumstances.  Nor will the "driven by marketing" approach work in too many situations.

This appears to be a free-standing organizational competency, and doesn't really align that well with marketing (although they're heavy users of the stuff), nor IT (although we need their help in delivering the infrastructure and integration).

Can you get there with other organizational structures?  I'm sure you can -- but probably not as quickly.  Although I'm sure there are a few people who aren't happy we're doing it this way, I have to say that I'm overjoyed with the structure.

And Then Things Started Moving Very Fast

In the space of just a few weeks, a bunch happened very quickly.

First, the team established an outreach community on our internal platform (EMC|ONE), targeted at all prospective external community builders.  I have this saying about using social media techniques to solve social media problems, and this is yet another example.

Rather than have a bunch of meetings, they defined a space where all comers with an interest in external communities could join, learn, discuss -- as well as become a bit more articulate about what they wanted to do, and why.

Second, we were able to come up with a fairly quick ranking of which external communities were priorities, and which ones could wait until later.  This sort of list helps to focus our efforts.

Third, the small dev team was able to quickly prototype what the external meta-community (EMC Community Network) would look like -- look, feel, navigation, etc.  I've discovered that when communicating this stuff, a picture (or mock up) is worth ten thousand words -- and takes a lot less time to communicate.

Now We're Cooking

I don't know when the first (new) external communities will appear.  I'm not sure when we're going to announce or promote the meta-community.  As a matter of fact, I only have a very hazy idea of schedules and milestones.

But I'm not too concerned about that at this juncture.

Why? 

• We've got a focused team with demonstrated proficiency at this stuff. 
• We've aligned their role with other vested stakeholders, and we have the lightweight policy governance we need to get things done and resolve conflicts. 
• We've established an internal focal point for everyone who's interested. 
• We've now got the ability to get customized and enhanced external community scaffolding up and running quickly.
• We've got thousands of internal participants who are comfortable with this stuff, and "get it"
• And we have community coaches who have now down it before.

Simply put, we've got all the ingredients we need for external proficiency. 

Now it's time to get cooking!  

Comments

[Annette Schulte]

Chuck, could a company without experience with communities use the collaborative committee model for managing external communities, you think? I'm seeing a real need for collaboration at my company b/w product managers, marketing, IT and myself, but will have to persuade others. Any advice?

[Chuck Hollis]

Hi Annette

It's hard for me to come up with concrete advice, as our situations are so different. I also checked out your website a bit to get more context regarding your situation.

I think it gets down to leadership models. If you have one individual who can provide strong and authoritative direction (of course, reflecting input from others), I think that would be preferrable to a model where there was a strict consensus model. Although the egalitarian consensus model can work, it won't work fast.

And I'm starting to realize that speed matters.