Public Relations Strategery

Stop worrying about hitting the big drive and concentrate on the fundamentals

Ever hear the phrase “Drive for Show, Putt for Dough?”  It’s  time-honored sports cliche that refers to the oohs and ahhs that a huge golf drive off the tee will elicit from the crowd. However, despite all the attention a big drive gets and hundreds of dollars a good driver costs, that shot is used maybe 12 times each round. The real money is made on the green where an average player will take almost 3 times as many strokes. You can make all the highlight reels you want with your 350 yard drives, but if you can’t make a 10 foot putt consistently, you’ll be in the same place I am on Sunday….on the couch watching someone else who CAN make those putts.

I bring this up because I’ve seen one too many Enterprise 2.0 implementation – be it a wiki, a blogging platform, discussion forums, microblogging, or Sharepoint – fail miserably because they forgot to focus on the fundamentals.  They end up being too concerned with the big drive off the tee that they forget to practice the short putts that are needed to truly succeed. Nearly every Enterprise 2.0 vendor out there offers a similar set of features – blogging, microblogging, wiki functionality, profiles, tagging, search, etc. – they all hype up the fact that THEIR platform is the one that can do X or can do Y, that they have this one unique feature that puts them out in front of the competition. Likewise, once these platforms are purchased and installed, the client teams responsible for customization and integration get enamored with all of these features as well. I’ve seen way too many internal launch emails that sound something like this:

“Visit our new website, the one-stop shop for all your collaboration needs. This new website offers all of the Web 2.0 functionality that you have on the Internet, here in a safe, secure, professional environment – blogs to share your expertise, a wiki that anyone can edit, profiles so that you can connect with your colleagues!”

Seeing all this empty promotional language makes me think of my friend who absolutely crushes the ball of the tee. After another monster shot from the fairway, he’s now gone 524 yards in two shots and the crowd is loving it. He then proceeds to take three putts to go the final 10 yards because he spent all of his money on a new driver and practice time on perfecting the big drive.

Unfortunately, Enterprise 2.0 implementations are suffering from this same, all too common problem.

Day 1: After being enticed by the blogs, the wikis, the microblogging, and the rest of the features, you visit the site, you poke around a little bit – so far so good.  Everything looks great.  The design is eye-catching, there’s a lot of great content up already, some of my peers have friended me, and I already found a blog post relevant to my job. This is the best site ever! Enterprise 2.0 FTW!

Day 2: I visit the site again and invite a few of my managers to join as well…well, I tried to invite them to join, but the invite a friend button wasn’t quite working. That’s ok – I’ll try again tomorrow – must be a bug.  I can’t wait to get them using all of these cool tools too!

Day 3: Well, that invite-a-friend bug still isn’t fixed, but everything else is going pretty smoothly…other than the fact that the blogs don’t seem to work in Firefox. I guess I’ll have to use Internet Explorer for those, but that’s ok.

Day 7:  I’ve got a big meeting today with the new VP at this conference we’re both attending – I’ll demo all these new social media tools for him and show him how he can start a blog too!

Day 7 (later on): Damnit! I didn’t realize that I wouldn’t be able to access the site unless I was behind the firewall in one our corporate offices 🙁

Day 14: On my way to a meeting, I was checking out my co-worker’s Facebook page on my iPhone when I saw his latest status update – “OMG – I can’t believe that someone said that about our new HR policy on our corporate blog!!” Intrigued by what was said on the new blog, I try to navigate to our blogs…foiled again!!!  No mobile support….I guess I’ll check it later tonight.

Day 17: Working late on a report again – luckily, I’ve been posting all of my findings to our new wiki so that when I leave for my vacation tomorrow, everyone will have easy access to the latest and greatest data.

Day 18: Disappointed to receive an email on my way to the airport that our Enterprise 2.0 site is down for maintenance for the rest of the day, rendering all of my data unusable to the rest of my team. They can’t wait a day for the wiki to come back up so it looks like they’ll be working extra hard to recreate everything I did last night.

Day 19: &*%$ I’m DONE!!!  Why is this thing so slow?  What does Facebook have 500 million users yet is always up?  Why can I download a movie from iTunes in 3 minutes, but it takes me 25 minutes to download a Powerpoint presentation?  Why can I read Deadspin from my phone no matter where I’m at in world, but can’t access the blog I’m supposed to be using for work?

Sound familiar to anyone? This is what happens when Enterprise 2.0 is too focused on the teeshot, and not enough on the fundamentals of the rest of the game. Features galore that will get people ooohhing and aahhhing, but lacking the fundamentals of speed, accessibility, and reliability that will keep people coming back. If you’re talking about implementing an Enterprise 2.0 platform, before you start talking about all of the bells and whistles you want, make sure that you take care of three very fundamental issues.

Make it Fast – People have to expect anything online to be fast. If I click something, it should take me there immediately. There are no exceptions. Load times for simple html pages (we’ll give multimedia an exception here) should be almost non-existent. I don’t care if I’m behind a corporate firewall or not – if it takes 4-5 seconds to load a page, that’s going to severely limit how often I can use it. If my bank’s site can be secure and fast, why can’t my Intranet sites?

Make it Accessible – Laptops, desktops, iPads, iPhones, Android devices, my old school flip phone, hell, even my TV all allow me to get online now.  I can access Pandora, Facebook, Twitter, and a whole host of other sites from a dozen different devices while on the subway, in my house, in a rain forest, or in my office.  But, you’re telling me that I can only access my work from one kind of computer that’s located in one place? Doesn’t seem to make much sense.

Make it Reliable – There shouldn’t be a fail-whale on your internal work systems. If I need to access some information to do my job – be it a blog post, a wiki page, or a file – I need to be able to access it, with 100% certainty.  If I need access to some data for an important meeting, and I can’t access it because our site is “down for maintenance” or it was accidentally deleted in some sort of data migration error, that’s a serious breach of trust that is going to make me question whether I should be using the site at all.

Concentrate on perfecting the fundamentals before you start getting into the fancy stuff – practice your putting before your driving, learn to dribble with both hands before entering a dunk contest, practice catching the ball before you choreograph your touchdown dance, and make the wiki work in Firefox before you start working on some drag and drop home page modules.

Photo courtesy Flickr user Stev.ie

Do the top developers for Google’s Android operating system use Blackberries?  Do the IT guys developing Windows 7 use Macs?  Do the folks at WordPress use Blogger to host their personal blogs?

These are purposely ridiculous questions – wouldn’t the best developers use the actual tools they’re responsible for building?  Wouldn’t they do their job more effectively if they were actually a user of the product they’re developing? Doesn’t the product have more credibility if the people behind it are believers in the product’s features?  Out of everyone, shouldn’t the development team, at least, be the biggest advocates of the very software they’re implementing?  Shouldn’t they be the ones drinking the Kool-Aid?

Unfortunately, IT departments at large companies and government agencies are too often doing the equivalent of developing Android apps at work and using the iPhone at home. Sharepoint developers implement Sharepoint, yet they don’t use it to manage the implementation. The guys installing your organization’s blogging software don’t realize that the “Add a Picture” button doesn’t work because they don’t have blogs.  The team responsible for increasing awareness of your Enterprise 2.0 platform haven’t even created profiles of themselves.

Now, take a look at the official support areas for WordPress, Telligent, MindTouch, Jive or any of the dozens of social software vendor sites.  Notice anything? The developers are often the most active members of their respective communities and they’re using their own software day after day in the course of doing their jobs. If there’s a glitch involved with posting a new comment to a forum, they’re going to be the first ones to see it, diagnose the problem and fix it.

Sadly, I’ve been seeing these situations increase with the emergence of the Enterprise 2.0 and Government 2.0 initiatives. IT departments are increasingly being asked to implement wikis, blogs, social bookmarking, video-sharing, and dozens of other varieties of collaboration software – software they may know how to code, but often have no idea how to actually use.  They’re just told to “give us a wiki” or “develop a blog for me.”  Actually using the blog or wiki isn’t a requirement.  As as I was told by one programmer a year or so ago when I recommended he start a blog to inform the rest of the community about the latest enhancements and maintenance activities,

“Every hour I spend playing around on a blog post is an hour I spend away from coding!”

Well, that was helpful – thanks! Instead of getting frustrated and ending the conversation, I should have instead elaborated on the benefits that a developer enjoys when he becomes a user instead of just a developer.

• Higher quality product – you can identify bugs and feature improvements before they become problems for other users.
• Increased credibility – If, as a user,  I ask how to upload my photo, guess whose response I’m going to be believe – the guy with an empty profile or the guy who’s been active on the community for the last year?
• Increased “forgive-ability” – Look, we know that these sites will go down occasionally, especially when they’re first being developed.  We can deal with that…if we’ve been reading your blog and know that it’s down this Saturday night because you’re installing the new widget we’ve been asking for. If the site goes down and all we get is a 404 error page stating that the site is down for maintenance…again, we’re going to be less than pleased.
• Content Seeding – Clients are always asking,  “how are we going to get people to actually work on this site and add content?”  Well, before you even launch, if your project team (including developers, community managers, comms people, etc.) actually use the site you’re building, you’ll create a solid base of content before you even start to open it up to more people.  Adding to existing content (even if it’s not related) is always easier than creating something new.
• Common Ground – you become a member of the community instead of the guy behind the curtain making changes willy-nilly. You gain trust and respect because they know that you’re dealing with the same issues they are.  You’re struggling to access the site on your phone too.  You’re not getting the alerts you signed up for either.  You’re not able to embed videos correctly.  You go through what they go through.
• Greater ownership in the final product – The community becomes YOUR community, not something you’re just developing for a bunch of “users.”  You become invested in it and want to make it faster, add new features, win awards, etc. because you’re a part of it.

For all you non-developers out there, would you like your IT staff to be more visible?  Would you be interested in learning more about what’s happening under the hood of your Intranet/Enterprise 2.0 platform?  What other benefits do you see to getting them more involved?

For you developers, what’s preventing you from getting this involved in the communities/platforms that you’re responsible for creating?

If you think that the enterprise-wide wiki you’ve been pushing to install is going to change the culture of your organization, think again.  That wiki is going to reflect the culture of your organization, not change it.

Enterprise 2.0 holds a lot of promise: Increase collaboration!  Break down stovepipes!  Enable open and transparent communication!  Crowdsource white papers and presentations!  Use wikis to eliminate email!  Cure cancer!

And in some cases, these technologies DO allow organizations to realize these benefits – well, except for maybe the last one, but you get the idea.  But in many of these social media implementations, I’ve come across a lot more people saying, “I have an internal blog but no one reads it,” or “We have a wiki, but no one uses it!”

Why are Enterprise 2.0 implementations of blogs, wikis, or forums not living up to the expectations of the technology?

The primary reason is because social media tools reflect the culture of the organization – they can’t change the culture of the organization by themselves.  If the “social” part of social media doesn’t exist within your organization or is corrupted, all you’re going to end up with is “media” – a blog with no readers or a wiki with no edits.

I recently discussed the challenges of creating a social media culture behind the firewall with several of my colleagues on our internal Yammer network – here are some of the more interesting quotes from that conversation:

On needing a restricted access wiki, even behind the firewall:
“I need a wiki with both ‘internal’ and ‘external’ pages so that I can keep our team-specific items out of sight. The rest of the wiki would be open to engaging others in our work and designed to ‘market’ our capabilities to others.”

On the (often ignored) issue of intellectual property within and organization:
“People spend lots of hard work and man-hours developing a work product. They don’t want someone who ‘has an idea’ to swoop in, use the work, and have them get all the credit and acclaim for it.”

On how social media impacts the corporate rat race:
“For commonly held skill sets, [social media presents a problem because] someone may know enough to be dangerous, but the work someone else does and posts in an open environment would give that person the tools to advance their own careers without crediting those they got the information from.  That’s what I feel is the main reason people fear transparency internally.”

On how people can “steal” your work and use it without asking for it:
“I encourage people to borrow/steal/run off with my work. More often than not, it is difficult to get colleagues to take the first step to deliver/create new intellectual capital.  If borrowing my work is their first step, that’s ok. I’ll borrow from their step 2 or 3.”

Ultimately though, no matter how many pages your wiki has or how fantastic your internal blog is, the technology is going to reflect your organizational culture.  Not the culture you talk about on your website, but the real, honest culture of your organization.

Do you have people who routinely appropriate other people’s work as their own?  It will continue on the wiki.  Do you have people who punish their staff for speaking their mind and taking risks?  Those managers will forbid their staff from blogging.   Employees who regularly go above and beyond to help others?  Those people will be your wiki gardeners, making the wiki run smoothly for everyone else.

If you want to change the culture of your organization, social media tools can be a part of the solution.  But culture is determined by people, not by tools.  Make sure you supplement those tools with a change management strategy that will address the people too.  Consider incentivizing employees to share information and collaborate with each other.  Make information sharing part of their annual review (my team reviews the employee’s contributions to our internal network during their annual assessment debrief).  Reward staff for taking risks.

Enterprise 2.0 tools will always reflect the culture of your organization – for better or worse.  Make sure you give it every chance to succeed and address the people, policies, and processes too.

Last week, I participated in AIIM’s Enterprise 2.0 Practitioner Certificate program, a two-day course focused on learning the principles and best practices of Enterprise 2.0 – social media behind the firewall.  Now, I’ll admit, I was extremely skeptical of this course when I first heard about it.  I don’t think that social media or Enterprise 2.0 is something that you can learn about from a book, course, class, or test.  I think that above all, it’s learned from doing.

It’s one thing to read that successful Enterprise 2.0 deployments are about changing a culture and not about implementing a new tool, but it’s another thing entirely to actually do it.  I think the most successful social media efforts are those that are driven by passionate people who love people and who truly want to change the way their organization operates, not by people with degrees, certificates, or titles.

So when several of my colleagues urged me to enroll in the two-day AIIM Enterprise 2.0 Practitioner Certificate program, I didn’t really pay much attention to it at first.  However, I figured I should at least do some research into the program to see if it would be worth my time.  I was pleasantly surprised to see that a number of social media luminaries that I respect were involved in the development of the course – Andew McAfee, David Weinberger, Stowe Boyd, Patti Anklam and Eric Tsui.  Well, ok, if those guys were involved, I figured I’d give it a try.

I wanted to be challenged by this course, to get out of the social media echo chamber and get different perspectives, and to learn about specific strategies/tactics that have been successful elsewhere.  I didn’t just want to learn what I needed to pass some test.

Day One

Along with 20 or so of my colleagues working on Booz Allen’s own deployment of an Enterprise 2.0 platform, our first day began with our instructor, Hanns Kohler-Kruner, leading us through an activity to determine what Enterprise 2.0 was about – was it about culture?  Technology?  Innovation?  Tools?  All of the above?  After seemingly hundreds of slides of definitions, acronyms, models, and terms, I started re-thinking my decision to enroll.  I wasn’t a fan.  It soon became clear that the attendees of this class were far more advanced in Enterprise 2.0 than the typical attendee.

Hanns did an admirable job of adjusting his teaching style to include conversation and less lecture, and he promised to totally re-work the material for Day Two.  The material from Day One was best suited for someone who has little to no knowledge/experience with Enterprise 2.0, and is interested in discovering the basics.

What I Liked:

• The adjustments that Hanns made to accommodate the audience
• The occasional conversations/debates that the course attendees had

What I Didn’t Like:

• Hundreds of slides!!
• Too much lecture, not enough conversation and brainstorming
• Curriculum seemed to be too focused on teaching you what you need to pass the test rather than having discussions about Enterprise 2.0 strategy
• No hands-on application of the tools we were discussing
• Very little discussion of what’s worked/what hasn’t

Day Two

Before even arriving for Day Two, I was excited to find Hanns on Twitter that night, responding to our #aiim tweets from the first day.  I was really looking forward to the conversations about more advanced E2.0 strategies and tactics instead of definitions of terms that I would need only to pass a test.

Discussions on Day Two centered around the right balance of policies, rules, guidelines, and best practices for internal wikis; the risks of open vs. closed networks; and the need for open/transparent communication between IT and the user community. Some of the choice nuggets from the second day included:

“Stop focusing on the HUGE task of changing culture, and instead focus on changing habits.”

“Give people the tools and the time to do their work inside the firewall and they’re less likely to use less secure applications on the Internet.”

“The IT staff HAS to communicate regularly with their users and remain flexible and adaptable to their needs rather than their own wants and desires.”

For me, there were two big takeaways from Day Two.  1) Enterprise 2.0 tools like blogs, social networking, wikis, etc. aren’t some panacea – there is still a place for email, for face-to-face meetings, and for other “old-school” tactics.  And 2) Enterprise 2.0 isn’t a set of tools, it’s a mindset.  The actual tools don’t matter as much as how you use them.  Organizations can have blogs and wikis and still have just as many silos of information and isolated information as one that doesn’t use any of these tools.  Just as organizations without any of these new tools can still be open, transparent and participatory.

What I Liked:

• The open, free-flowing conversation where ideas were debated and assumptions were challenged
• The instructor was not only on Twitter, he’s been actively using E2.0 tools internally at AIIM
• The breakout groups where we worked together to help fictional organizations
• The slides had been completely re-adjusted for our needs

What I Didn’t Like:

• Hundreds of Slides!!
• Too focused on structured models and not enough on the cultural norms/nuances
• Not enough discussion about real-life Enterprise 2.0 examples

Following Day Two, we were all given a link to an online test consisting of 64 multiple choice/true-false questions.   This is where I was most disappointed with the course.  In taking the test, I quickly became annoyed that the questions were completely objective, focused on testing my knowledge of theoretical models and frameworks (e.g., “True or False: The tags described in the FLATNESSES model do not include meta-tags”), rather than on real-life Enterprise 2.0 practices.  Seriously, I could care less if someone can recite what that acronym means.  Why does that even matter?  I’m more concerned with answering questions like, “You’ve just implemented an enterprise-wide wiki – what are the arguments for/against keeping it completely open vs. allowing some private wiki spaces?”

Overall, I’d give the course a C.  I don’t think Enterprise 2.0 can be learned from a book – it needs to be experienced.  In the future, I’d like to see them shift the focus away from lecture (as Hanns did so aptly on Day Two) and more toward facilitated conversation.  I’d also like to see more use of these actual tools – how about an intstructor’s blog where we could all interact with our instructor before, during, and after the course?  Lastly, and most importantly, I’d recommend that AIIM incorporate some sort of # of months/hours of hands-on experience actually involved with Enterprise 2.0, a la the Project Management Professional requirements to have at least 4500 hours of direct project management experience.  Without this requirement, I’m scared that people will become “Enterprise 2.0 Certified Practitioners,” so they can cash in on this hot topic right now without ever actually having done any Enterprise 2.0 at all.

*Image courtesy of Flickr user billerickson