Social Media is not a strategy

Last week I had the opportunity to speak at the Web 2.0 Conference. The conference, like the Enterprise 2.0 show in Boston this past summer,  is atypical in that most of the good stuff was happening in the talks and workshops. People were there to learn and see what the thought leaders were thinking. And there were some fabulous thinkers there. Jeff Dachis and David Armano gave a fantastic discussion of social business, Gentry Underwood artfully presented is very useful insights into adoption of Enterprise 2.0. Really, the list of luminaries and their beautiful and insightful presentations are well worth a look here.

In this context, my talk was very nervously executed (I was speaking on topics I don’t normally cover, I’m more of a culture and collab gal), but the quality of the audience was fantastic. The basic idea was this. You don’t start with a social media strategy. You start with a marketing strategy, a customer relationship strategy and a collaborative objectives strategy.

Insightful and important questions ranging from budgeting to competitive differentiators, and importantly, how to convince people of the worth of what you’re doing came up, and I believe the Q&A lasted longer than the talk itself.

More than 100 people came to my session, and I was grateful for the engaged audience, and have a lot of new twitter buds as a result. Hopefully I also created some interest in the excellent range of technologies, products and expertise that Open Text has to enable Enterprise social media.

My slides from the talk are here. If you attended the session, or if you didn’t, I’d appreciate your thoughts and a continuation of the Q&A.

A repost: Enterprises aren’t human

When someone you respect suggests you repost something, its a good thing to do on a late friday afternoon. So for Oscar Berg, I offer you a classic post from last fall during the Obama/Hillary race for president. I’ve fixed some of the grammar, but left the rest in tact. Have a great weekend.

December 29, 2008 • 5:10 pm (Edit)

why social media is hard for government and corporate america

Since the dawn of commerce and government we’ve been programmed to believe that enterprises are not human – they are better: polished, powerful and perfect. They have a presence (rather than a personality) that does not include human characteristics, like warmth, empathy, vulnerability, hobbies or ears. The job of the people in the enterprise has always been to perpetuate and perfect this presence.

Now employees and leadership both are confused by their centuries old mandate not to act human, and their new one to do just that. They see the risks – revealing too much, legal liabilities, leaking information to competitors, and all – and are unsure of the rewards.

But they’ve heard about “viral” and “loyalty” and “word of mouth”, and “customer-evangelists”. they’ve seen Obama be cool and successful.”

And they’d like to too. But to do this they need to take a big risk. They need to be human – vulnerable, imperfect, and all that. The people in the enterprise need to be free to (and encouraged to) come out from behind the curtain, and to know what that means.

Barriers
1. Most enterprises don’t share enough with their employees for the employees to feel confident as spokespeople.
- Beyond the mission statement, the leadership needs to discuss with people  the priorities and values of the company. Not just in an annual meeting, but constantly. It needs to be true and real – not white-washed. If you can’t convey your mission, aspirations and values to your employees, they can’t internalize them and carry them outward as people. Solution? Internal dialog. Perhaps facilitated by internal social media. Its NOT rehashing the phrases coming out of the PR team. Its not a ghost written memo. This means that YOU, the CEO, the VP of whatever, need to be in constant dialog with your team. It seems as though that would have more than this one benefit dosen’t it?

Here’s a simple example of corporate leadership being human in an inspirational way:

http://about.networksolutions.com/site/network-solutions-executive-team/

That’s not too hard. A nice step. A nice example. You could do that. You could go a step further and add an email address or a blog. You could go a step further, and do it a couple layers deeper in the organization, or for everyone in the organization. Think about how that would make the people on your team feel about being on the team.

2. Government and Commercial enterprises fear the loss of the power of the curtain.

It takes a tremendous amount of confidence to be human. It means that you are confident that on the whole, the value your organization brings to its customers is very high, and that you are operating with integrity. That you are generally proud of what goes on inside.

This is a kind of confidence that companies have not had to develop or test. But the people and organizations that we respect most are the ones with these qualities. Its the difference between Hillary and Obama, in many ways.

3. Unclear on the upside.
Well, here it is. Corporate credibility is on the decline – not because corporations are, but because people have now had enough experience to know that the facade is just that. Who believes advertising? Who trusts the literature? But they’ll trust a person – one they know, for a recommendation. They’ll trust someone they don’t know who makes the effort to gets to know them by listening, showing an interest, speaking clearly and honestly, sdoing what they say they’ll do – someone who builds a relationship with them.

If you want credibility now, you need to be communicating as an organization of people, not a corporate entity.

tales from the collaborative front

Its a whole new world with all sorts of new twisty things to work out – at work too.

So – this collaborative culture we’re promoting and developing – its new, and people are banging around the middle and the edges.

Case in point. We, in our englightenedness, have a system (that you will certainly hear more about soon) where it takes approximately 3 seconds to set up a community. The community has a participant list, a wiki, a discussion feed and can hold docs.

There’s a (small) team that built a community to support a specific goal. They’re experimenting and trying to fly under the radar. One member – a well meaning one to be sure – wants them to “open” the group to the wide world, especially the team we can call the “broad responsibilities” team.

So – are they being open and transparent? No. Is that wrong? Maybe not.

Who is your team?

Your team is the set of people with whom your goals are aligned.

This implies that you have different teams for different goals.

You also have your day to day team, the slightly broader stakeholders team, and the general wide world of potentially interested parties team. They are all legitimate, and good things come from each.

But is transparency and collaboration the same across all three teams? Should it be?

Is it legitimate to want to fly under the radar? Or is this inherently anti-collaborative? What is the purpose of collaboration, and how is it affected by this sort of thing?

These dramas and many more will fold and unfold as we go forward. The good news, is that we’re learning a lot. The bad news is that learning is sometimes, uh, eventful.

My gut feeling is that there’s a place for small, insulated teams to do some experimentation, but at some point the insulation should come off. Or even better – what if this team was visible to others, but only if they were searching for a relevant term, tag or person – a sort of need to know filter? This wouldn’t be hiding, but not explicitly inviting participation unless there’s a reason.

I think at the very least its a great opportunity to dig into the value prop of collaboration a little deeper, and see what emerges.

Ok – half of the people involved are going to read this, so fire at will…

nothing to fear but fear itself

If people were perfect, we wouldn’t need to collaborate, just clone.

People used to think the way to be efficient was to divide and conquer. And that’s still true, but limited. The next level goes from divide and conquer to unite and conquer. What I mean by this is that each of us individually has a set of competencies, experience and perspectives, as well as inexperience, weaknesses and blind spots.

As a team united, our strengths are amplified and our weaknesses diminished. Anyone who’s ever been part of a really collaborative team will relate to the blood-pumping excitement – the “we can do anything” feeling that comes from this.

So why is it so very rare? There are of course lots of reasons of course, but I think the number one reason is fear.

A collaborative team has a fully and mutually open kimono. and we live in a society that’s been taught to be very bashful. A couple of generations of top-down management by fear have taught us that imperfections are shameful, and we should be sure to cover ours.

But if we’re constantly covering our ___’s then we are not allowing the team to work its amplify/minimize magic.

Earlier today, I took an email trail and posted it to an internal wiki. The ask in the email was some answers to questions posed in a q&a session. I was taken to task for posting it cause it wasn’t “ready” – it hadn’t been “reviewed” – someone’s going to take offence.

Ladies and gentlemen – this is what a wiki is for! Put it out rough, and let the team do its thing.

Who’s your team? Your team is the set of people that you share these characteristics with:

1. Shared goals and mission.

2. Mutual respect

3. Trust

4. A pact, enabled by the previous 3, that makes finding problems and flaws a virtue.

Traditional management by fear encourages us to hide flaws and weaknesses, because we’re punished for them, rather than rewarded for our strengths. So – instead of bringing possible problems to the table early and eagerly – where they can get be turned into opportunities and achievements, they are hidden until its so bad that they burst.

Want to be the best and the brightest team? Bring your strengths, bring your confidence, bring your flaws, and toss the kimono.

trouble in the middle of the room

I have this big color laser printer. You know the kind – its about the size of a large old fashioned tv set, and about as heavy. Its sitting in the middle of my office. On the floor. Its been there for over a month. Its in a spot where I actually have to walk around it to answer the phone, or to get on my elliptical trainer, and I makes it difficult to pace the way I prefer when on conference calls.

So why is it still there? Cause I don’t really know what to do with it. I don’t want this giant to take up the space where my current printer is. Its too nice to get rid of. I don’t feel like taking the 15 minutes to hook it up.

This is exactly the kind of thing that happens in most product development cycles. These problems. That everyone knows about, but doesn’t exactly know what to do about.

And there’s the opportunity right there to make the difference between good and great. Find those things littered around the floor. Sometimes they are UI issues. Sometimes its a feature that’s lacking. Or the fact that the customer research says everyone wants green and you have blue. Or the fact that the licensing isn’t (and won’t be) in place. Don’t ignore them. Make it an absolute virtue to say – hey look everyone – theres this stupid printer in the middle of the @*#&^@ floor.

You may catch some heat, at first. In some companies I’ve worked for, the pressure to ignore these things gets greater as you go up the hierarchy (I’ve never been able to understand this, and its one reason I find consulting to suit me). But ultimately, if you can be part of a team, that will never pass a printer in the middle of the floor without deciding what to do about it and then doing it, you will do great things.

Passion is a best practice.

Want to build something great? You have to want it. Bad.

Here are some somewhat random thoughts about passion, quality, genius and boredom and mediocrity.

Greatness is rarely achieved by accident. It is the result of a pure vision, refined over time and developed with care and purpose. I do not believe that it is possible to develop a truly great product without at least one very influential visionary on the team. Why?

Well – on the way to any goal, there are about a million little decisions and tradeoffs that need to be made. Without a vision, a North Star, as they liked to say at Adobe, those tradeoffs end up in a bland compromise.

But we have to compromise! Of course we do – we need to make decisions. But with a clarity of vision and purpose, those decisions make a product stronger, not weaker.

Without vision, its hard to care, to offer the attention to detail necessary to make it perfect. Pure discipline is a hard way to attend to the details. We need discipline in everything we do – of course, but discipline fueled by passion is incredibly powerful. Discipline supported by sheer force of will – well its just hard to maintain and sustain.

An interesting micro-cosmical example of this happened at Startup Weekend a couple of months ago. Various ideas were pitched and discarded, and the one startup idea that was voted in was a site that enabled micro-social networking for neighborhood communities. The problem? The guy with the idea split shortly after the vote. Leaving the rest of the people – even those who thought it had been a good idea – looking around for what was special about it, and what would make it more than yet another social networking site. We eventually came up with a couple of reasonable value propositions that we bickered about a bit, and ended up spending the weekend working on features that were neither here nor there.

Now – this was a situation where it really didn’t matter much. The point of the weekend was to see if we could launch something, learn, have some fun. All of which we did – and it was a FANTASTIC and wholy worthwhile experience that I hope I can repeat someday. But. It made a great little expose on why a little passion goes a long way.

On the flip side. When I worked at AOL, oh so many years ago, we launched an online calendar. In those days, an online calendar was still a new-ish thing, and AOL was still the leading provider of consumer internet access. But our little calendar was sweet. Every detail was lovingly designed, debated and improved. We had a crystal clear notion of what we were building and why, and what we wanted it to become someday. The team had a huge spark of creative endeavor. For a calendar. Its not the product – its the passion behind it.

What’s your passion? What’s fueling your creativity? What will make your next product great, not just there?

Slogging through the details? Get Agile.

So – the strategy is clear, the thinking is exciting, the opportunities immense. What’s left now is to get it done.

And its not all easy, and its not all fun. So how do you slog through the minutia? These details that can be painful to document are so important to success, so – what’s the best way to approach them. In my case, I’m working on a Product Requirements Doc for a client. (I’ll do anything in the name of a great outcome). The outlines of the product are clear and everyone’s excited about the product direction. And still – getting every detail on paper is taking longer than it should, and delivering less value than it should.

The answer here depends on the circumstances, and who you are, and what you’re trying to achieve. But I think the best weapon is a buddy. Have someone to walk through the details with, and instead of a boring, painful, process, you suddenly have a vibrant conversation.

Who’s your buddy? Well – in the case of a Product Requirements Document your best allies are Design and Engineering. They each bring great insight to the table, and its essential to be in lock step with them. This small step is, in fact the first step toward an Agile methodology.

The Agile process is one of the most productive, efficient and altogether engaging team structures. In this process, design, product management and engineering get together, define the general outline of the product, and take a deep dive on a piece of it. Then, engineering goes and builds that piece, and design and product management go deep on the next piece. Then engineering gets involved again, and so it goes. Iterating, learning, iterating and learning. I’m a huge fan of this process, and most engineers I know like it too.

The key tools of the process are collaborative communication, trust and respect. People need to be on their toes and know you are too. The result is usually a highly aligned team, with a high degree of collegiality, and a killer record for getting things accomplished. People work in parallel, but not in isolation. Engineering isn’t left waiting while product management figures stuff out, and product management isn’t left with the huge burden of arranging every detail on a platter for

There are pros and cons to this method. The pros is that it can dramatically reduce schedule risk, gets all the best minds in synch, and can be very responsive to changes in requirements and learning. The cons, is that if you must have extensive face time. If part of your team is half way around the world, it can be extremely difficult to achieve this level of communication. I’ve not managed it yet myself. But, I’m sure that if I could, the productivity of the team would soar, as would morale.

Has anybody out there been successful with Agile across continents?

But Agile is not just for Engineers. Agile tactics are very well used in design, marketing and any other part of the business where cross-functional collaboration is key, and parallelism is important. There are great books on the subject, but I think the best way to learn about the method is to chat with people using it, or even better, attend some sessions. I can hook you up with some, if you like. Just ping me at deb at productfour dot com.

collaboration: tangibles and intangibles

Product teams are usually made up of geographically dispersed, differently skilled and talented people working toward the common goal of shipping something exciting and profitable.

This creates huge challenges, but can, under the right circumstances be an inspirational experience that produces great results. Wrong circumstances, bad experience, disappointing results. Real collaboration involves dividing responsibility and sharing ideas, insight and expertise. This is often a mix of structured and unstructured, formal and informal free style interaction that needs both tangible and intangible support and assets to succeed.

Tangibles

The tangibles in collaboration have to do with making the collaboration itself logistically easier. There are 3 core activities that current technology has begun to make great stride in:

1. Communication – Email, phone, IM, teleconferences, video conferences, etc. The tools of group communication are good and getting better.

2. Sharing – this is where some of the web 2.0 technology has made a real contribution. Wiki‘s and wiki based tools make sharing a lot of data in an unstructured way easy and fast.
3. Reuse. As professionals, we’re often asked to do things analogous to what we and other people we work with have done before. There’s frequently a lot of research and documentation of results. Most of the time, however, all that remains of this process is the documentation, and the memories preserved in the minds of the people involved. Wouldn’t it be handy if the research and collection phase were self-documenting? This is an area yet to be addressed by technology, and as such should perhaps be in the “intangibles” section – but I have hope for a solution here, and soon.

Intangibles

1. Respect. You all know you are all good at your jobs. Each person’s opinion is worth something.

2. Trust – you’re there to help each other, not climb over each other.

3. A shared sense of goals. Working toward a common objective and vision, not competing with one another.

With these three intangibles in place, nearly any group can have productive debate that sparks real innovation, problem solving and the excitement that gets the hard work done. Without them, debate becomes bickering, the team lacks the ability to refer to one another to solve problems, and the whole is less than the sum of its parts.

Getting started with wikis

One of the first things I like to do when I begin any engagement  or project is to set up a Wiki. Wikis are a great collaboration tool, and getting better. I like them because they are so simple to use its easy to get people to cooperate.

A wiki is basically a website that is meant to be designed and edited by a group of people. If you have a wiki, it means that you and your team, friends, whomever you designate as authorized can come, type, edit, and upload docs and meda. Don’t be alarmed by the idea of editing a web page. If you can use email and Microsoft Word, then you can easily use a wiki.

Early wikis had little formatting capability (unless you wanted to use html tags, and I don’t), and were really designed by and for engineers. But they’ve improved. In just the last six months, wiki tools have become more flexible, easier to use, and a lot nicer to look at.

Wikis can solve 2 very common problems:

1. The “What’s the Latest” problem: You’ve probably done this – email a doc out to a group, edit, resend. Things get out of date and out of synch. Nobody knows what the “latest” is. Post it to a wiki and bam – every one knows what the latest is. Every one is literally on the same page. Not only that, but whatever format you’ve got it in, and whatever email products everyone is using, the file won’t get munched in the transfer.

Having a wiki is like like having a shared notebook. You and your team can each post anything from minor comments to fully formalized docs. Everyone has equal access to them. I’ve managed large and simple software projects this way, along with the design and permitting process of a house.

2. The “Where is that thing” problem: Because its so easy to put stuff up there, people actually put stuff up there.. Feature ideas, minor issues that need attention, meeting notes, Aha! moments. The number of the pizza place. The team roster. Whatever it is you’re looking for now, you can stick up there, and then you’ll know where to look. Where is it? On the wiki.

Getting started.

Getting started is pretty much as easy as going to the wiki website of your choice, signing up, and dithering around with the buttons. Your second wiki will take you less than 30 seconds to set up. Your first may take all of 10 minutes, if you aren’t really used to the software. There are wikis that you can run on your own computer or on your own servers, but fortunately, there are plenty you can just go to, create an account, and you’re in.

Once you’re in, you can edit pages, add pages, upload stuff and link stuff together. Invite your teammates to join. They get an account, then they can edit the pages too.

Cautions:

1. The biggest problem I come across in a wiki is that while everything is up there, it can sometimes be hard to find. You may want to come to some kind of agreement with your group as to where you’ll put various categories of stuff.

2. Wysiwyg formatting is still not as good as it could be. We’re used to word and power point, and we’d like that level of sophistication in our tools. Google? Got a minute? I expect this to improve significantly and soon.

Free wiki’s to try:

These are just a few in a relatively crowded field.

www.wikispaces.com – this is my tried and true, but its not the most beautiful, nor does it have the nicest wysiwyg editor anymore. Has ad supported free, and paid, private offerings.

www.wikidot.com – love this. nicer editor, nicer looking. Free. Embedable widgets. Great formatting for academia: footnote, bibliography and formulae are all nicely handled.

www.pbwiki.com – also very nice. embedable widgets

or, if you have more elaborate collaboration needs, you can try: www.basecamphq.com, which includes, to do lists, time tracking, milestones, and more complete project management features.

So, Now that I’ve found the trouble…

I recently posted about the trouble seeking process (The Virtues of Looking for Trouble). So, I’ve been asked the question – what do you do with trouble when you find it. Well, in short, the goal is to minimize risk, and maximize opportunity.

How. Well – first, as I said before, its imperative that you alwas have your ears open for trouble, and make it a regular activity to discuss it with the team, and management (get them used to it – it will pay off in the long run!)

1. Keep blame out of it.

Even if someone really screwed up, there’s time to deal with that later. Blame will not help solve the problem, and blame will make it much, much, much harder to discuss problems productively. No one will bring up bad news if they fear they’re going to get slammed. Most of the time, assuming that you have a good team, the blame will be that we work fast, blazing paths through the unknown – we’re paid to innovate – that means we just don’t always know in advance how things will play out. So – respect and trust. (And if you do have a bad egg – deal with that quietly, and make sure its about skills, talent, match, etc and not about “this went wrong and its your fault”. But that’s a different subject)

So back to dealing.

2. How bad is it?

Is there general agreement that if this problem is not managed, the launch, the schedule, the user adoption, the business model or other critical success metric is in clear peril? If so, all due attention should be These should be at the top of the agenda, and made as visible within the organization as possible to get to the best possible solution.

3. Verify and characterize the problem.

Once the problem is on the table – get general input on it, then make it someone’s responsibility to map out the size and shape of the problem. Is it a lack of information? Is it a technology glitch? A new competitor? A design flaw? A resource issue? What are the ramifications? Best, worst case scenarios? Is there a critical decision point, or is this something we can just watch.

5. Identify key decision factors: (ie if this outside event does not occur by this date, then we’ll… ), if this metric hits this mark, then…, if this study returns this result, then….. If the blah blah group (or partner, or whatever) can’t deliver x, by y, then…

4. Decide on a course of action: Solve, remediate or watch.

Some problems can’t be solved, but you can keep them from making fools of you just by tracking them, and responding when and how you can – is it positioning, PR, expectations setting on the schedule, feature-rejuggering, getting new partners, etc. A team that can sit down and really hash out problems will get to the “aha” moments much faster. A team that is looking for, and dealing with trouble effectively is going to make it to the goal line faster, and score bigger.

Moreover, many problems, found and managed early, will make your project, product or campaign much much better than you might imagined. Stay tuned for “How canceling a project won over our users”.