Work Collaboration v2.0
Thoughts on the tools we use, the culture they foster and how they can be better
Because of COVID, most of my day-to-day interactions take place over Slack or Zoom. I think this is an appropriate time to discuss how these tools could be better, especially for remote workers.
The crux of my argument is simple: the tools we use to communicate are separate from the tools we use to get the actual work done. On the other hand, most offline industries don't adhere to such nonsense. Chefs don't leave the kitchen every time they want to discuss how much salt to use. Painters don't leave the room they're painting to decide how many layers of paint to apply. The work occurs alongside the talk. Kevin Kwok phrases this eloquently in The Arc of Collaboration: "Work is just the iterated output of individuals creating and coordinating together". It's no surprise remote teams struggle with collaboration. Most of the tools they use aren't designed to be collaborative.
My hunch is that most of our programs are like this due to technical precedent. They were originally built for individual usage vs. team usage. Adding video chat or DMs was technically complex. The value added by including these services natively was not worth the cost. Now, we have APIs like SendBird, Daily.co, and open-source tools like Centrifuge. These APIs are easier to implement and well worth the cost, enabling any tool to become multi-player.
Company Culture and Workplace Tools
In the 1960s, Canadian philosopher Marshall McLuhan said "the medium is the message". The gist of his argument is that the medium in which information is communicated can heavily influence the engagement with the information. Different mediums provide different affordances. It's important to note the relationship between our company cultures and the mediums we use to communicate. Because of this, a purely synchronous or asynchronous tool doesn’t work well for teams.
It’s important to note the distinctions between synchronous and asynchronous tooling. Synchronous tooling requires the presence and participation of all parties at that moment in time. Examples of synchronous tools are video conferencing, certain types of chat and phone calls. Asynchronous tooling, on the other hand, allows for staggered conversation because it doesn’t require all parties to be active at the same time. Commenting and voice memos are examples of asynchronous mediums.
When a platform, like Slack, decides to go all in on real-time chat, it influences how individuals work. Slack is a purely synchronous  workplace tool. In companies that use Slack, I've noticed a more prevalent “always on” attitude . Certain affordances of the medium, such as rapid fire messages and quick collaboration, naturally evoke the same behavior even after the workday ends. On the other hand, an async medium (i.e.comments on Google Docs) won't capture the same level of urgency, leading to slower work cycles. Because of the staggered nature of asynchronous tooling individuals spend extra time context switching.
Providing both synchronous and asynchronous features allows for more flexibility. Teams can then leverage the communication styles that work best for them. Users can customize the medium, allowing it to convey urgency and other necessary signals.
: I consider real-time chat more synchronous than async hence why Slack is synchronous.
: In Slack's defense, they've added features to help mitigate this: DND, "It's x PM...", Time-constrained notifications
Documentation and Teams
It's no secret that good programmers write good documentation. Given that codebases can be so complex, documentation provides a glimpse into the thinking of the programmer that wrote the code. It enables another developer to gain context about the decisions made, what something does, and its purpose .
When creating a product feature, a new organization hierarchy, or even a deck of slides, it'd be useful to leave a trail of thoughts about the motivation behind certain decisions. Team members would better understand each other, reducing redundant discussions and work. In fact, we have this! It lives in our message histories with other individuals that are a part of that process, yet it's never published. Instead, what's published is a one-pager with a heavy dosage of hindsight bias. In the book The Pragmatic Programmer, there's an emphasis on creating documentation as you code vs. afterwards. Documentation that's written after the code is less likely to be correct or up-to-date.
Google Docs does a great job of this. I've seen documents with comments that litter the sides of the page and that often are more important than the doc itself. The final document represents an end state whereas the comments and message history represent the journey. Oftentimes, this is where you will find the real knowledge.. Large corporations would benefit from coupling their communication applications with the tools used to get work done solely based on the value-add of effortless documentation.
: The idea of non-technical documentation has built massive companies (see Notion, Coda).
When multiple tools build their own communication features, it causes fragmentation of conversations. Below are some implementation details I envisioned as I thought through this that also might solve this core problem.
On a high level, the platform should:
Be coupled with the tools people use at work
Organize conversation based on tool and/or task
Provide a mix of async/sync features, allowing users to choose appropriately
With these constraints in mind and a goal to reduce fragmentation of conversations, here’s how a potential solution may look:
Real-time chat across major work-based websites for MVP (JIRA, Notion, GDoc, Salesforce, Figma, etc)
Real-time chat grouped by site and by topic (Enter Salesforce and see all conversations had on Salesforce regarding a certain sales cycle)
Commenting (or some form of markup) on sites to allow for more async conversations
Packaged as a Chrome extension, with New Tab as the “Home” for all convos and work topics.
If you want to build this (or are building this), let’s chat!
Product Study: Inverse
Inverse is the closest implementation of what I like to call “Work Collaboration v2.0”. It enables threads across all websites with a team via a Chrome extension. It does a great job handling general documentation: You can open a Salesforce page and see all the comments from your team regarding that page.
Inverse also feels very async. The UI and UX of the threads don't feel real-time . It's a cool implementation and even has use-cases when used individually. Best of luck to its creators, Haris and Sunil!
: For a documentation use case, this is a perfect medium. This is how I use Inverse in single-player mode.
Product Study: Loom
Loom is another great example of Work Collaboration v2.0. I realized this after watching @ryandawidjan use Loom as a way to expand on an idea he’d tweeted about.
Loom does a couple things from the high level implementation notes above. Mainly, it’s coupled with the tools you use to get work done. Screen recording is ubiquitous. It exists on every tool you’d use to get work done on your computer. Similar to Inverse, it’s also very async with features like commenting and async video. I’m excited to watch Loom grow and see what new use-cases they’ll go after!
If you read this far, thank you! I hope it was worthy of your time. Thank you to Adam, Ivanna, Rory and David for reading drafts of this!