The Arc of Collaboration

The arc of collaboration is long and it bends in the direction of functional workflows.

Why Slack is an Else Statement, there is no distinction between productivity and collaboration, and why the Slack of Gaming may be Discord but the Discord for Enterprise is not Slack.

Disclaimer: I currently use every product mentioned in this post, and love all of them.* I also used to work at Greylock and helped with the investments in Discord and Figma. There’s lots of opinions I have on both of them as well as their general spaces. But really you should talk to Dylan Field and Jason Citron. And John Lilly and Josh Elman, who led the investments in both. Because all four have shaped my thinking on productivity and collaboration significantly. And compared to the world they are still living decades in the future on how both are merging and where they are going.

*Except Salesforce, because I am not successful enough to need a Salesforce instance for my personal life.

When Slack first started growing, there were many debates over which company would own collaboration, Slack or Dropbox. Dropbox proponents argued that Dropbox already managed all the actual records of a company, and so would be the center of gravity. Slack partisans argued that Dropbox was a transitory product, and eventually companies would stop caring about individual files, and messaging would be the more important live heartbeat of a company.

Messaging, it turned out, appears to be a better center of gravity than documents. And while Dropbox (barring significant traction in its new products) seems to be fading in its centrality, what’s striking is that Slack’s victory seems hollow as well. If anything we’ve seen even *more* new companies building towards owning parts of these workflows and getting traction.

That’s not a statement on its prospects as a company, or its accomplishments. Slack, even with recent dips in its stock, is a $15B company with very impressive underlying metrics. But there’s this feeling that’s hard to shake.

If Slack won the war, and owns collaboration, why doesn’t it feel like the war is over?

Slack was supposed to be the app that became the OS, the end of the cycle on productivity. But that hasn’t happened. How should we understand what’s happening.

Slack is ubiquitous at most companies in tech (and in many other industries as well), but it doesn’t feel like it is becoming the central nervous system undergirding all the apps and workflows of its customers.

A new generation of functional apps have risen, with messaging and collaboration built directly into them as first parties. And with them it becomes increasingly clear that Slack isn’t air traffic control for every app, it’s 911 for when they fail.

Slack is the 911 for whatever isn’t possible natively in a company’s productivity apps. And though it’s improving, there are still many structural cracks. Slack is current best solution for filling these cracks. But it doesn’t fix the cracks themselves, improved processes and productivity apps are needed for that.

As the ecosystem of specialized SaaS apps and workflows continues to mature, messaging becomes a place of last resort. When things are running smoothly, work happens in the apps built to produce them. And collaboration happens within them. Going to slack is increasingly a channel of last resort, for when there’s no established workflow of what to do. And as these functional apps evolve, there are fewer and fewer exceptions that need Slack. In fact, a sign of a maturing company is one that progressively removes the need to use Slack for more and more situations.

What drives these changes in collaboration? And is there room for one app to focus entirely on collaboration–and if so, what should it look like?

To understand this is to understand that there is no distinction between productivity and collaboration. But we’re only now fully appreciating it.

Separated at Birth: Productivity and Collaboration

Productivity and Collaboration are two sides of the same coin for any team with more than one person. Work is just the iterated output of individuals creating and coordinating together.

But the two have been distinct and isolated segments historically, due to how long the feedback loops of both were.

Post-software and Pre-cloud. Collaboration is external to productivity

What really began our modern era of how to think about collaboration began with the shift to software. Digital work has significantly faster feedback loops for productivity. Software, quite simply, can produce and iterate new things at a daily if not hourly or minute basis.

Suddenly, the constraint on work became much more about the speed and lossiness of collaboration. Which remained remarkably analog. The friction of getting people your document, much less keeping correct versioning was non-trivial.

Even with the introduction of email, people could send each other files—but still had huge coordination costs around versioning.

Cloud – Dropbox and Box

As the industry began to transition to cloud, companies like Dropbox and Box rose. Instead of everyone keeping their own local copies of documents, what if everyone had them pooled in the cloud. Then parts of collaboration like versioning and permissioning could be done across the entire team.

Employees could make changes directly in document, and trust it would propagate to their co-workers. In practice, there were still versioning issues to handle. But it was a significant improvement.

However, this model looks transitory in retrospect. In a pure cloud world, this atomic unit of documents seems increasingly archaic. Documents are more a constraint of a pre-cloud world. And once you assume storing them online is table stakes, the question becomes where is actual collaboration happening that then leads people to wherever they need to do work.

And core Dropbox is not a solution to this. People store their documents in it. But they had to use email and other messaging apps to tell their co-workers which document to check out and what they needed help with.

Dropbox understands this concern. It’s what’s driven their numerous forays into owning the workflows and communication channels themselves. With Carousel, Mailbox, and their new desktop apps all working to own that. However, there are constraints to owning the workflow when your fundamental atomic unit is documents. And they never quite owned the communication channels.

Slack

Slack became the place you messaged your coworkers and sent them links to the work you wanted them to check out. They began to displace Dropbox as the center of gravity for companies.

The dream of Slack is that they become the central nervous system for all of a company’s employees and apps. This is the view of a clean *separation* of productivity and collaboration. Have all your apps for productivity and then have a single app for coordinating everyone, with your apps also feeding notifications into this system.

In this way, Slack would become a star. With every app revolving around it. Employees would work out of Slack, periodically moving to whichever app they were needed in, before returning to Slack.

But productivity *isn’t* separate from collaboration. They are the two parts of the same loop of producing work. And if anything collaboration is in *service* of team productivity.

What is Slack, really?

There has been much pushback to Slack in recent years. Often centered around this feeling that Slack is distracting and not productive. As with any successful app, much of it is the gripes that come with any app that is successful enough to become a significant part of your working life. But there’s an underlying current to these critiques that I think is real but people struggle to pin down precisely.

It’s not that Slack is too distracting and killing individual productivity. It’s that your company’s processes are so dysfunctional you need Slack to be distracting and killing individual productivity.

Slack is not air traffic control that coordinates everything. It’s 911 for when everything falls apart.

Every slack message about a new document your feedback is wanted on or coordinating about what a design should look like is a failing of process or tools. Slack is exception handling. When there’s no other way to make sure someone sees and update, or knows context, Slack is the 911 that can be used.

Slack serves three functions:

• 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.
• Watercooler. Slack is a social hub for co-workers. This is very important, and full of gifs.
• 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.

There is an entire separate essay to be written about meta-coordination. Which I think can have very different outcomes from functional workflows. We may be very far from formalization of meta-coordination and less concrete strategy planning. Which means unstructured text, meetings, and video calls could be the best current functional workflows for them for a while. But for our purposes of this essay will put that as out of scope.

As a company’s processes mature and the apps they use get more sophisticated, we expect to see the need to go to Slack for exception handling *decrease* over time. (Though of course, the complexity of the overall company may increase at a faster pace than this maturation, leading to a net increase in slack messages).

These three functions are incredibly important. From the perspective of owning the process of doing work, they point at interesting relationship.

Slack’s importance is inversely tethered to the rate at which functional workflows within companies become legible and systematized. Both at an operational level, and long term at the meta-strategic level.

And this makes sense. The platonic flow of productivity should minimize time spent not productive, with collaboration as aligned and unblocking with that flow as possible. By definition, any app that requires you to switch out of your productivity app to collaborate is blocking and cannot be maximally aligned. It’s fine to leave your productivity app for exceptions and breaks. But not ideal when working (and not having issue).

Functional workflows rule everything around me

Slack ironically is more similar to Dropbox than expected. The more time goes by the more it looks like exception handling being needed ubiquitously is a transitory product as we switch off of documents. After all, like Dropbox, Slack makes the most sense as a global communication channel when the workflows themselves don’t have communication and collaboration baked in natively. For documents this is true, but increasingly for modern apps this is false.

As it becomes more clear what are specific functional jobs to be done, we see more specialized apps closely aligned with solving for that specific loop. And increasingly collaboration is built in natively to them. In fact, for many reasons collaboration being natively built into them may be one of the main driving forces behind the venture interest and success in these spaces.

As these apps proliferate, there is less and less need to turn to Slack. And Slack becomes more and more about the edge cases that aren’t yet built in.

Github is a great example of this for the engineering side. Salesforce for Sales. Out of scope of this essay, but there’s lots to write about this and I’d generalize Shopify as being part of this as well.

But for our purposes, let’s use an example, Figma.

Figma

Figma is a collaborative design tool. Unlike Sketch or Photoshop, Figma has collaboration built in natively as a first party. This means the ability to comment on designs. But it means much more too. It means the ability to design together at the same time. To be able to send a live demo to someone frictionlessly and then be able to make live changes as you talk to them. It means being able to build design systems that are reusable and plugins that are shareable.

Figma shows what collaboration means when you understand that collaboration is *intimately* part of productivity. And always has been.

If you are working on a design Figma handles all communication. There’s no more need to send an updated file on Slack. Or type in feedback on Slack. Or make a change and let someone know on Slack. And as Figma increases the scope of their app and adds more team and enterprise features. Even for sharing with non-designers on the team, the need for external communication falls.

And as Figma expands into plugins, the ecosystem will continue to solve for more and more of the needs and exceptions.

Over time, our workflows align with our functional flows. And collaboration is no exception.

And Figma is not alone. More and more apps in all categories understand that collaboration should and must be built in as a first party if they want to best serve their customers. Notion, Airtable, etc all understand this. The feedback loops of collaboration get so short that they become part of the productivity loop.

The future increasingly looks like one where companies use very specific apps to solve their jobs to be done. And collaboration is right where we work. And that makes sense, of course. Collaboration *should* be where you work.

Meta-coordination

It should be noted, that meta-coordination adds nuance to this. Just as we increasingly productize the functional workflows. It allows us to start to be better at the meta-coordination at longer timeframes. Which could have standalone functional apps that specialize in these slower cadence coordination problems. Slack and Zoom are both possible answers in this regard. As are apps working in todos, project management, etc.

The efficient frontier of meta-coordination is fascinating. Over time we see productivity apps eat up the stack. Google docs is a good example of the abstraction layers of coordination.

Google docs is good at line level commenting. So for this low level of coordination it excels. Which when sending word documents was the current state of the art, felt advanced. But increasingly, feels limited for higher abstraction levels of collaboration. As apps like Figma build in deeper collaboration.

Can there be a meta-layer?

This isn’t to say that there cannot be a horizontal collaboration app that is core to the productivity workflows. But it likely cannot be blocking to productivity. It can’t be a peer level app that is standalone. Instead it must work across and within each productivity app.

Standalone messaging is not what ties all apps together. It is a peer level product that’s used where the others fall through.

However, there is a need for a layer across all the applications. A layer for things that should be shared across the apps as well collaborative functionality across them.

Slack in its current form cannot be this. If you have to switch out of a product to use Slack, then it is not the layer tying them altogether. Instead, the layer needs to exist a layer above. If everything was in browser it’d be a browser extension. But since most apps are not, it needs to be at the OS layer.

There is some mix of presence, collaboration, coordination, and identity that should be ubiquitous across whatever apps are being used. A layer more attached to the people doing work and what they’re trying to accomplish—than which specific app they’re in.

Perhaps one of the closest to this we’ve seen was Screenhero. After all, the idea of screen sharing is inherently about collaboration while working within productivity apps.

But it made the decision to be downstream of Slack, not upstream. It assumed Slack would be the central nervous system for people at work, and people would switch over to Screenhero from Slack. It traded scope for distribution. And got neither.

KK note: It was acquired by Slack in an all equity acquisition. So to be clear it was hugely successful

But there *is* a non-enterprise example of what this layer might look like.

That company is Discord.

Discord

Discord is the best analog for what should exist. For a while Slack and Discord were compared to each other as competitors. As Discord has focused squarely in gaming, and Slack in companies this comparison has been used less and less.

But this misses the main distinction between Slack and Discord.

Discord is actually two products bundled into one. It *is* a messaging app that looks akin to Slack. But it is *also* a meta-layer that runs across all games.

Beyond its Slack-like functionality, Discord has functionality like a social graph, seeing what games your friends are playing, voice chat, etc. These have been misunderstood by the market. They aren’t random small features. They are the backbone of a central nervous system.

Active users of Discord have it on all the time, even when they are not playing games. It’s a passive way to have presence with your friends. And when your friends start playing games it makes it easy to with one click go join them in the game. Bringing your actual social graph across all games. Finally, voice chat makes it possible to talk with your friends across all games, even when you are playing the game. Like when working in a google doc, having to switch out of your game to message is a negative experience. Instead Discord adds functionality to your games even while you are focused solely on them.

We will see more companies understand and begin to work on this area.

Final Thoughts

Abstracting out of productivity and collaboration apps into the processes themselves, there’s something beautiful at how much we’ve improved and continue to improve at the process of working together with other humans.

In Making Uncommon Knowledge Common I said “One way the tech industry can be viewed, is a process by which we collectively push forward our understanding of industries and new business models.”

And perhaps a company is just a process that hopefully compounds and improves in its ability to serve its customers.

But underlying both of these is the most beautiful loop of them all. Progress is a process by which humans compound and improve on our ability to work together better for the things we care about.

Like distributed computing, it has turned out that for most of human history coordinating among humans has been a slow, intractable, sisyphean effort. In the last few decades we have seen tremendous technical breakthroughs in the latencies and tooling possible to remove these constraints. Across the world, whether in productivity apps or in national governance, there will be a transition period as our norms and processes adapt to this tightening of the collaboration feedback loop. But perhaps I remain incredibly bullish on what it means for our alignment and output as we increasingly systematize and make sense of these.

Our ability to compound together at compounding together is our most beautiful trait.

Appendix

Appendix: Distribution

Of course, an approach like Discord for enterprise will need novel acquisition loops. This type of collaboration has strong intra-company network effects at scale. But lacks trivially obvious inter-company network effects or pre-liquidity loops.

Out of scope for this essay. And don’t quite want to get into the tactics I think would be effective here. That said will note a general framework here.

If you look at most collaboration companies’ loops there are a few dimensions to categorize most of the tactics and loop sequences by:

• Single player vs multiplayer
• Intra-company vs Inter-company
• App required vs no app required
• Synchronous vs Asynchronous
• Personal capital vs Social capital driven

A company working in this space has significant surface area for novel growth loops at each combinatorial set of these.

Appendix: Fortnite and Epic

Discord is also useful for understanding what comes after this stage as well. If you look at Discord. One potential TAM constraint is if gaming becomes 1) power law with low ecosystem churn and 2) not monetized via purchase.

Fortnite and Epic is the best example of this potential. And Epic’s playbook in launching their app store vs Steam is a case study in how a dominant enough app can move up the stack if it has enough sway over end consumer attention.

There are similar lessons for companies selling to other companies. And we’ve already seen examples of these in specific industries. So always, something to watch for.

Credits

Many thanks to Keila Fong, Saam Motamedi, Dave Petersen, and Eugene Wei for the many discussions about this topic, their help with this post, and their unceasing pressure to publish it.

Furthermore, even more thanks to Keila without whom these super professional quality stick figure drawings would not have been possible.

Though they didn’t pre-read this post, also want in particular to thank John Lilly, Josh Elman, Dylan Field, and Jason Citron. All of whom have heavily influenced my thoughts on productivity and collaboration. And compared to the world they are still living decades in the future on how both are merging and where they are going.