The creation of Social by Social

In the beginning...

We first started this project in October 2008, coming together as a collective in response to NESTA’s original tender to produce a handbook to new technologies for social impact. With the exception of Clive and Nigel at CASS, none of us had ever worked directly together before.

In our original project proposal, we stated:

We wish to emphasis a fundamental dimension of our proposal. This is that the project itself will, at every stage, directly use the communications technologies that are being advocated for use in social change. There is one spine of the project that relates to use of a range of social technologies for both internal operation of the consortium, as well as for external engagement. This will also enable the working methods of the consortium itself to become a case study of innovation – this type of approach remains rare in consulting projects.

A second dimension is that it is both desirable and necessary to engage actively both with other practitioners in use of social technology, as well as those prospectively interested in using the eventual NESTA outputs. This engagement will take two forms. Firstly, the electronic media already touched upon. Secondly, during the duration of this project there are two physical events taking place. Not only will these be places for engagement face-to-face, it will be possible to use some of the methods in which the group are expert (including social reporting) to develop materials that can be directly used in the final handbook.

Thirdly, the project is not simply concerned with producing one draft free-standing document that is finally edited all together. With a consortium of five members, it is essential that the editorial task is continuous through the whole duration of the project.

When we set up a project wiki, it included the tag line: “Social by Social is a project in eating our own dog food while we help you get some of that dog food, too!” Yum. This idea of using the process of Social by Social’s own operation as a case study, of ‘eating our own dog food’, carried its own risks. We would have to be willing to admit that some things worked less well than others for us. We might even (as did happen) have to admit to making mistakes. However, we felt that what we would go through would parallel almost exactly what other groups, whether they were ad hoc collaborations, cross department or organisation projects, or permanent social enterprises, would go through in setting up social technologies for the first time.

There is inevitably a shortage of case studies that are willing to address problems and failures, yet it is precisely these that first-time users of new technologies need to hear the most about. By engaging in the process ourselves, we were able to offer up a ‘warts-and-all’ case study of social by social in action. Sharing the real lessons learned, if you will.

Technology

The group was, as a whole, pretty technology savvy – or at least that was the assumption. This assumption lead to the first major mistake: not enough thorough evaluation of each participant’s level of social media competency and experience. It is easy with a group of people interested in social media and technology tools to assume that everyone is on the same playing field, and conversations about skill levels can also be awkward amongst collaborators. The difficulty is that the field is growing exponentially faster and wider every day. Even coming from the same background or sector doesn’t mean two people are familiar with, or have even heard of, the same tools. We have options now to do virtually the same thing via a multitude of tools; and decisions are being made by referral, Google search results, demographics, and even the look and feel of a site, not on whether it will do the task or not.

What we did: Selected a group of tools that sounded great on paper. We were thoughtful to include tools to cover all the stages of information gathering, sharing, and collaborating we would face, but we were not thoughtful about how those tools would be used by the team or how they would come together into a finished product. Because we picked the tools before diving into the project, we weren’t addressing the audience first. This meant we ended up with tools that team members didn’t know how to even begin using and were stuck feeling the pressure to figure it out without “messing up.” This led to a great deal of internal push back and resistance to tool adoption. We ended up defaulting to e-mail quite quickly for two reasons: firstly, because everyone was definitely using it; and secondly because we trusted it to give us our own record of what had been said that we knew we could rely on. The project wiki was useful for collating content together, but it became cumbersome and ineffective for editing the final document together: it was too text-focussed and wasn’t useful for showing layout and graphics to the designer, and also it wasn’t appropriate for delivering to the client at NESTA and inviting formal feedback and signoff. We ended up collating the final handbook in Microsoft Word and using e-mail and tracked changes – which worked very efficiently but broke our collaborative approach in favour of getting the job done.

What you should do: Choose tools based on what people are using already first, and introduce new tools only if you really need to. There are probably lots of subtle reasons you haven’t thought of why people like the tools they use, so don’t assume you know how to do it better. Survey all members of your team or community to find out what kinds of tools they have used before, which tools they use on their own and which for work, how they work most efficiently (do they prefer individual emails, shared workspaces or maybe RSS for alerts?), and what things they feel the least experienced using (it’s helpful here to include a range of tools and a scale of comfort/experience to guide people through). Once you hear from your team, you can begin selecting the tools that most apply to your team’s experience and preferred working style and what kind of work you need to do. You can also take note of the kind of training that will be needed, whether it is a professional session or just a cheat-sheet you create (see below). And keep reviewing the appropriateness of tools and respecting people’s needs to work in what they’re most comfortable in; it’s a constant trade-off between efficiency for individuals and efficiency for the group.

Skills

Most of our team had, at one time or another, worked online as part of a team, so there was always one person who felt comfortable with any given tool. This lead to the second major mistake: when you are working as a team and needing to get things done, one person isn’t enough. In some situations, having one ‘expert’ in your group is all you need, but in our situation, we all needed to jump into the same tools, jump into the same work, and get going quickly (since we only had 10 weeks to put the handbook together). This meant that having one person feel comfortable and the rest lost, wasn’t going to get us very far. What made matters worse is that we don’t work in an office together to turn around and ask a question. It was all virtual. But, this is very common with partnership and projects, and always the case when communicating with your community outside of the organisation.

What we did: We relied very heavily on one person among the five knowing the ins and outs of the tools. But we all needed to know how to use them. We also did not allot time or prepare for any training on the tools, since we were so confident in choosing the tools in the first place. This created a Catch-22: we didn’t train the whole team, so the ‘expert’ would create information on how to use the tool and distribute it, but there wasn’t an opportunity to review the training materials with the ‘expert’ and ask questions in real-time, so the ‘expert’ would refine training materials at different intervals based on intermittent feedback, and so on. The tools we used created structures of communication and responsibility that didn’t fit with the way we actually needed to structure the work. This meant that resistance to adoption was strong and animosity grew, whilst some members of the team felt under huge pressure to plug the gaps.

What you should do: Allot time for training and also for using the tools prior to really starting the project. It’s a good idea to offer training to all members of the team so no one feels singled out or behind the curve. Create a culture of support by making sure the team is aware of who to go to or how to find the help he or she needs, whenever it is needed. Even if people get trained on how a tool works, the most valuable part is using the tool and finding the questions and problems that arise before it’s really go-time. Create initial projects or tasks so everyone has a shared objective to work on as a way to get introduced the tools without the pressure of doing it for real. Make sure the tools aren’t changing the way you work and getting in the way of doing your job; if they are, drop them, it’s a false economy to make your processes more efficient if they’re the wrong processes.

Engagement

The group also had very strong connections either with their own technology experts or as part of communities which included such experts. This lead to the third major mistake: prioritising conversation and engagement before there was content to discuss. We were really excited to share our ideas with each other, and even more excited to share our ideas with the rest of the world. We knew that talking about successes and failures, innovations and new ways of doing things would be integral to really creating a space for shared learning—whether it be an expert taking part, or something exploring social media for the first time. So, we imagined that these conversations were so important that they would need to start right away. Plus, there was a huge network of people we thought would be excellent to engage for input, links, resources and quotes.

What we did: We were so ready for convening conversations that we created a blog and selected bookmarking tools designed for conversation and not building our handbook. The blog was intended as a place where we could post ideas, snippets of conversations, or more substantial work in the making. It would mean we could put things out for the community to weigh in about, help us shape and refine, and ultimately create real material to be used in the final resource. But what happened was that we either had ideas or information that went into our handbook, or it was too squishy to articulate and just stayed in our brains for reworking. We also faced the fact that we weren’t, ultimately, in charge of starting the conversation since we were commissioned for the work with the intention, more properly, that the conversation would start with the release of the finished handbook. Likewise, we chose a tool for collectively bookmarking websites, videos, blogs and other pieces of information that would be useful for the handbook and as further resources for the handbook readers. We chose a bookmarking tool that created a great place for conversation and comments attached to every link or other media posted. But we didn’t have anyone to share it with, so there wasn’t any conversation. We were posting resources into an empty closet. Our initial ideas to engage non-authors in the conversation and content prior to creating any, or publishing any, turned out to be much more difficult and ultimately impossible – and the content collected wasn’t in a form that was easy to integrate and publish, which ultimately wasted a lot of the work. And when we finally did engage others in writing content for the handbook, it happened at editorial stage without the involvement of the rest of the team. We tried to create general conversation and engagement, when actually the most effective engagement tool was simply to ask people directly if they wanted to write content for us.

What you should do: Be excited for conversation and connection, for sure we weren’t wrong there! Social media is made to be social, after all. Do evaluate your process and when different audiences will be introduced as this can effect the content you have, and could even effect which tool you use. Your social media plan should include goals that address what kind of connections you want to have with your community and how you’d like individuals to be able to connect (is it a 4-person team that needs a way to share knowledge, a 1000-person community you want to empower to give feedback, or an unknown group you want to provide information and resources to?). When you identify the audience and how you want to connect with it, it is easier to identify the appropriate tools for that connection and when you’ll be able to start making it happen. Make specific requests of people too, it makes it much easier for people to engage and support you.

Purpose

We were all incredibly interested and excited to work on this handbook, with ideas bubbling up every time we tried to talk about it. This led to the fourth major mistake: excitement and knowledge do not outweigh the need for a clear purpose and specific deliverables. We never arrived at a clear purpose that we all agreed on and could work towards, which meant at times we either went off in wrong directions or got stuck and didn’t know where to point our energies. The wiki was the most successfully-used tool in terms of tangibly progressing the project, as we were able to see the handbook coming together in front of our eyes. But it took a while for us to actually get to that practical stage.

We certainly felt at the beginning that we’d been set an impossible task: to create a guide to using tools that change every day. But as much as this is a difficult task, it is still possible with specific parameters. It isn’t so new that there is no information, nor is it something beyond the capabilities of the authors. We were very ready to consider our previous thinking, discuss ideas, come to new positions, and then rethink those as well. But, alas, this was not an intellectual or philosophical endeavor, it was a practical one. Once we had stopped trying to get everything exactly right, focused on an achievable goal and allowed ourselves a few “it depends” moments, things moved much quicker.

What we did: Given our backgrounds in the sector, we were quick to point out examples and options of tools and organisations and even our own work, creating a wider and wider scope without narrowing the working scope. We got stuck in the thinking and researching, the pulling together of all the thinking from experts and thinking about their thinking. We divided the work among members based more on theoretical divides and not on the actual end-structure of the handbook and its parts. This only made matters worse for actually getting the handbook written and edited. We needed a much clearer shared agreement on the specific work that needed doing, and who the handbook was for, so we could ensure every piece of work we did was genuinely helping us reach our objectives. We also each, including NESTA, had slightly different stories in our heads about who the handbook was for and how it would be used, which meant what was written took a lot of effort and time to edit together into one consistent whole.

What you should do: Clearly identify your audience from the beginning of your project. Who will be receiving your services or your message? Who it is determines how that service or message will need to be delivered. You might also want to create ‘use cases’ for the main ways your output will be used and agree on these too, so you all have the same stories in mind when you’re working separately. Create a flexible map of your project and allow time for research and thinking flexibly so that if in the research and thinking something surfaces beyond or different from your preset scope of the work, you may want to evaluate whether to redesign the scope. Identifying your goals is also crucial. In this case, though, your goals are based on outputs and change. For example, do you want to make a more connected community online with your members, or provide a new way of sharing knowledge or community, create a conglomeration of resources and conversations, or write a handbook. When you identify your audience clearly and understand what they need, you are much more able to successfully reach your goals. A handbook for every audience serving every purpose is impossible; a handbook to help a specific group of people achieve something is possible - and much more useful too.

Tools

In our proposal we outlined the following communications tools for use:

• Cassfocus (a same-time, same-place ‘electronic boardroom’ system)
• School of Everything Scrapbook (a form of social bookmarking)
• Project Blog
• Project Wiki
• Semantic Media Wiki
• Huddle
• Other media eg Flickr, YouTube

Here are the tools we really used, and how we really used them:

• Huddle: for project collaboration, a placeholder and go-to spot when information or conversations needed to be stored and archived, for high-level thinking and project information sharing with NESTA.
• Wiki: for the meat of it all, writing, editing and framing the handbook.
• School of Everything Scrapbook: collecting links to be used in handbook content and as further reading by handbook recipients.
• Blog: for starting conversations without an audience to comment (only 3 posts).
• Delicious: for collecting links in a more streamlined fashion with individuals’ work as it is an application already integrated into many of our toolsets.
• Personal blogs: for highlighting ideas and conversations that come up as we work on the handbook, a way to discuss issues with a community of readers that already exists.
• Email: for direct communications and for those team members struggling with Huddle or the wiki.
• Microsoft Word: for assembling and presenting edited content, including layout, and recording tracked changes and client feedback.

Although much of our initial focus was on new collaborative tools to increase our efficiency, we ended up relying on ‘old-fashioned’ e-mail and word processing to actually get it finished.

Victory?

Overall we feel we have accomplished what we set out to do: the handbook was written, and we created some useful conversations and resources alongside it and “ate our own dogfood”.

Could it have been done more efficiently? Yes, undoubtedly, and the editorial process in particular could have been greatly simplified by having a clear direction and shared understanding of the project from the outset. But we rallied a team of people who had never worked together before and delivered a difficult project in a very short space of time, to what we hope is a high standard. We adjusted well to new developments, re-evaluating and spotting new opportunities instead of being bogged down in the obstacles. And most importantly, we’ve shared what we learnt. Whether the handbook itself is deemed a success or a failure, we have all learnt so much about how these technologies and collaboration work, and how to write and publish a book too, which means by its own standards, the project has been useful.

We hope you think so too.