moving a boat together
People assume collaboration comes in one shape and size. That's not the case PHOTO: Phil Dolby

It’s tempting to think that a suite of tools like Office 365 or IBM Connections will meet your collaboration needs. 

However, when I run focus groups to explore digital workplace requirements, asking the question “Where do you do your work?” is often revealing. Rarely is the response the intranet or a social network. Sometimes people answer "email," but more often than not the answer is "in a specialist system." 

Lawyers might work in a case management system, researchers in an electronic lab Notebook, developers in Jira and call centers in a customer service platform like Zendesk.

Yet when people write about "collaboration," they make a tacit assumption about what form the collaboration takes. In the SharePoint world it is usually multiple people working on a document, presentation or spreadsheet. In the enterprise social sphere it is closer to conversation, in Yammer or Slack for example. 

But when somebody makes decisions on a workflow request or plans resources for a work schedule, isn’t that collaboration too? 

When evolving our digital workplaces we run the risk of forgetting other forms of collaboration, and focus on just the things that Office 365 does. 

The model below reminds us of the other ways people work together. It’s essential that we factor these other forms of collaboration into our designs if our digital workplaces are to remain coherent.

The 4 Collaboration Dimensions

Two dimensions determine collaboration types: stability and complexity. Stable collaboration can usually be defined as a repeatable process, making it suited to workflow-type systems (so long as it isn’t too complex). If it is new or constantly changing, then less structured forms of collaboration are needed. 

Inevitably this gives us a 2 by 2 matrix (forgive me, I’m a consultant and can’t resist).

4 types of collaboration
Four types of collaboration

  1. Ad-hoc interaction: In new situations with low complexity, simple collaboration usually suffices. A phone call, quick meeting or even just a chat over the open-plan partition can do the job. People won't even know that they just used a process. However, this only works when the desired outcome is simple to explain. We’ve all seen this model break down when an email request generates a whole string of “What did you mean exactly?” exchanges.
  2. Embedded process: Well understood outcomes with few options lend themselves to a repetitive process — and make the cost of building it into a workflow system worthwhile. Examples in the digital workplace are HR request forms, facility bookings, rota scheduling and pretty much any kind of checklist. When you get many exceptions though, the complexity goes up. Most workflow tools can’t handle this well. That’s when people resort to email and it gets messy.
  3. Expert process: This is for when the outcomes are well understood and you want a systematic approach, but there's a possibility of exception cases and you require a level of judgement. Examples include surveying, fault diagnosis, insurance underwriting and health and safety assessment. If you take the insurance example, 80 percent of applications might fit the embedded process category and can be fulfilled by junior staff or even automated. Twenty percent will be unusual and need review, for example because there is a medical history or an unusual sport involved. Although the problem is complex, using tools that are too unstructured will lead to errors and a lack of auditability.
  4. Rich collaboration: Sometimes the situation is both complex and novel. Imagine a diagnosis where the symptoms are contradictory, or a set of customer requirements for which no service currently exists. Solving it may require some creative thinking, deep diagnosis, trial and error and even debate over what the requirements might be. Horst Rittel coined the term wicked problems for the most extreme of these. Using too restrictive tools will lead to frustration because the bandwidth of communication is too narrow.

Matching Collaboration Tools to the Job

Once you have a grip on the nature of the collaboration involved, it becomes easier to work out the right tool for the job. 

For example, document-based collaboration can work well for an Expert Process so long as the documents are adapted to the particular need. A safety specialist may have several spreadsheets with built-in macros that calculate risk, for example. This is good, but for a digital workplace to do this at scale requires version control to ensure everyone uses the same macros.

What collaboration tool to use, when
What collaboration tool to use, when

Conversely, Ad-hoc Interaction will feel suppressed if conversations are forced into a workflow system. You can see this in call centers where operators fill in a form, but then use post-its or desk-side conversations to explain everything that didn't fit in the form. Simple task-coordination tools like Trello or Office 365 planner can be enough to ensure things don’t get lost. And if the collaboration becomes systematic, then the task cards can become checklist templates.

Interestingly, checklists can help in several of the quadrants. In his excellent book "The Checklist Manifesto," Atul Gawande talks about pilots using checklists for both routine and emergency situations, such as engine failure. The checklist frees one expert up to focus on the essentials (flying the plane is often recommended) while the other pilot can systematically try to resolve the issue under pressure.

Gawande observed that not every workplace is sympathetic to checklists, with some seeing them as too simplistic. I’ve written before about how collaboration culture matters when it comes to choosing tools, but sometimes specialists collaborate in ways that necessitate different tools than everyone else. 

This can get tricky, because using a different tool will create silos. However, it's preferable to using an inadequate tool for the job. The solution lies not in forcing them into a standard, but in channelling the outcome of their work back into the tool everyone else uses.

Further Reading: