
A friend shared this fascinating read by Kevin Kwok:
It’s a thoughtful thesis on the state of enterprise/business tools and the apparent tension between productivity and collaboration, as epitomized by the use of Slack.
Starting with Slack as the jumping-off point, Kwok acutely observes that, currently, Slack usually serves three main functions:
1. “Else” statement. Slack is the exception handler, when specific productivity apps don’t have a way to handle something. This should decrease in usefulness, as the apps build in handling of these use cases, and the companies build up internal processes.
2. Watercooler. Slack is a social hub for co-workers. This is very important, and full of gifs.
3. Meta-coordination. Slack is the best place for meta-levels of strategy and coordination that don’t have specific productivity apps. This is really a type of ‘else statement’, but one that could persist for a while in unstructured format.
The first one is worth digging into. In essence, the prominence of Slack is a result of existing business tools not supporting some essential collaboration capabilities. Slack fills these collaboration gaps (as well as supports 2&3 above). To use Kowk’s eloquent yet slightly hyperbolic metaphor:
Slack is not air traffic control that coordinates everything. It’s 911 for when everything falls apart.
And we are seeing some of those functional gaps starting to get closed, by native, in-app capabilities. All “GitHub for X” collaboration-first products fall into that category. Kwok highlights Figma (Design), to which I’d also add Abstract (Design) and GitBook (Docs) to show that this more than a single-product trend. The ripples in the collaboration pond originated in engineering (GitHub) and permeate outward starting with engineering-adjacent roles (designers, technical writers) with the first ripples reaching as far out as HR.
But there seems to be a huge missed opportunity here, since the need for collaboration is function/work-product agnostic. By building in-app collaboration capabilities the walls between apps become higher and cross-app interoperability becomes harder. Not to mention the increased cognitive load on the user.
Kwok looks at Discord as a different potential direction/inspiration for a tool that provides a set of collaboration capabilities (text and voice chat) across a set of functional workflows (games), stemming from a similar unfulfilled gap around collaboration caused by the poor in-game chat/collaboration capabilities. While the analogy has its limits, it does highlight an exciting path forward.
The depth of desired collaboration on an MMORPG game and a business app (if you need a mental image: think a PPT/Keynote/Gslides presentation) is different, while the former often stops at coordination, in the latter we aspire for co-creation. This has a couple of concrete implications:
1. Functionality-wise, lofty “collaboration” can be decomposed into a set of shared cross-product capabilities:
This list is probably incomplete, but the immediate capabilities that come to mind are:
- Unique user identity — mostly already solved today via “login-with-Google” type solutions.
- Hyper-granular permissions — providing edit/comment/view access to a subset of the work product. Think a single slide in a deck or a set of rows in a spreadsheet.
- Synchronous and asynchronous co-creation — I’m making a distinction here between “two people writing in a GDoc at the same time” and “Person A using the “suggest” feature to offer specific changes to Person B”. Both are needed. Both are relevant across all work products.
- Versioning —used here as a catch-all for the entire GitHub functionality including but not limited to: fork, branch, pull request, diff, and partial/selective merge.
- In-line commenting —having a dialogue about a specific piece of the work-product
- Decision-making — decision-making is used here in the narrow context of making decisions about changes to the work-product, not in the broad context of making business decisions facilitated by the work product. Today, only a single decision-making mode is supported, by some of the products: a single autocratic “owner” accepting changes made by “collaborators”.
2. An ideal solution will seamlessly integrate with the existing functional UIs
The breadth of work-products that we want to collaborate on justify the existence of multiple “creation/authoring” UIs. Any UI that will try to reduce collaboration on code snippets, presentations, and spreadsheets, just to name a few various work-products, into a single UI will most likely have to do so at the expense of depth of collaboration that it can support. An ideal solution will look more like Grammarly’s browser extension, which provides cross-product writing quality support, or like a “collaboration SDK” which multiple products can adopt.