Decomposing collaboration

“Collaboration” – a term bandied about liberally yet rarely precisely defined.

Over the past few years it’s been a subject that I’ve spent a great deal of time grappling with for various clients. A great deal of that work is summarized here:

I’ve thought about what are the reasons why an organisation might want it’s people to work together, and to work together more effectively. I’ve spent time trying to understand what are the common systemic barriers to that improvement happening. I’ve defined a series of different types of collaborative teams in which we may find ourselves, and from that drawn some conclusions about how technology might help (or hinder).

The latest analysis is of the technology itself – what are the various components that make up software that is there to help us to work with one another?

Why’s this important? Well, primarily because there is a long-held assumption within the world of technology management which starts from the principal that duplication is inherently bad. There are two stems from which this derives, both of which I believe are probably false:

1. Computing resource is scare, therefore we should use as little of it as possible. And duplication is by nature a wasteful use of technology resource. This assumption was the case for many years, but to all intents and purposes these days the computing resource we have access to is as near as to be free as to not be worth worrying about. There is a separate question of whether duplication leads to other resource problems which we will come to.
2. Organisations need to strive for “One version of the truth”. This is a Utopian aim which fails to take account of the ambiguity of the world in which we live. There is never “one version of the truth” – success in life and business is about negotiating and synthesising ambiguity and conflicting truths.

The duplication of both technology functionality and data is rife in the realm of collaborative software. That there are usually half a dozen ways in any organisation today to achieve the same outcome is problematic. In some cases it might make sense to either reduce options or to provide clear guidance. But if we don’t even understand what types of things you can do in similar ways in different platforms, that spotting of opportunity for reducing the options is impossible. So that’s what I’m trying to do.

In the document you can find here I have identified 12 distinct types of collaborative functionality that you may find in many different tools, namely:

1. Text conversations
2. Audio conversations
3. Video conversations
4. Screen sharing
5. Task management
6. Contact management
7. Event management
8. Content creation
9. Content management
10. Process & workflow management
11. Presence
12. Search

For each one I give a short description, some examples of the types of things that people are doing within these functions, a bit about the sorts of data that might be being generated as a result, and some examples of the types of products in which we might find that functionality.

My hunch is that the most important thing for a team to consider is the type of team they are (Project/Service Delivery/Relationship Management) and the best aggregation of functions that provides what they need (ie a project team will probably be reasonably supported by text conversation services in a tools like Slack or Teams, but a service delivery team would find the text services built within a case management or CRM system more useful).

Anyway, take a look at the document. Feel free to comment, make suggestions and so on.