Collaborating without documents in the digital workplace
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, a fascinating question to ask is “Where do you do your work?”. The answer is rarely ‘the intranet’, or a social network. It is sometimes ‘e-mail’ but surprisingly often it is in a specialist system. For lawyers it might be a case management system, for researchers an electronic lab Notebook, for developers Jira and call centres a customer service platform like Zendesk.
Yet when people write about ‘collaboration’ there is often a tacit assumption about what form that 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?
There’s a risk when evolving our digital workplaces that we forget other forms of collaboration, and focus in on just the things that Office 365 does. Here I want to share a model that reminds us of the other ways people might be working together. It’s essential that we factor these into our designs too if our digital workplaces are to be coherent.
We can think about collaboration types as being determined by two dimensions: 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×2 matrix (forgive me, I’m a consultant and can’t resist).
- Ad-hoc interaction. When a situation is new but the complexity is low, simple collaboration is likely to be enough. It can be worked out with a phone call, a quick meeting or even just a chat over the open-plan partition. It is unlikely that people are even aware a process has been used. 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.
- Embedded Process. When outcomes are well understood and options are few, then it is easy to repeat and the cost of building it into a workflow system is 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, and most workflow tools can’t handle this well. That’s when people resort to email and it gets messy.
- Expert Process. This is when outcomes are well understood and a systematic approach is desirable, but a level of judgement is required and there may be many exception cases. Examples include surveying, fault diagnosis, insurance underwriting and health and safety assessment. If you take the insurance example, 80% of applications might fit the embedded process category and can be fulfilled by junior staff or even automated. 20% 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.
- 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 tools that are too restrictive will lead to frustration because the bandwidth of communication is too narrow.
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, there needs to be version control to ensure everyone uses the same macros.
Conversely, Ad-hoc Interaction will feel oppressed if conversations are forced into a workflow system. You can see this in call centres where operators fill in a form, but then use post-its or desk-side conversations to explain everything they weren’t able to put in the form. Simple task-co-ordination 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 be useful 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 your collaboration culture matters when it comes to choosing tools, but equally if the type of collaboration for some specialists may mean they can’t use the same thing everyone else does. This can be tricky, because using a different tool will create silos. However, this is better than 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.