Diner Menus and Collaboration Platforms

Being a native of New Jersey I have fond memories of the classic Jersey diner. The kind of place that had a 20 page book for a menu, that served everything from breakfast to burgers to seafood (generally a goodFlickr - wallyg idea to avoid diner shellfish) all the way to full roast turkey dinners.  Throw in a generous helping of Greek, Italian, and even Mexican selections, and the customer likely had about 500 different items to choose from.

Someone not familiar with the New Jersey diner can get a bit overwhelmed and surprised with the sheer heft of the menu and almost dizzying array of choices. Page after page of choices, even at 3 AM.

Lately it seems like the options to the Human Resources Technology professional in the area of internal collaboration platforms is starting to resemble a Jersey diner menu.  Every day I think another web-based solution to support employee collaboration, communication, improve productivity, and otherwise turn your organization into a high performing, 'social' organization. And while I generally agree that these kinds of solutions are really the future for collaboration for many organizations, the sheer number of solutions that are currently available have to be confusing and a bit daunting  to the average HR professional.

A starting point for many investigating these solutions is the famous Gartner Magic Quadrant document. These documents attempt to give a relative ranking to a fairly large number of vendors in a given market, along with some basic information on the solution.  The current Magic Quadrant for Social Software can be found here. But the problem with the Magic Quadrant is that its inclusion criteria skews towards the larger vendors, and consequently the ones that tend to sell to the larger customers.

The many, many start-ups and smaller vendors, (many offering fully functional collaboration platforms for very low costs, even free) are not included by Gartner, and are generally ignored by many other major analyst firms. So if you are an HR Pro at a company of say less than 500 employees, (which by the way outnumber firms larger than 500 employees by about  333-1), then you are pretty much on your own to navigate this complicated and ever expanding space.

Just in the last few months alone I have checked out (among others) Brainpark, GroupSwim, Sosius, Central Desktop, Obayoo, Socialcast, Injoos, Spinscape, Conenza, and Neighborhood America.  All have interesting solutions, and all could be the right solution for a small business, but for the HR Pro, navigating this complex and crowded market has to seem kind of overwhelming. There are simply so many options and choices here that it can be difficult to determine just what solutions are best for a particular organization.

If you find yourself at the diner in Jersey the recommendation is easy, order a Taylor Ham, egg, and Flickr - feralboycheese on a hard roll, you won't be disappointed. If you are a small business looking for a new collaboration solution, well, order a Taylor Ham, egg, and cheese on a hard roll, and be prepared for quite a bit of research and exploration.

Worlds are colliding, Jerry!

Last week I posted a question called 'Ask the Tweeps', essentially wondering where folks are turning when in need of information and expertise. As you would expect, the answers were pretty mixed, people rely on internal co-workers in many situations, and turn to their external networks for 'new' or 'different' questions that may not have in-house sources of expertise, or if they are interested in more diverse or alternate perspectives.

This is altogether natural and expected, and I think understanding the 'mix' of expertise and information requests in an organization could certainly become an important part of a company's talent management efforts. 

Just how often are our employees reaching outside the organization for information and advice?

What kinds of things are they asking?

Do we really have that knowledge in-house already, and our employees just don't know how to find the right person or resource?

And finally, how might the organization capture and leverage employee's external connections for longer-term organizational benefit?

Should they even try?

Lately a number of collaboration and information platforms that are designed to better enable employee communication and knowledge sharing have started offer at least some insight to these questions by  incorporating 'external' sources of content like Twitter updates, Delicious bookmarks, and FlickR images.  Solutions like Socialcast, Obayoo, and to some extent Socialtext all offer the organization the ability to combine or mash-up classic 'internal' content and communication with heretofore 'external' data that has been traditionally viewed as private or personal in nature.

Conceptually, this makes sense.  If knowledge workers find a great website that helps solve a problem, it should be bookmarked for others in the company to potentially leverage.  If an image on FlickR helps to explain a concept, then it would be great for the rest of the team to know that it is available.

But while the 'blending' of internal content (discussions, status updates, documents) with external content (Twitter feeds, RSS feeds from blogs, Delicious, YouTube. etc ) can make sound business sense, I wonder if many employees are prepared and comfortable to open up in this way.

These new collaborative tools try to help organizations exploit what everyone knows is going on: employees rely on external sources to accomplish their tasks. But will employees be willing to more fully open up their private and personal worlds to others in the organization.  Will they need to create dual accounts on these external sources, so that their 'company' Twitter feed can be shared with the organization and their personal Twitter feed can be kept private?

Worlds are colliding more and more each day.  It may not be as easy as it seems for organizations to take advantage, just ask George Costanza.

I don't care what it says, who else has seen this?

One of my very first 'mentors' in the corporate world was the CFO of a rather large division of what then was AT&T. Whatever is left of that group today would likely be part of Alcatel-Lucent, although it is really impossible to say what became of the department.

Back in the day before ubiquitous e-mail, important information was circulated via the old-school written memo.  The memo was usually typed out by an administrative assistant, copied, and finally distributed to two 'lists' of people.  The 'To' list and the 'CC' list. Generally speaking, the folks on these lists would be the only people to see and read the contents of the memo.Flickr - mil.

Back to my CFO. Whenever a memo of any kind crossed his desk, he immediately glanced at the top of the first page, (where the 'To' list of names was), and then quickly paged to the end of the memo, (where the 'CC' list of names was).

Once I observed him doing this and asked why he instantly paged to the end of a particular 5 page memo and he replied,

'I need to know who else has this information, before I read it, and before I even think about making a decision about it'. 

He really meant it too.  His approach, strategy, and decision making process was heavily influenced by his perception of 'Who else knows this?'.  Back then, information could be controlled, e-mail was not universal, there was no wiki, blog, or Twitter to spread and share information.  To use the old cliche, knowledge was power, and in many cases it was hoarded and exploited for the wrong reasons.

That all seems like such a long time ago, and I would like to think in the modern organization, supported by almost limitless media and technology to share and transmit information, that the 'Who else has seen this?' question is ridiculous and unimportant.

But I am not so sure.

I still think that the 1970's mindset of the closely guarded memo still endures in many organizations. I still sense that information, and access to those who have information is not as free and effortless as many of us would like to believe.

I hope that my organization, and yours, can get to the place where the answer to 'Who else has seen this?' is typically, 'Everyone'.

I hope that soon, even asking the question is ridiculous.

Trapped in a Box

The company organization chart.

Every company has one. There is an entire class of software applications to help companies generate them, (my favorite is OrgPublisher from Aquire), and maintaining them and making sure all the correct names are in the correct boxes and the lines are all connected properly can be a full-time job in larger organizations.

In some organizations the chart is sort of a sacred document, informing managers and employees of crucial information like who is in charge of what, how many folks do job 'XYZ', and who might be the likely successors for a given person if they were to move to a different position, or leave the organization.

But organization charts, can be limiting, and can effectively 'trap' individuals and teams by defining them in too Flickr - Stefannarrowly drawn roles. If the culture of the organization is not inherently 'open' or 'collaborative', then the chart is a tool that can also serve to maintain separation in the organization. If your position on the organization chart is Web Designer reporting to the Marketing team, then you do web design work for marketing, and may not typically get much exposure to the web designers that work on the company's internal sites or intranet, as the responsibility for those functions falls elsewhere in the organization.

With the growing popularity and increase in the easy availability of tools and technologies to facilitate collaboration and communication, it seems very likely that many medium to large organizations have multiple, and isolated activities underway to explore and deploy these kinds of tools.

A mid-sized organization that I am familiar with has at least four different wiki platforms deployed in various parts of the organization. These are all set up, maintained and administered locally, and some are successful and some are not. But even the successful ones do not really have much of a chance to impact or influence the broader organization, chiefly because of the culture and the strict adherence to the organization chart. The company does not have the ability to 'break free' from the constraints of the chart, and individual local administrators of these wikis are not allowed or encouraged to work with other parts of the organization to share information and potentially work towards developing a solution that may benefit the organization as a whole.

It is actually very ironic that the recent availability and relative ease of adoption of tools to promote collaboration are bringing to light the lack of collaboration across this organization.

The number of tools for collaboration and communication are growing everyday, but if the organization still clings to the org chart, like construction crews cling to blueprints when erecting a building, then in many cases the full potential of these tools will never be realized.

A Collaboration Experiment

The past couple of weeks I have organized and have been monitoring a very small pilot of Yammer in our organization. For those who may not be familiar, Yammer is positioned as 'Twitter for the enterprise', a service that allows people to provide short text updates, ask questions, and provide information to their colleagues in (nearly) real-time.  Unlike Twitter where updates are typically visible to anyone on the service, Yammer networks are restricted to members of individual organizations, by means of valid

possession of a valid e-mail address from the company domain.

I managed to get several team members to register at the site, join the dedicated, private group that I created to keep most of their updates 'private' and internal to the group, and also walked everyone through the steps to download and install the Yammer desktop client.

So far, the adoption has been decent, and I think there is at least a 50-50 chance that Yammer will eventually become a reasonably important part of the every day communication process in the team.  But there are already a few key lessons that I have drawn from this brief experiment, lessons that I think would be broadly applicable to most other new 'collaboration' technologies (wikis, internal networks, or idea markets) that you may try and introduce into the organization.

Lesson 1 - Tools won't create collaboration immediately

Most of the work that is done by the team members has typically been done individually.  The practice and culture of primarily individual effort doesn't miraculously change or morph just because a flashy new 'collaboration' tool is available. Analysis of the traffic on the Yammer network reveals a modest amount of communication on actual 'work products' primarily centered around simple 'status' type questions and answers.  The tool has not immediately impacted the group to foster or encourage more collaborative problem-solving, development, or design.  That may come in time, but the tool itself won't make that change happen overnight.

Lesson 2 - The right people need to be included

One reason the collaboration levels inside this group are relatively low, is that much more interaction and collaboration actually occurs with folks outside the group, the customers for this team's development.  Inclusion of some of the key customer contacts in the pilot would likely lead to increased traffic and added value on the Yammer network.  In time it is anticipated that the 'wider' network will begin to communicate and collaborate more freely. So when organizing a pilot program, don't be afraid to cast a wider net in soliciting and including participants.

Lesson 3 - Simplicity is more important that almost everything else

Even with a dirt-simple tool like Yammer, I have had to spend quite a bit of time explaining how the tool works, how to get signed up, and how to download and configure the client application.  There were several moments of confusion and mis-steps along the way, while none of them are that complex, they still introduce unneeded friction into the process.  Any participants that are perhaps unwilling or disinterested in the pilot, or are slightly technology averse, may very well be completely turned off by these issues.  Whatever tools you plan to introduce to the organization, make sure you keep them as simple as possible, at least initially, if not forever.  Find the one or two key features you need, find a tool that supports them exceedingly well, and put everything else on the back burner. Simplicity is essential.

Lesson 4 - But not as important as executive support

This experiment may be successful, or it may not.  But I am 100% sure that if the 'right' senior executive found out about it, and was not comfortable or supportive, the project would quickly end. Once your collaboration project moves beyond just a few users 'playing around' and starts to gain some traction in the enterprise, you have got to secure senior level support.  This is so important. To have an executive sponsor that can break down barriers, protect your project from the budget ax (maybe), and serve as a champion in those meetings that you don't get invited to may be the determining factor in your success.  The most crushing and disappointing outcome sometimes is the hammer coming down from on high ending your project due to the lack of the right executive support.

Lesson 5 - You won't know unless you try

In my example, we are experimenting with Yammer, a free online tool.  The only cost is the internal staff time spent testing, explaining, and documenting the registration process.  The 'barriers' to this type of project are therefore extremely low. So consequently, it is an easy tool to try out.  Not all technologies in the collaboration space are completely free, but most are relatively inexpensive compared to most other enterprise software.  Wikis, internal social networks, and hosted blogs can all be tested and experimented with at modest costs. Many technologies have 30-day free trials that give you just enough time to get the feel of the technology.  You really can't just discuss these technologies to determine if they truly will be effective and important to your organization and deliver on the promise of increased collaboration and communication.  You really have to give them a 'real' test.  Fortunately, most of these tools are offered in the SaaS mode, do not require an upfront license fee, and allow you to walk away from the project with no penalties at almost any time.  But you may need to secure at least some funding to truly give these tools a try.

So far our project is progressing, and I anticipate over time, if we can keep in mind and learn our lessons, it will be successful.

I would love to hear what some other technologists have to say about the key lessons in introducing collaboration tools to the organization.