It’s been a few days since the end of Enterprise 2.0 Santa Clara and there’s been a few blog posts that have chosen to tackle wrap up the conference or tackle some of problems around the definitions of social business, enterprise 2.0 or whatever this market for software like ours actually entails.
While we’ve been at it for the past 5 years with ThoughtFarmer and my ear is far more attuned to the debate than most of our clients and potential clients, I’m not too fussed about it. I probably side closer to Larry’s perspective. Instead of talking about the signifier, let’s talk about the signified. The thing itself. And how it works.
I did leave the conference with some nagging concerns about the industry and how the conference represents those in the industry. In particular, how the conference communicates to potential buyers of software and people like my clients, instead of how industry insiders quibble with each other on new buzzwords and posture against competitors in keynote infomercials.
Maybe I’m just too close to having organized and put on an event and I’m caught up in the halo effect that goes along with that, but I wound up with a list of things that left me unsatisfied. I have a big list, which I’m somewhat surprised about, but I’ll save my rants about how panel discussions should be done to maximize audience value, the constant invocation of (absent in the room) Millennials and generalizations about how non-workplace sociality is setting the norm for workplace sociality, or imperatives and determinism of any flavour….
Instead, I’ll focus on my biggest beef of the entire conference.
Sloppy use of the word collaboration. Still.
Collaboration. What does it mean?
I get the sense that if you’re a potential buyer looking to understand enterprise 2.0, social business, and social software for the enterprise, that you’d have left the Enterprise 2.0 conference with the idea that you know you should be collaborating, but you’re probably not sure how to do it or what it entails. And just like teenagers and sex, you get the sense that everyone else is doing it, but not you. And even if you are doing it, everyone else is doing it a lot better, more frequently, and having a lot more fun than you are.
So let’s cut to the chase. How we define collaboration as a problem defines how solutions and designs work to address that problem. And not by mistake, problems and solutions are at the core of collaboration.
Here’s a definition I’m fond of from Barbara Grey and her book Collaborating: Finding Common Ground for Multiparty Problems
Collaboration is a process through which people who see different aspects of a problem can constructively explore their differences and search for solutions that go beyond their own limited vision of what is possible.
Lovely. Catch all of that:
- search for solutions
- results beyond any individual
Whole is greater than the sum of its parts and all that. It’s a great starting point.
But for Enterprise 2.0’s purposes, we need to dig deeper into collaboration. If you’ve spoken to me about this topic over the past 2 years, you’ll know I’m fond of referencing three collaboration patterns that acknowledge the different types of working arrangements and problem solving activities that social software can afford. These three patterns were first written about by Shawn Callahan, Mark Schenk, and Nancy White from Anecdote, an Australian intranet and KM consulting firm.
In their whitepaper, “Building a Collaborative Workplace” published in April 2008, Anecdote describes three levels of collaboration: team collaboration, community collaboration, and network collaboration.
Go and read the full article yourself, but here’s the definitions of each mode:
The members of the group are known, there are clear task interdependencies, expected reciprocity, and explicit time-lines and goals.
To achieve the goal, members must fulfill their interdependent tasks within the stated time.
Team collaboration often suggests that, while there is explicit leadership, the participants cooperate on an equal footing and will receive equal recognition.
An example is a six-member team working together to develop a new marketing strategy in a month, with a defined set of resources.
Team collaborations can also occur with external partners, but there is always a clear mandate and defined roles.
There is a shared domain or area of interest, but the goal is more often focused on learning rather than on task.
People share and build knowledge rather than complete projects.
Members may go to their communities to help solve their problems by asking questions and getting advice, then taking that advice back home to implement in their teams.
Membership may be bounded and explicit, but time periods are often open or ongoing.
Membership is often on equal footing, but more experienced practitioners may have more status or power in the community.
Reciprocity is within the group, but not always one to one (“I did this for you, now you do this for me”).
Steps beyond the relationship-centric nature of team and community collaboration.
It is collaboration that starts with individual action and self-interest, which then accrues to the network as individuals contribute or seek something from the network.
Membership and time-lines are open and unbounded.
There are no explicit roles. Members most likely do not know all the other members. Power is distributed.
This form of collaboration is driven by the advent of social media (tools that help us connect and interact online), ubiquitous internet connectivity and the ability to connect with diverse individuals across distance and time.
It is a response to the overwhelming volume of information we are creating. It’s impossible for an individual to cope on their own. So networks become mechanisms for knowledge and information capture, filtering and creation.
Great stuff. And with that model, we can look internally at collaboration amongst ourselves and our coworkers on projects, in communities, and via networks, as well as look externally when we collaborate with our customers or suppliers in each of those three domains.
So when next time someone says they have the need to collaborate more, ask them “what do you mean when you use that word?” And when you as a product vendor claim to offer a collaborative solution or your system affords collaboration, define what you mean by that.
- Do you have a community space feature where your customers and staff can exchange ideas about future directions for your product? (BTW, is that what people are talking about as SocialCRM? Is that what people were trying to talk about at E2Conf in all of those sessions?)
- Do you offer project and document management tools for geographically distributed team members within you organization to work together on a project?
- Are you harnessing individual behaviours in the system, aggregating and analyzing them and displaying them back to your users to suggest what other content or people they might be interested?
Either way, let’s adopt some more rigor around the use of the word collaboration. It’s a really basic thing but it’s lowering the level of discourse and discussion that could be had because we’re using the same word to talk about a lot of different things. It’s not doing any of us (vendors) or our customers any favours.
On another note, I’m part-time at KM World 2010 in Washington DC this week in between working for a great new client here in DC. Given the topics and personalities assembled, this seems to be a lot more relevant to a potential customer or even educated vendor as to what we’re really trying to do with these technologies. Having never been to KM World before, I’ll be keen on knowing if that’s the case of if its just good marketing…
If you’re around and would like to chat, send me a note via Twitter – I’m @gordonr.