Bas Reus' quest on self-organization and online collaborative spaces

Coordinated chaos

Posted in online collaborative spaces, self-organization by Bas Reus on September 22, 2009

Why do some social media initiatives make it, and others not? The success can’t be assured a priori. Take the example of FriendFeed. I never used it, but the technology was outstanding people say. It was the first service that made use of realtime updates for example. Of course, for the founders things turned out quite well, because Facebook acquired it recently. For open social networks, mass is needed. People can choose their service freely, and positive network effects strongly influences who will win or lose.  The more people you know use Facebook, the more likely it is for you to use it too, and to abandon FriendFeed for example. You’re not really locked-in like you are with using Microsoft Windows and Office, although that latter lock-in is declining with the advance of free web-based alternatives.

YinYangIt is different for corporate social networks. First, it is less social. Not everybody in your life can be connected, just your colleagues. Second, there are mostly no alternatives available. The company chooses to introduce an Enterprise 2.0 application, custom made or out of the box. It’s there just for the company. Third, for the most people, it will only be used during working hours, not very much in the weekends. Fourth, it serves different purposes, like more effective collaboration, not just sharing cool things or experiences that are very funny. However, when people share those it’s a sign they feel comfortable out there. Fifth, there are even more differences. All these differences are a given, and are important when designing and introducing a corporate social network.

Traction Software explains it very well on their blog. INNATS. It’s Not Not About The Structure. Structure is important, but too much structure is a problem, as well as too less structure. Hence Not Not. Starting from scratch is not a good idea, but reinventing the wheel over and over again isn’t either. The right amount of freedom to be able to express your creativity, to find the right information in the chaos, and coming back for more on a regular basis because it contributes to your job and the tasks you have, that’s an important factor for success of a corporate social network.

Setting the scene is what it’s about. Or better, knowing scenes a priori that could be the starting point of a flourishing corporate social network. You never know if it will flourish, but it pays to look for the right balance between coordination and chaos. Like with open social networks, positive feedback can make it happen faster once the right balance is found. And the initial state of the network has great influence on what wll happen later on, like the butterfly effect (great movie btw).

Advertisement

Interview with Jordan Frank from Traction

Posted in online collaborative spaces, self-organization by Bas Reus on September 15, 2009

TeampageThe recent discussion on ‘Self-organization defined‘ where Jordan Frank from Traction Software commented on, triggered me to ask him some questions on the Teampage product in relation to self-organization. And as you can notice from the title of the blog, I’m interested in online collaborative spaces as well. Luckily, Jordan was so kind to answer my (many) questions. This post in an interpretation of some of the topics we discussed.

When I asked Jordan to explain Traction in maximum 100 words, he said: “Traction TeamPage is an enterprise social software platform. While TeamPage offers the wiki, blog, tagging, discussion and document management features people seek in a social software or collaboration platform, TeamPage goes beyond traditional expectations to deliver critical functionality that is need by most, if not all, enterprises. Simple examples include social tagging across differently permissioned spaces, content moderation model, a view/query model that lets you easily organize pages around your use case or work objectives, and an audit trail that goes beyond edit history”. The video below explains some more.

I’m really impressed by the loosely organized pieces of information in Teampage. One example is the manner in which it does not type content so finely that a given page can be a Wiki page or a Blog post or a Comment – rather, each entry flows into the blog-stream and may be assigned a Wiki page name or may have a relationship which makes it appear as a comment. Another example is the treatment of every paragraph as an object which can be tagged, linked to or commented upon. This solves a ‘problem’ I run into in my daily life, by having to choose when to use a wiki, blog, comment, tweet, or resort to an e-mail or whatever, the place (or silo, see a great story about Silo Smashing and Sharepoint) unnaturally confines the content, or the conversation. That’s the promising aspect of Google Wave as well, I think. Jordan thinks a little different of Google Wave:

I don’t think Google Wave is the holy grail in this respect. I see it as a protocol for interaction and threading. While it greatly improves item level discussion versus email, it won’t necessarily span workspaces or offer anything close to the capabilities that TeamPage does. But we can use it to great advantage – much better for capturing synching external conversation and internal history. Should be fun to implement. We are making heavy use of Google Web Toolkit in our next interface.

Clients of Traction Software use Teampage for a number of purposes such as for project management, intranet sites, market research, competitive intelligence, communities of practice and as a knowledge base. Jordan says:

The system easily organizes around use cases rather than shaping the workspace based on the technology used to implement it. As one example, rather than having a ‘blog’ and a ‘wiki’, an HR space may have a ‘Policy’ section and a ‘Questions’ section. That space may also be moderated, which may be a requirement for the organization – otherwise a less capable wiki just wouldn’t be allowed.

When we talk about self-organization, it is very important to set some constraints, or to remove them, all in order to let people ‘organize’ themselves easier. That’s what the consensus on the ‘Self-organization defined’ topic is. Translated to software or online collaborative spaces, I asked Jordan how this can be done in Teampage.

You can set constraints by providing templates, a starting set of labels (tags) and sections. Sections are like portlets in a space. A Project management team may have sections for meeting notes and issues, for example. Each section may be associated with article/page template. So, a meeting agenda template may launch from a meeting notes page section. If we talk at having freedom for the users of the software, there is any freedom you would expect in any other blog/wiki/tagging environment. The starting sections and labels in a template are just that, a starting point. A person in charge of the space can enforce some controls, or leave it fairly open.

Defining self-organization is not very straightforward. That’s one of the reasons that the earlier blogpost generated so much discussion. When I asked Jordan to his understanding of self-organization, he said:

In my context, it’s enabling individuals to organize themselves and their content without constraints that they don’t want. This acknowledges a need for constraints that may be helpful. This acknowledges that an organizational structure (be it top-down or matrix) may be necessary or simply helpful.

Key is to make use of existing organizational structures, and play with constraints. Keep them, make them or bypass them where necessary. Structures can always change, and Jordan explains this with a sports analogy, when I asked him about his earlier statement that self-organization often works better when there is some starting structure. What did he mean here?

I mean that a blank white page is very intimidating, and doesn’t necessarily assist team play. To use a sports analogy, Zone defense is a bit less structured than man-on-man. Zone defense requires constant adjustments and on-field co-ordination. So, there is a structure indicating an area a player defends at the start, but the structure may change as a play is executed and the players self-organize to adapt. Out of 10 types of activities, a project team may discover that their most pressing need is to document requirements and discuss issues. You may structure a space, initially, around these two use cases and you may go as far as gaining management backing (or mandate). At any time, individuals may go beyond the starting structure by posting other types of content, but they start by creating some gravity and a consistent process for documenting requirements and resolving issues.

It’s great that Teampage is very flexible concerning creating a starting point, and as I mentioned earlier in this post, I’m really impressed by the loosely organized pieces of information in Teampage. But still, software alone is not going to make a difference. In my view, it’s an important part of a greater process. How do people use the software, and how is it going to make their (professional) life easier, more efficient, more fun, in other words, what is needed to help both the company as their employees (and everybody these people work for) to benefit? What is needed besides software? And where can software help to fulfil those needs? Is it part of a company’s culture? I think I will end here with these questions in mind……