Online Groups Blog

If you have a mailing list running on GNU Mailman, and you’d like to get the benefits of OnlineGroups.net, we would be happy to migrate your mailing list.

OnlineGroups.net is a great way for your group members to collaborate using email. It provides an email address and an inbox for a group, just as email provides those for individuals. Tools that do this are called Mailing List Managers. OnlineGroups.net is not the only Mailing List Manager. Others include Yahoo! Groups, Google Groups and the old faithful GNU Mailman.

GNU Mailman is an open source Mailing List Manager that has been widely used for over ten years. It is easy to install and works well, but it lacks some of the features of OnlineGroups.net. Most notably, where Mailman has separate web interfaces for viewing posts and changing settings, OnlineGroups.net has a single web interface where users can search and read posts, as well as edit their settings. Not only that but with OnlineGroups.net, you can post from the web interface, while with Mailman you can not. So OnlineGroups.net functions as a Web Forum as well as a Mailing List Manager, while Mailman is mainly an email-based tool. (For more on this, check this detailed comparison between GroupServer and Mailman 2.)

The good news is that is just got easier to migrate your mailing list from Mailman to OnlineGroups.net. We recently released a tool for migrating Mailman lists as part of GroupServer, the open source software that underpins OnlineGroups.net.

If you prefer to have a hosted online groups site, you can migrate your users to an OnlineGroups.net site yourself.

The process is easy.

• Start an online groups site for your organization.
• Start the groups you need on your new site.
• Get the email addresses of your group members from your Mailman site and invite those members to join the groups on your new site.
• When your users accept the invitations they will be able to make and receive posts on the new site.

If you would like to migrate your archives, let us know. We are happy to migrate your archives from a Mailman Mailing List for free, if you purchase a year’s subscription for a 160 member or larger site.

We can even help you migrate your custom domain from a Mailman list to an OnlineGroups.net site.

To get this started, or if you have any questions about migrating a Mailman list, get in touch with us.

Building collaboration is difficult. It involves helping others before they help you. To do that, you have to trust that the others are likely to help you. That trust grows when they help you. Once this positive feedback loop established is hard. Someone has to take the risk of beginning it. Taking that risk is a leap of faith: of faith in the possibility of collaboration.

Here is a story that helps to maintain my faith in the possibility of collaboration.

A lifetime ago, my partner and I had a young child. We both worked or studied full time. We needed help with the care of our child, but we were poor. Through our networks we met a young woman who seemed trustworthy and was willing to look after our child for very reasonable pay. Her name was Leanne.

We told Leanne that her job was done if we came home and our child was safe and content. We apologised that we could not pay more and made it clear that Leanne was not expected to do any housework.

When we came home, the fire was lit, gentle music was playing and Leanne and our child were doing an activity together on the floor. We were delighted. As the days progressed, we began to come home to a load of washing on the line, or a clear bench that we had left in a rushed clutter that morning. Touched at Leanne’s thoughtfulness and generosity, we found some more money to pay her.

Lee Timmins of Management Today lists ten reasons that he thinks ditching email is the way to go.

I heartily agree with one of the problems that Lee points out. Email by itself is not great for group collaboration. Lee’s other nine reasons are almost the exact opposite of what I believe is the case. Here is why nine of Lee’s reasons are actually reasons that ditching email is not the way to go. Then the one about how email is poor for group collaboration, and how to solve that problem.
 
1 Time. The reason the average employee receives over 50 emails a day is that email is such an efficient means of communication. Before email, it was simply impossible to manage the amount of communication that we manage today. If you replace email with another medium, you will not make the communication go away. You will simply migrate the workload to another place. If you can find a medium that reduces the cost of communication below that of email, by the same process that brought us 50 emails a day, you will get even more communication.

2 Bad Management. Email has no monopoly on perfunctory exchanges. Poor management via email is not a fault with email, it is a fault with management.

3 Technology. I see no evidence that email is no longer the most efficient one-to-one and even one-to-many communication medium. Other media exist, and the web is great for one-to-all messages, but you have to check each one of them individually. The likelihood that you will forget to do that is managed how? By sending notifications to email. BYOD is an excellent argument in favour of email as all its flavours talk to each other.

4 Distraction. Email is as distracting as you let it be. But it has simple but powerful metadata that makes it very easy to parse. Good email enables you to assess it quickly without even opening it. Bad email you can quickly delete. We get more messages. Deal with it.

5 Stress. Email does not cause stress any more than telephones do. Work and conflict cause stress.

7 Communication. It is not rocket science that poorly worded or structured messages can take time to decipher. Once again, this is not email’s fault. Garbage in, garbage out applies to any communication medium. In fact, email is an excellent medium for taking time to prepare a communication. It by definition not real time, so you have more opportunity to think before you post. Of course email is not as rich a medium as face to face or video. And of course chat, microblogging, and many other media have their place. Let us just not dismiss email as inherently having any more problems than other media.

8 Prioritisation. Lee Timmins seems to have missed the conversation about email as an activity stream. Sure there are many other, and probably better activity streams, but email is the one we’ve got. The one we are all using all day every day. Whatever tool you use, you have to learn and manage it. Prioritisation is hard. I’ll bet you that finding people who don’t have well-developed hacks for prioritisation using email is harder.

9 Learning and Development. Yes, videos and learning resources are useful where the effort has gone into making them, and where they match the learning need at the time. But we know that most learning happens in context through interaction with others. Asking and answering questions, in other words. And email is fantastic for that.

10 Smarter Working. I don’t think anyone could argue with the idea of thinking about your work or even choosing better tools. There are many many tools for specialised task. Sadly, I think they all struggle from overwhelming competition from pretty much the most versatile generic communication tool we have ever had: email.
 
Which brings me to the one point that Lee makes that I agree with.

6 Collaboration. Yes, there are better tools for real time collaboration. For asynchronous collaboration among two or three people, email is great. But for group collaboration it sucks. And Lee is exactly right about why when he writes that “good inbox habits like filtering and storing messages in folders can hamper knowledge sharing”. Tucking group email away in a private store is of far less use than building a shared resource. Email suffers from the lack of a shared repository for a group. It also has no way to consistently ensure that messages are shared in a defined group.

In conclusion, email is a highly useful all purpose communication medium that is massively established in the world of work. It is very hard to get people to migrate from email to another medium. Email does not however provide support for group collaboration.

It is for exactly these reasons that OnlineGroups.Net built a web-based mailing list manager. Mailing list managers allow people to use email to collaborate in groups by providing an email address and an inbox for a group. OnlineGroups.Net enables people to participate using email or the web, in whatever combination they prefer. It provides a defined membership list and an online shared archives for message and files with configurable privacy.

Enterprise Social Networking “is the new battleground for all enterprise collaboration vendors:” writes Richard Edward in Moving on from a culture of collaboration by email. There is no doubt that Enterprise Social Networking (ESN) is growing, but ESN does not replace existing enterprise collaboration, especially collaboration using email.

Real Life meets Real Work

Social Networking comes from the Web. It comes from sites like Friendster, MySpace and Facebook. These sites grew to connect people with their friends. The connections are largely based on stories from people’s lives, told with short posts, links, images and videos. The purpose is predominately around leisure and social connection. More recently, Twitter has provided a lightweight complement to social networking sites, and has come to be used for work as much as real life.

Enterprise collaboration comes from no online collaboration at all. Organisations have always been plagued with the inescapable reality that as they grow, it becomes harder and harder for them to function as a single unit. You have to slice up the organisation in so many ways: geographically, into tiers, into departments and teams. And each of these divisions comes at the cost of collaboration. Historically that has not been so much of a worry, as we mostly assumed that if everyone just worked on their own tasks with the minimum of discussion, things would work fine. This is one reason that email has become so successful. It is great for communicating with individuals to get a job done. For group collaboration, it is not so good — in fact email actually discourages group discussion by making it really hard.

The Web or Email

More recently, we have realised that technology might make it easier to collaborate in groups, so that organisations could reduce some of the efficiency and effectiveness constraints of scale. The enterprise collaboration market has grown to meet this demand. But it has never quite overcome its arch-rival: email. Social networking has arisen from the web, where posts are relatively public and the large websites are free because they are paid for by advertisers. For many participants on social networks, web-based systems are the first and only form of online communication that they have become familiar with. People at work in organisations, on the other hand are used to email. Systems that do not use email have a hard time getting off the ground. If just one key team member does not switch to using the new system, the whole team is pulled back to email, despite its flaws.

Discover the Unknown or Achieve the Known

People participate in social networking and group collaboration for different reasons. In group collaboration the goal is to complete known tasks or share knowledge in a defined area, with the people we are required to work with. In social networking, the goal is to discover things we don’t already know, and to expand our social connections.

Transient Public Groups or Persistent Private Groups

Social networking and group collaboration occur in different social contexts. Group collaboration happens in persistent groups: usually teams and communities of practice. The groups usually collaborate in private, where greater trust can develop and tasks can be completed before they are delivered outside the group. Social networking takes place in networks that sprawl across the boundaries of persistent groups and organisations. It necessarily takes place in a more public setting.

The kinds of media used for the two tasks are quite different. Both use regular text, in posts of varying length. But group collaboration is likely to involve exchanging office-documents, often in successive revisions. Social networking, on the other hand, is more likely to involve images, audio and video.

Individual or Group Orientation

In essence, both are networks, but they have different orientations. A social network is a network of individuals where the links between the individuals constitute small transient groups. It is like a web-based public equivalent of email. Collaboration systems are a network of groups, where the individuals are the links between the groups. Both are necessary. In organisations, both have the challenge of unseating their long-encumbent competitor: email.

Whatever technology you use, your main challenge in getting collaboration started is going to be social. So you may as well start using simple technology and work on the social factors.

Building Collaboration is a Social Problem not a Technical One

Collaboration one of the holy grails of organisations. Everything will go so much better if we collaborate. But in practice, collaboration is hard. It is hard to do and hard to get others to do. It is not hard because of poor technology. There is plenty of great collaboration technology. It is hard because of people and the environments that we work in.

Collaboration involves helping other people, often before they help you. If you help other people enough, they might start helping you. Or they might not. Most people in organisations are busy. Busy achieving their individual goals. That’s what doing our jobs usually requires. So to collaborate I have to stop doing my job and start doing yours for a while. If you ever come to help me, I have to take the time to explain the problem to you.

For me to take the risk of helping you, or of making myself vulnerable by asking a question takes trust. Pretty much the only way to build that trust is repeated examples of helpfulness in a group. So building a culture of collaboration is a chicken and egg process.

There is no easy formula to this. Pressures of competitive culture, or of cultural difference mitigate against it. Great leadership and facilitation help but they also depend on the gradual building of trust and relationships.

So if all the problems of getting collaboration are social, why should we focus so much on technology? We shouldn’t. You can not solve a social problem with technology. You can lower the barrier to collaboration with technology, as long as the technology itself has a low barrier to adoption.

Choose Technology with Low Adoption Barrier

The technology with the lowest adoption barrier is email. Everyone has an email address and an inbox. All flavours talk to all flavours. But as we know, group collaboration using email can quickly turn into a mess of emails and files.

The system with the next lowest barrier is email groups. Email groups have a low adoption barrier because group members can keep using email to participate. Email groups work with all flavours of email. Effectively all they do is provide for a group what most individuals already have: an email address and an inbox. Group members email the group and the group emails the group members. The group inbox on the web makes it easy to follow several conversations at once, to search posts and files. And you can post from the web as well.

By organising posts by the subject line, email groups provide a very simple way of keeping parallel conversations separate.

Email groups using GNU Mailman work well via email but do not support posting from the web. Google Groups and Yahoo! Groups both provide free web-based email groups but they are supported by advertising and do not provide a dedicated site for your groups.

With OnlineGroups.Net, your groups are all on a dedicated site with no ads. You can have as many public or private online groups as you like for different teams or communities associated with your organisation.

Social Adoption Hacks

Whatever technology you use for online collaboration, it’s never quite going to meet all your needs. This means that you are going to have to adopt particular approaches to using it. For example, I usually use an “Availability” topic in team online groups. Everyone in the team uses that topic to let others know when they are going to be away. That way there is only one place to look to find out who is unavailable when. It is not as sophisticated as a calendar but it works and is trivial to set up.

If you are going to have to adapt to your software using social hacks anyway, you may as well start with simple versatile software. This will give you a chance to focus on growing participation.If participation does grow, over time you will learn about specific tasks that the group has. This will give you the detailed information necessary to choose a more specialised tool.

A Lean Collaboration Tool Adoption Process

This approach is similar to the lean startup approach to business development. The lean startup approach starts with a hypothesis about how customers will interact with a new product. It uses the most lightweight implementation of the product that is possible (a “Minimum Viable Product“) to test the hypothesis. Making iterative tweaks to both the hypothesis and the product allows you to measurably verify the demand for your product before investing in expensive development and promotion.

Steps to Successful Online Collaboration

As your main challenge in building collaboration will be social, here are the steps I recommend.

1. Choose a simple collaboration tool like email groups.
2. Engage your members, build participation and enjoy the benefits.
3. Make social adoption hacks to adapt your generic tool for specific purposes.
4. Collect data about any key collaboration tasks that are not supported by your simple tool.

You may choose to use that data to select a more specialised tool. Or you may simply continue to enjoy the fruits of collaboration using your familiar simple tool in a variety of ways.

You may have heard the line “If you are not paying for it, you are the product.” Evidently, it originated in Metafilter. It has been discussed on Lifehacker, Computerworld and Forbes. The statement is a reference to the older idea of “user generated content” or UGC. UGC has long been a holy grail of websites. You get visitors to your website to create content that attracts more visitors to do the same — and view ads. The site is free, so more and more people join. Revenue comes from advertising.

So if the customers are the advertisers, what does that make you? As the story goes, you are the product. As you are likely to view the ads, that is true. But as the producer of the content that attracts visitors, you are more akin to some kind of animal domesticated to produce the product.

This means that the site is designed to maximise your productivity as a content-generator and an ad-clicker.

Typically, Facebook is the target of concern about who is the customer. But they are not the first or only site to use this model. In fact, almost the entire first generation of Internet startups was based on generating eyeballs.Now there is a burgeoning economy based on the exchange of your personal data.

These days eyeballs do not matter as much for startups. New businesses focus on delivering a service of value, and demonstrating that with revenue.

At OnlineGroups.Net, we have always been clear that we want our customer to be you, not some third party with whom you have no relationship. We want to design our system so that you and your users can achieve your task: to collaborate easily in groups using email and the web. For that reason, we will place no ads on your online groups site. Instead, we charge a fee that we believe is fair for the service we provide.

Recently Google removed the feature that enabled a group administrator add members directly to a GoogleGroup, without the need for the new member to take any action. Instead, the group administrator must invite new members, who must accept the invitation before joining the group. At OnlineGroups.Net, we made a similar decision a couple of years ago. In both cases, the decision has been controversial.

The decision is so controversial, that for specific circumstances, we are working on implementing a system to just-add group members, while getting around some of its problems.

In the meantime, OnlineGroups.Net can offer a couple of options to group administrators who require just-add straight away:

• Talk to us. We answer email and respond to posts in the OnlineGroups.Net Administrators group. We also offer a variety of custom services, so we may be able to help.
• Set up your own GroupServer instance and add members via the back-end interface.

Before running ahead with this, however, it is worth taking a closer look at the arguments for an against “just-add”.

In Favour of Just Adding Group Members

The Response Rate to Invitations is too Low

When I just add people I get a lot more new group members than I do when I invite people. Just add allows me to build the membership of my group as quickly as I would like to.

People Do Not Get the Invitation Emails

Invitation emails sent to new group members are often caught by spam filters, so there is no way for the invitee to respond.

Group Members have Already Consented to Joining the Group

The invitee agreed to join the group when I collected their email address. There is no need to get their consent again.

Responding to an Invitation is Too Difficult for Some People

Some of my group members are technically naïve. They find it too difficult or tiresome to go through the process of accepting an invitation.

Group Members will Miss Out if they Do Not Start Getting Email Straight Away

There is a really interesting discussion going on in the group right now. I want the new members to receive these posts so that they get engaged in the group straight away.

I Want to Help One Group Member in Particular

An important person has agreed to join the group. I want to make the process as smooth as possible for them.

I am Not a Spammer

I understand that others may abuse the facility to just add group members. I will not abuse it! Why should I — and my group members — be penalised?

Our Staff are Employees — they Have to Participate

Inside an organisation, the rules are different. We can require that people join email groups as part of their jobs.

In Favour of Invitations

How Much Consent is Too Much?

In some cases, invitations may repeat the process of obtaining consent. The consent they obtain, however, is well-informed. Email is intrusive. The invitation contains links to the actual system that the user is signing up to. It shows the description and other information about the group, the terms of use of the site, and information about how the system functions.

It is true that the system does not (currently it can not) distinguish between legitimate administrators and spammers. This does however protect the administrators and their group members from being just-added to other groups for non-legitimate purposes.

People Participate when they Want to Participate

Most group administrators want to build healthy participation in their groups. The number of members and the names on a membership list are important, but they do not guarantee healthy participation. Healthy participation occurs when people want to participate.

If new group members are already well-motivated to participate, they will push through the barrier of a click or two on a website. If they are not, then they will need hands-on encouragement. A personalised invitation message is likely to help with this. A new stream of email from an unfamiliar source is likely to have the opposite effect.

A moment spent browsing the archives, on the other hand, will quickly inform a new participant of the current conversations and of the kind of people and conversations that characterise the group. We suggest creating a welcoming Introductions topic, and pointing new members to it.

Cross the Technical Barriers Early

Like any technology, email groups require users to adopt a new interface. They have to set up a connection with the system, and to learn how the system works. Active participation in the process of joining a group presents these barriers early in the process, at a time when the participant is most likely to be motivated to overcome them.

Firstly, an invitation system picks up the 15% or so of email addresses that contain errors. Secondly, it establishes that the participant can actually find and respond to emails from the system: a task that will be required for ordinary participation. Thirdly, it establishes that the participant can log in to the website, set a password and possibly even configure some settings and create a profile. All these things will help the participant to participate, and help others to engage with them.

If the invitation remains unaccepted, the administrator is in a good position to offer hands-on help to the invitee. With just-add, any of the above steps can fail silently.

We know that the invitations system has usability challenges. One of the biggest is that it is very hard to determine what is going wrong when an invitee does not respond. We would welcome any insights into this and suggestions about how the problems could be overcome.

Between 2007 and 2010, I started a community of practice for people who work with biodiversity information systems. At the outset of the project, I was not a member of the community. I did the project as a community of practice wrangler contracting to the Terrestrial and Freshwater Biodiversity Information System programme aka TFBIS. Now the community is established and I have become a part of it. Here are some reflections on my experience of starting a community of practice — and on why I will continue to work in the area of biodiversity information systems.

The Dataversity project established a community of biodata managers who collaborate to improve practices in their own organisations and across the sector. Dataversity has around 160 members, who are biodata practitioners from local government, the Department of Conservation, Crown Research Institutes and other government, non-government and private sector organisations. The community participates in an online forum and at regional and national meetings. Members of the community are now collaborating on at least two shared software projects that have emerged from Dataversity conversations.

Dataversity is now managed by a Steering Team that is linked to the Regional Council Biodiversity Forum. The Steering Team maintains participation and events such as the recent national workshop, carries out projects to improve biodata management and plans to develop Dataversity as the recognised voice for the New Zealand biodiversity and biosecurity data management community.

Community-Building in an Information Systems Context

Most TFBIS projects focus on creating a technical or informational resource, and are often followed by community-building around what has been produced. The Dataversity project was the other way around. The community was built, and then information systems began to emerge from it. As all TFBIS projects originate from and feed into the biodata community, the learnings from Dataversity are potentially applicable to all those projects.

It is difficult to isolate learnings that resulted specifically from the Dataversity project. What follows is more a reflection on an ongoing learning process.

An Iterative Process

A community can not be built in the same way that a collection is digitised or that IT systems are traditionally built. There is no specification and no linear process for assembling components. It requires an iterative process of engaging with community members to develop understanding, and then trying out interventions. It is perhaps akin to biodiversity management itself.

Dataversity began as the “local government biodata managers community of practice” project. It was based on a hypothesis that there was sufficient potential benefit to individual biodata managers, that they would go to the trouble of sharing what they know with each other. If this occurred, it would inspire others to do the same, and the resulting collaboration would lead to increased biodata capabilities of the sector, as well as of the participant organisations.

If you Build it, Will They Come?

At the outset of the project however, there was no clamouring demand for such a community. It had not emerged spontaneously from association among members, as had the Local Government Ecologists network or from a professional grouping like the Ecological Society.

The prospective participants were busy and reluctant to add to their workload. They were wary of duplicating existing communities or creating a useless “talk fest”. Some were wary that the project was actually setting out to build an over-arching database. Engaging their participation meant persuading them that sharing with others would ultimately make their own jobs easier.

Finding biodata managers in local government was often not straightforward. No council has a designated Biodata Manager, and many even have no distinct biodiversity function. Some biodata managers are in IT, others are in planning or policy and many are in biosecurity teams. It was often necessary to talk with a sequence of people before finding anyone who knew about biodata.

Keeping the Faith

Engaging participants in Dataversity required persistence, not only of action but of spirit. Doubt is the worst enemy of engaging people in a vision. To keep doubt at bay, both as a community-builder and among the participants, it is necessary to form and articulate a clear and compelling vision for the community.

The early stages of participant-engagement involved a lot of questions and listening. Gradually, ideas about what the community might look like developed. Naming the community Dataversity was a key step in this process. As momentum grew, the engagement process became easier.

Face to Face Meetings

The most effective intervention in building the Dataversity was holding face to face meetings, to begin swapping notes about biodata. Even at meetings within a single organisation, biodata managers often met each other for the first time. There was often enthusiastic participation in the conversations. This demonstrated what Dataversity was about better than any presentation could have, and got the actual work of the community under way as the community was forming.

As Dataversity grew, regular regional meetings were held, and were enthusiastically attended. The meetings typically began with introductions, which were followed by a generous break with food provided. The food breaks were always abuzz with conversations about biodata. It quickly became clear that people actually cared quite a lot about biodata.

The enthusiasm for participation increased further at the two national meetings. The first national meeting focused on building relationships and a shared understanding of the issues and requirements that existed for biodata managers. The second national meeting focused on wide ranging reports on biodata initiatives across local and central government, and on workshopping shared issues in smaller groups. Again, generous breaks allowed for informal discussion.

Most Participation is Invisible

The participants in these meetings often joined an online discussion group. Initially, a private online group was formed in an attempt to create a trusted space exclusive to the local government end-users of the project. This proved unnecessary and unhelpful. A public group was set up for anyone interested in biodata, and which enabled online participation to grow more quickly.

Although participation in the online group seemed sporadic and restricted to a few regulars, discussions at face to face meetings revealed that most members followed the postings with interest, even if they never posted themselves. There were also stories of phone calls, corridor meetings, and conversations at conferences suggesting that most of the activity within Dataversity was behind-the-scenes.

Grow a Core Group

Throughout the process of forming the Dataversity community, the small group of key advocates for the community were a valuable resource. This group had its origins as supporters of the original funding proposal. During the project it became a valuable source of ideas, contacts and reinforcement of the vision. As Dataversity has matured, this same group has led to the formation of the Steering Team, and the connection of that team into its institutional context.

Communities, Information Systems and Ecosystems

As the conversations about biodata systems have developed within Dataversity, there has been a clear direction towards a vision of independent biodata systems loosely linked by common standards to facilitate biodata management on a national and even global scale. The patterns within such a diverse network of systems are similar to those within a community like Dataversity and within the very ecosystems that biodiversity management is concerned with. To this extent, the processes for developing vitality in all of those systems are similar, and learnings from all of these domains can be drawn on to inform the others.

There’s a lot of talk about alternatives to email. But if you look at people on their computers, most of the time they’re not using Web 2 or Enterprise 2. They’re using email. We use email because everyone uses email. It’s the only online communication tool that everyone uses. So we’re stuck with it.

And email is fantastic for one to one communication. It’s brilliant for one to many communication. But for many to many communication, it sucks. So when you start using email to collaborate in groups of 3, 4 or 5, it hurts. It pokes you in the eye with a fork. So you stop. And collaboration stops. And lies bleeding on the floor.

But no-one talks about this. We’re too busy talking about Web 2 and Enterprise 2. Meanwhile the use of email keeps growing. It’s an elephant in the room. Well I’m breaking the silence about it.

But just how bad is this problem? As we are basing our business on the notion that there is a need to make email collaboration easier, I figure we should know a bit more about it. I decided to conduct some informal research.

At the recent GOVIS 2011 conference, I conducted some workshops to access people’s experience and gather some data on the problem. The workshops set out to explore three assertions.

1. We Are Stuck with Email
2. Email Collaboration is Difficult
3. Email Makes People Collaborate Less

I’ll explain the results. But first a little context. First up, I make no claim that this is robust research. This is a preliminary investigation that I hope will open more of a conversation about email.

The Participants

The participants were attendees at a New Zealand government information systems conference. In two one-hour workshops held on consecutive days, there was a total of fifteen participants. The participants were about 50:50 in line of business roles vs some kind of IS related role.

Defining Online Collaboration

For the purpose of this exercise, I defined collaboration as restricted to many-to-many collaboration in persistent groups.

To warm up the participants to collaboration, I explained the three main collaboration tasks that we think about at OnlineGroups.Net:

• keep in the loop — the most common collaboration task, sometimes referred to as non-posting participation or (in an attempt to reclaim its status from the pejorative “lurking”) as legitimate peripheral participation
• closely follow a conversation
• contribute to a conversation

To warm up the participants to online collaboration, I explained some of the benefits that we aim to deliver at OnlineGroups.Net:

• To overcome barriers to face to face collaboration:
• geographic
• inter-organisational
• scheduling

• To overcome limitationsof face to face collaboration:
  • holding multiple concurrent conversations
  • keeping records for re-use and audit purposes

For the purposes of the research questions that I planned to ask, I asked participants to respond according to what they perceived as typical in their work world.

We Are Stuck with Email

Use of Email

We started by looking at how much people use email for collaboration. I asked people to rate use of email on two criteria.

1. The proportion of the time that the active window on the computer has email in it.
2. Of that time, the proportion of the time is spent doing ongoing conversations in a group of three or more.

The responses were as follows.

From this I could tentatively conclude that people spend between a quarter and a half of their computer time using email. The more people use email, the more they use email for many-to-many collaboration.

Availability of Alternatives to Email

I asked the participants to rate the statement “People in organisations have to use email for many-to-many collaboration in groups of three or more”. Their responses were as follows.

So, that is a yes.

To investigate this more, I would like to explore what happens with attempts to introduce an alternative to email. I have a hunch that if one critical participant refuses to adopt the new system, the whole group gets pulled back to email.

Email Collaboration is Difficult

Here are the participants’ rating of the statement “Many-to-many collaboration in groups of three or more using email is difficult”.

Again, they mostly agreed with the statement.

The main issues described were these:

• Unclear and unstable group membership – the wrong person ends up receiving the email, or the wrong person gets left out of it (it is the sender, not the recipient, that gets to choose who can keep in the loop).
• Unclear flow of conversation.

Participants told several stories of email-trails spreading, branching and mutating. Wouldn’t it be interesting to map the path of an email thread as makes its way through an organisation!

Email Makes People Collaborate Less

So, people have to use email to collaborate, but email collaboration is difficult. So, that would make people collaborate less, right?

Here is the groups’ rating of the statement: “In order to avoid the difficulty of collaborating using email, people in organisations avoid collaboration”.

This one I did not expect. Apparently the pain of collaborating with email is not putting people off. But they wouldn’t necessarily do any more collaboration if it was easier.

Conclusion

This preliminary investigation has confirmed my hunches that people are stuck with email and that email is not great for collaboration. But they seem not to be bothered by that. This raises more questions than it answers.

Why are people collaborating using email when it is painful? Are they that motivated to collaborate as much as they do, but no more? Perhaps people are collaborating because they have to. Perhaps they do not realise that a culture of voluntary collaboration is possible once the barriers are lowered. What would happen if you made it easier for people to collaborate using email? This definitely warrants further investigation.

As you may know, OnlineGroups.Net has an office in Christchurch, as well as in Wellington and Canberra.

The Christchurch office of OnlineGroups.Net was based in a CDB building called Kenton Chambers from 2004 until December 2010. Kenton Chambers suffered only very minor damage in the 4 September 2011 Christchurch 7.1 earthquake, so we, and a bunch of associated businesses were all happily occupying the building until Christmas.

On Boxing Day 2011 a shallow 4.1 magnitude earthquake occurred right under the Christchurch CBD. Small earthquakes are like fire crackers. If one goes off across the room, it’s funny. If you’re sitting on it, it hurts. The Christchurch CBD was sitting on the Boxing Day ‘quake. Outside the CDB, it was hardly worth interrupting a sentence for. But in Kenton Chambers the smaller ‘quake was more violent than the big one. This time, the building sustained much more damage, so we were out.

Since then I have been working from home in Sumner, which is where I was on 22 February. You probably saw Sumner on TV after Feb 22. It was telegenic because of the large rockfalls. Some commercial buildings and many houses on the surrounding hills were badly damaged. But for the most part, the damage was minor, especially when compared to the Christchurch CBD or to the eastern suburbs built on wetlands and poverty. Our place was almost completely unscathed.

My partner and I gathered Miss 8 from her school. Some friends joined us at our place. We hunkered down for a week without power, water, sewerage or telecommunications. We met our neigbours in a new hyperlocal economy of help, equipment and news. With a portable radio and a smartphone charge from a neighbour’s 12v inverter, news filtered in. Mercifully all my friends and family were ok. Many were much less lucky. Even among my friends, like Alan, Lucy and Layton were stories of smashed houses and offices, and horrifying escapes from the CBD.

In our privileged situation the aftermath of the earthquake was almost fun. At about the same time, I had planned a camping trip where we would voluntarily be without power, water and mod cons. We improvised a toilet and even a hot shower. Days filled with carrying and boiling water, and new routines for lighting and cooking. Many freezers full of food were barbecued. But the backdrop to all this was the trauma of a shattered city. Even without negotiating the twisted streets, the very absence of the usual services brought home the reality of the situation in successive waves.

One feature of the daily routine was to collect water. In the queue there was always some local news. The same guy drove the water truck each day, and he would report news from the many conversations he had heard. Then a community hub sprang up, with a movie screening and briefings from the local police, fire and civil defence. Volunteers coordinated food, hand-sanitiser, assistance of all kinds, a community laundry and showers. I saw vitality that I had no idea was present in Sumner. With the roads blocked or congested, I went days at a stretch without leaving my neighbourhood. At the same time, stories continued to pour through blogs, Twitter and Facebook.

Even now, a month after the earthquake, each day comes with new stories of the impact of the earthquake. With each story comes a new heavy feeling. Around me, most people are experiencing similar feelings — even my Christchurch friends who live out of the country. Especially in the first couple of weeks, I observed myself and others behaving in unusual ways. I think we all respond to grief differently.

This reminds me of other experiences of grieving and deepens my understanding of it. Grief happens at two levels. On the surface, we grieve for things we have lost — loved ones, homes, livelihoods, infrastructure, familiar places and landmarks. At a deeper level, we grieve for the loss of trustworthiness of the world. If the world can take away these things, what else can it take? This sometimes manifests in reflections about the value of each day, or of loved ones. I have felt it as a deep but indeterminate sense of disturbance.

There is something about the ground that is important to us humans. When we are born, we emerge from weightlessness, and settle to the ground, or someone or something held up by it. We learn to walk by learning to fall forwards, foot extended until it meets the ground, which is always there in front of us. For all the richness of our virtual connections, when the ground beneath our feet begins to leap or shake around, it makes the world seem fundamentally unsafe.

Along with the others who have been affected by the Christchurch earthquakes, I am quietly grieving, staying connected with myself, my feelings, and with others as best I can. And like the others, getting on with my life. Living more locally, with more of an eye on my garden and neighbours. And being online with a new consciousness of the value of this medium, when commuting is hard, and there is no CBD to go to. This reminds me of the craziness of the idea of living online and the craziness of living without the opportunity to connect online.