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 – Knowledge Worker 2.0

Stephen Collins has an interesting point about the KW 2.0 being cross-generational. They wnnt to know how they can give and get value. This is perceived as a lack of loyalty – when it is in fact just looking for value. They will then walk out the door with a wealth of unshared information.

How to make sure they are engaged? Give them a community – let them collaborate will colleague. Need for awareness; these people love to share. People get demoralized at work when the effort they put in doesn’t get recognized. It is very important to have a Learning organization culture. Silos kill knowledge sharing – you need to kill walls. KW 2.0 dont’ have respect for authority: this derives from knowledge rather than power. Need to have management validate the new working style. The metrics around what you’re doing need to be changed: the output should count, not the number of hours they spend there.

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.

Four wiki implementation take-aways

Nathan Wallace posts a great case study on creating a wiki intranet at Janssen-Cilag. The approach is refreshingly common-sense. My main take-aways:

• Pre-implementation conversations are a great way to create excitement and obtain personal commitment to maintain content. Also helpful: sharing articles that give a glimpse into the possibilities.
• Use the “social force control” argument when pitching a wiki: if social forces keep people from sending out weird email messages (which colleagues do not see), social forces will act more strongly to keep people on target in editing a wiki page. Also helpful: pointing out that changes captured in a wiki and monitored will be much easier to manage than the quiet behavioural departure from “norms” experienced by many companies.
• Use Wikipedia as an uber-known example. This provides a very positive point of reference for a new technology that is disconcertingly free-form.
• Offer ultralight training – Nathan was able to offer the necessary training in 5 minutes. After that, one-on-one coaching and a help section provide ongoing support. Also helpful: Begin with a basic help file, and as people have more questions, explain – then ask them to update the help section. People who are only just learning how to do something are much better equipped to explain to their peers than an “expert” is.

Nathan’s approach to content ownership and maintenance is remarkably simple and clear:

1. If someone isn’t willing to maintain a piece of content, it can’t be that important to the business.
2. We happily show people how to do things with the site, but we don’t do it for them.
3. Occasionally we highlight sections of the site on the home page, which is a great way to drive the defacto owners to clean it up a little.
4. We encourage people to have high expectations for content on the Intranet. If something is missing, please report it to the appropriate area of the business, or better still, add it for them.
5. The answer to verbal queries for many departments has become, “it’s on JCintra [the wiki/intranet]“. This reminds people to search first and ask later.
6. In the end, the quality of content in an area is a reflection on the defacto department owner, not the Intranet itself.

“It’s on the wiki!”

The one thing that most discourages team members from actively participating on a wiki: being asked to provide – verbally, via email or other direct communication – information that they have already written on the wiki.

To counter this: give everyone free license to say again and again – “It’s on the wiki!”. Encourage wiki participants to NOT give out information through another medium.

Bonus: any technical issues that keep the wiki from being fully functional will surface and be solved much sooner.