Collaborative climate in Romanian enterprises

A few weeks ago, I invited about 100 friends to participate in an online survey on collaborative climate in Romanian enterprises. I also asked them to forward the email to friends and colleagues. Vladimir Oane, Bobby Voicu and Cristi Manafu wrote on their blogs about the survey. The response was great – 278 people answered the questionnaire. Many thanks to all who participated! You were incredible!

As promised, all of the results are available for anyone to use. You can download the bar chart report (in English) and my interpretation of the results (in Romanian). Just drop a comment or email if you want the complete raw data to process for yourself (the answers are, of course, anonymous).

If you’re busy, here’s a snapshot of some results:

• We really want to share knowledge (91% of participants enjoy sharing knowledge).
• We think that our organizations demand the results of knowledge sharing from us, but don’t give us the support or the tools we need.
• We can communicate more openly in our team than in the organization as a whole, but the overall collaborative climate score is lower for the work team than for the organization. This is one of the most intriguing finding of the survey.
• There is a scary disconnect between the way managers view collaborative climate and the way their subordinates see it. Managers are much more optimistic across the board. Do you think that’s due to “rose-tinted glasses” that managers wear, or to a more positive environment for managers?
• 78% of managers think they are encouraged to express opinions even in disagreement with their superiors, versus only 60% of general employees. Why do you think that is so?
• The size of the firm you work in doesn’t seem to matter at all!
• Between the ages of 25 and 35 we become much more pessimistic about collaboration.
• 40% of respondents are NOT able to find out what similar work has been done in the past when embarking on a new project. This means that a huge amount of work is re-created from scratch, instead of being reused.
• 45% of respondents find that multiple people in their organization are working on the same problem independently. Again, a huge waste of resources. And the problem is more acute for large companies, compared to smaller ones. What’s surprising is that the medium-sized companies (50-100 employees) are the worst off. Perhaps because they’ve outgrown purely informal collaboration, but have no procedures in place?
• Only 64% of respondents organize regular meetings with the purpose of sharing knowledge. Most of the knowledge sharing is performed via informal discussions (87% share knowledge in this way).
• 40% of the participants are NOT able to keep their colleagues up to date with work trends and important news.
• We don’t seem to feel that we’ve learned a lot working in our firms. Only 79% think that knowledge sharing has helped them learned; only 50% think that most of their expertise was gained within the firm. We perceive that knowledge sharing has more benefits for the firm than for us.
• We all think we are great at knowledge sharing and collaborating, but work with dense loners and knowledge hoarders (77% of the participants accuse their colleagues of preferring to work alone).

For more in-depth analysis, you’re welcome to download the reports.

Office 2.0 – Online communities

Finnern told us the key to having a large number of community participants is to give out iPhones :D

The first question: where do we start? We are in a different place than we were; we’rea learning how social communities work. The rise of social web is driven by its utter simplicity – driving enormous growth. Most of the content is created by “us”, propelling the peer production model. The blogosphere is the biggest conversation in the world.

Self-formed communities – ex. KatrinaList. CafeMom is a sample of a real-people social network vs. SV network. Average people in an organization will not have time to adopt these tools. This is something that we have not yet found a solution for.

Problems: the 2% troublemakers; the 9x problems (new tools must be nearly 10 times better for people to have incentive to switch – Harvard research). Many are concerned that 2.0 will decrease productivity [and we're all so excited about how they increase productivity?].

Diane Davidson – found that when people say bad things, approaching them directly solved the problem. After some time, WebEx found people asking “can we do this in a community?”

Robert Duffy – Intel is opening up, looking at social media to make sure they keep being relevant. Participating not just internally but also going out to other places where discussions are going on as well.

Mark Finnern – finds that most of the growth on SAP’s communities for business processes consulting comes from word of mouth.

Josh Hilliker – when launching Intel vPro, wants to talk to the people within partner organizations who are bloggers passionate about silicon. Research is moving from talking to individuals in enterprises about what they want – to talking to the community as a whole.

Mike Walsh – talks about companies outside of the usual adopters (hi-tech industry) looking at online communities and obtaining great benefits?. [This is something that I am very interested in. Does anyone know of a company in the construction industry using enterprise 2.0?] Mike gives two interesting examples that I will have to look at: Dwell.com and Autodesk communities. I wonder

Comment from the audience: “Community can be a nice way of saying that we are shifting the burden of tech support unto our customers.” Diane sees it more as broadening of what gets done, a win-win situation. Offering joint ownership of our products [Apple, where are you?] Josh makes a good point that community is faster than support.

Audience asking for 5 tips on how a start-up can build a community. Answers:

• start with a great product
• one-on-one relationship
• listen and react so people feel heard
• hire your top contributors
• set your goals so people internally are on the same page
• find your greatest advocates
• market the community
• keep it open as much as possible (a minimum of private areas)
• reward people for providing good content and participating

What resources to allocate for launching a small community and growing it?

• do you want to build your own platform or buy? integrated or best-in-breed?
• WebEx had almost no resources internally
• need to find people internally who are willing to change the way they work
• Intel has a few positions of “Community Manager” (Josh’ position). Very very nice!
• Josh also makes the point that launching communities in Intel is very much like a start-up
• Intel has a goal of shifting the content to the community and ultimately spinning it off

Very nice panel, thanks to all the panelists!

More on Meetings on a Wiki

Bill Ives of the FASTForward blog adds some very insightful comments to my earlier post on holding meetings on a wiki.

Bill has an interesting point regarding notifications:

I would add to also allow this [notifications] to go somewhere besides the email inbox. I am not excited when a heated discussion on an email group suddenly drops twenty messages in my inbox. Take advantage of the common workspace here and do not drag in the sins of email spaghetti with its overlapping tangled mess.

I fully agree. I love RSS. I would, however, approach it in a differentiated manner depending on the lifestage of the wiki and people’’s level of familiarity with it. If participants are not used to RSS, I’d rather give them updates via email than wait until they learn to use RSS. After they get smothered in email, they will also be more likely to see the use for RSS :D

Stewart also comments:

One suggestion with the point about structure – it’s important to be careful to use as little structure as possible, and make sure people know that they can change the structure of a page if it makes sense to do so. In other words, the flexibility of the wiki is what makes it such a great event planning tool.

Yes, the simplest structure will usually work the best. Once a community has been using a wiki for some time, structure can be very sketchy and free-form. I find that with a community that has only just started with a wiki, an empty page will not trigger participation. Populating the page with some content – breaking the ice, as it were – gives the discussion the traction needed to get going.

How to export LinkedIn connections to Facebook

Facebook looks tantalizing, very easy to populate with the content I am already producing elsewhere – but I was struggling to start using the “social” part of the latest social computing fad. This quick tutorial on importing LinkedIn connections to Facebook filled in this need:

We do know of an easy way to get your Linkedin Connections into Facebook in 2 minutes flat.

• Click on Contacts (after you have logged into your Linkedin account)
• Scroll to the bottom of the page and click on “export connections”
• Download the file as a CSV (Outlook) and save to your desktop
• Login to Facebook
• Click on Find Friends
• Click on “email Applications” and upload the saved CSV file

If you have any contacts on facebook from Linkedin, facebook will find them and display them and give you the option of inviting them to be your facebook friend; and send them an invite for you. Works like a champ! It will also invite all the other people that are not yet members of facebook from your Linkedin connections…

Source: Linkedin on Facebook?… At least there is a Linkedin Facebook Group
at FaceReviews.com: Facebook Application Reviews, Facebook Widgets, Facebook News
Address : FaceReviews

How to hold meetings on a wiki

In the days immediately following our first World Cafe, our team couldn’t find time to hold an evaluation meeting. We decided to try holding the meeting on our wiki, and found that the results were better than in a traditional meeting. Here’s what we learned:

1. Allow enough time for the discussion. While a traditional meeting can last as little as a dozen minutes, the time-distributed nature of a ‘wiki meeting’ makes it necessary to allocate at least one day, depending on how busy team members are with urgent projects. Don’t expect people to drop everything and participate on a wiki discussion. We created the wiki discussion as soon as the World Cafe ended, and within 24 hours had obtained input from all team members.

2. Offer structure. As you create the wiki page, populate it with questions and issues. Make the structure simple and specific. Add content, don’t just post the meeting agenda. Include all relevant information, spell out your opinions on each subject and ask for more information where necessary. People are much more likely to respond if all they have to do is agree / disagree with an opinion or answer a specific question.

3. Encourage participants to openly sign their contribution. Mediawiki software parses three or four tildes (~~~~) into the signature of a participant to a discussion. A simpler option is to simply preface each comment with “Ron says:…” While most wiki software allow readers to find out who performed each edit, openly signing content goes a long way to keep the tone conversational.

4. Provide participants with tools to follow the discussion. Whether your software produces RSS feeds or simply sends email, make sure everyone knows how to set up frequent notifications. (Wouldn’t it be great to have wiki software produce Twitter feeds?)

5. Manage the discussion. While a moderator is usually not necessary once you have created structure and obtained participation, a discussion will often require participants to gather additional information or perform external tasks. Someone might have to install and demo some software, make some phone calls, cross over into the office of a non-participating coworker to obtain his expertise on a particular issues, or simply dig up some information. While participants will often self-organize, it is your job as the initiator of the discussion to follow through. Above all, make sure you keep contributing with any information or ideas made necessary by the discussion.

6. Capture actionable items. Regardless of the project management system your team uses, it is very important to capture and act on any requests made during the discussion. At the very least add ideas to a “To consider” or “Someday” list that everyone can see. Discussions on a wiki are available for reference, and few things discourage people from participating as much as the evidence that their contribution was not followed through.

7. Declare the meeting closed. Give participants 3-4 hours’ notice to put in a last word. After, that, formally close the meeting. Post a notice at the beginning of the wiki page. Don’t leave the conversation open-ended. It’s discouraging.