The facets of collaboration Part 2–Enter the matrix!

 

Hi all

In my first post in this series, I introduced you “Jane” and a true story about her missteps when implementing popular social networking technologies within her organisation. We then asked some deep and ponderous questions, before meeting Robot Barbie and the crazy world of SharePoint Robot Barbie solutions. Finally I outlined a simple mental model that I developed that I have found to be quite a useful method to look at collaboration more holistically and help with the user engagement and information architecture aspects of SharePoint governance.

Now before we start, I want to make a four points to pre-empt the type of replies that I anticipate from putting this model out there.

  1. Kailash once told me that the problem with models is that their creators fall in love with them. They forget that they exist to help us to understand the reality around us, but this doesn’t make them reality. For that reason, I do not love my model and see lots of flaws. I also look forward to seeing better ones that people come up with. The key point is this: No model can ever capture the total sum of variables combine to make a collaborative situation look or feel a certain way, all it can do is approximate. This is my attempt at approximation.
  2. Imagine watching the Matrix movies without the car chases or kung-fu. It would be long, full of nonsensical dialogue and you would come out saying “I have no idea was that all about”. Mental models are a little like that too. This model is designed to be simple and explainable within 2 minutes. Any concept that takes more than a beer to explain will forever be in the realm of academia and get little real-world use.
  3. Some people (particularly scientist types), will look at a matrix like mine and automatically think that is measuring something. This is because there is an X and Y axis and usually, their presence indicates two variables that can have a range of values. In my case though, I was not thinking about an axis in that way. I just saw that each of the facets identified (task vs trait and social vs transactional) seem to me to be the extreme ends of an axis that I as yet, have not worked out :-). The point is, matrixes don’t always work for these people and they tend to avoid drawing quadrants with explicit lines because of the implicit suggestion that a situation falls into one quadrant or another. If you are of this persuasion feel free to develop it in a way that works for you. I think when we hit part 3, you will see that I use the model in different ways.
  4. Remember that this model is about collaboration. By definition, this involves more than 1 person. I was not thinking of individual people when putting it together. It assumes a bunch of people interacting and each facet I guess, highlights a dominant collaborative trait.

So let’s examine each facet in turn

Task Based Collaboration (Outcome driven)

Task based collaboration is typically characterised by short(ish)-term groups, comprised of people with a shared goal or common outcome (i.e. a "project”). The membership of a task based group is typically fairly diverse because it is the outcome drives the members’ attention and participation. Members are chosen because of their ability to play a part in achieving the outcome and it is not necessarily true that they have a say in that outcome.

The dominant characteristic of a task based collaborative group is that members do not necessarily have shared interests beyond the outcome being delivered. A SharePoint project team is a good example of this, because of the multidisciplinary skill set required to deliver it. Outside of that project, people may have vastly different interests and skills, and may have nothing in common beyond the outcome being sought. Some organisations are like this, where the people you work with you do not necessarily have any social interaction with beyond the interactions required to get the job done.

When you look at the matrix below, the top and bottom left quadrants are therefore driven by outcome. (i.e. getting something done).

image

Trait Based Collaboration (Interest Driven)

Trait based collaboration is comprised of users who are related through shared traits or long-term interests. As I stated in the first post, members may not be consciously collaborating on the same task or outcome, but may be highly likely to repeat or augment tasks already accomplished by other group members. Therefore, trait based groups tend to come together to share their learning and experiences. It is the shared interest that drives the members’ attention and participation. There is no deadline as such, or a specific task being shared among the group.

Examples of trait based groups are special interest groups (fans of a particular musical group) and occupational groups (via job role or even department). When you think about it, Facebook is the mother of all trait based collaborative platforms because members almost overwhelmingly are there connect with people who have a shared trait of some fashion. Also consider a community driven site like NothingButSharePoint or a conference such as SharePoint Best Practices. Both are excellent examples of trait based collaborative scenarios. We use these collaborative environments to gain insight and learning from sharing experiences with like-minded individuals.

When you look at the matrix below, the top and bottom right quadrants are therefore driven by interest.

 image

 

Transactional Based Collaboration (Process Driven)

Transactional collaboration takes the form of a business process where various people or groups interact to get something done. In this scenario, inputs and outputs are fairly well defined and the process is repetitive by nature. Think of airport baggage handling as a great example. This is a process that has to be run efficiently and consistently. As a traveller, I want baggage handlers to be making sure my suitcase is on the right flight. I don’t want them all sitting on say, Yammer or MSN to co-ordinate the delivery of baggage. But I sure as tell want them to be able to tell me the status of my bag pretty much instantly.

One interesting characteristic of transactional based collaboration is that the people in the process can often be “swapped out” with other people, because transactional process is designed to be well defined, optimised and easy to follow consistently. It is the process that drives the members’ attention and participation, and governs the interaction between participants.

As stated in part 1, another characteristic of transactional collaboration is that it is usually not a place of spontaneity. Consistency is key to success and processes are designed to run with a minimum of variation and margin for error. As a result, this is the sort of stuff that well defined business rules, metadata and rule-based workflows handle well.

When you look at the matrix below, the left and right bottom quadrants are therefore driven by the process that governs the collaboration.

 

image

 

Social Based Collaboration (Insight Driven)

Social based collaboration is an interesting one. Truth be told, I knew that this one would have the greatest connotations because of the wildly different interpretations of the word social. From the point of view of my model, I offer the following explanation.

Social collaboration is the other extreme of transactional. This is usually characterised by more ad-hoc sharing of perspectives and information. It is realisation or insight through pattern sensing via group interaction, rather than structured business rules. It looks beyond the process and attempts to get to the ‘big picture’ of an issue, problem or constellation of problems.

Therefore social collaboration cannot really be a predefined interaction in the transactional sense. It is not a structured workflow, a rule or something with well defined inputs. But it is the place where tacit knowledge creation, development and exchange typically occurs. It is where hard decisions sometimes have to be made and where innovation tends to come from because it is the shared insight that drives the members’ attention and participation. It is the world of wisdom of the crowds – collaboration in all its messy glory.

As a simple example of what I mean, even the best business process modelling guru will never be able to document the process a board of directors would go through when performing strategic decision making. If for example, someone worked out the business process diagram that would tell any organization how to develop the next iPod or to master the stock market, then we wouldn’t marvel at Steve Jobs sixth sense for product delivery or Warren Buffets ability to consistently out-perform the market.

Therefore in the matrix below, the two top quadrants are therefore driven by the insight gained from the collaboration.

image

 

To Summarise

Hopefully after that explanation, each of the quadrants start to make more sense. The facets of collaboration can be summarised as follows:

  • Task: Because the outcome drives the members’ attention and participation
  • Trait: Because the interest drives the members’ attention and participation
  • Transactional: Because the process drives the members’ attention and participation
  • Social: Because the shared insight drives the members’ attention and participation

image

 

In the next post, we will use this simple model to examine several common scenarios and see what insight we can glean from looking at collaborative tools and situations through this lens.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

5 Comments on “The facets of collaboration Part 2–Enter the matrix!

  1. Paul,

    Good post.

    As you have mentioned, in your model, the x and y axes (the dimensions) are not variables, they are categories. I wonder if your model can be “translated” to one in which dimensions are variables. See this post by Cynthia Kurz for an example of such a translation. In the post she discusses how the category-based Cynefin model for classifying problems can be translated into a model which uses continuous dimensions.

    Regards,

    K.

  2. This is extremely helpful. Traditional requirements gathering will begin missing the mark because SharePoint and other socially driven or user adoption dependent solutions will not fit into a nice little box. I am enjoying this series, and it will be useful in practice as well.

  3. Aha! That last pre-statement really helped. 🙂

    Remember that this model is about collaboration. By definition, this involves more than 1 person. I was not thinking of individual people when putting it together. it assumes a bunch of people interacting and each facet I guess, highlights a dominant collaborative trait.

    I keep forgetting as most of the models I work with are both collective and individual models. 🙂

    Awesome breakdown of the model. It would be great if you could come up with selective questions that could be used to take any collaborative activity and determine (based on the answers) where in the model they seem to be aiming for…

    That way it would help determine which tool, construct, or methodology should be applied. Or at least which things might resonate better with the identified end goal.

  4. Richard

    The idea of selective questions is an excellent one and something I will have a good think about before this series is done.

    Currently, I use this model directly with clients because its easy to draw and can be explained in little more than a couple of minutes. It helps them better understand what they are trying to acheive, and when a particular solution might be a robot barbie, or a “Jane” situation where she was clearly looking at a social/trait based solutuon for what may well have been a transactional/outcome based problem.

    More on that in part 3

  5. I have always struggled with the concept of “collaboration” and your series is really helping me. This model helps me understand ways to help other people avoid the cop-out of platitudes and design solutions that have a much greater chance of success. It seems to me that the measurability of the desired end result is also something that can help identify where on we are on the matrix… when we ask the participants to characterize the end result or desired end state, the “fuzzier” it is, or the more unmeasurable it is, places it more on the left. Thanks so much!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.