Next generation work tech has to build on the work graph, not just social networks

Mark Zuckerberg is responsible for popularizing the term ‘social graph’ at the Facebook F8 conference on May 27 2007, as a way of explaining the Facebook Platform’s value proposition: offering up the social relationship data of between Facebook users, and to other social objects (like photos and posts), so that other app developers could simply use it and not have to regenerate it.

The earlier use of the term may have originated with Philippe Bouzaglou who used the term in a paper that applied graph theory to explore the characteristics of the social network it modeled. Dustin Moskovitz, a co-founder of Facebook and now a co-founder of Asana, attended that class with Bouzaglou. People might have gravitated to it also as a helpful disambiguation from the ‘social networks’ like Twitter and Facebook: the category of apps. It comes as no surprise then that people at Asana are using the term social graph, and now have proposed the term work graph in distinction from the more general social graph.

I didn’t initially see that the term social graph offered much over the historical use of the term social network, but now my view has shifted, and for one reason. I always considered the principles of social networks as being derived from graph theory in the first place, but the social graph idea has added to the mix the idea of social objects: the photos, messages, likes, and other signals and information that are shared across social networks. So a simplistic but helpful way to think about it is this:

social graph = social network (people) + social objects (things)

Returning to the notion of work graph, Justin Rosenstein, Dustin’s co-founder at Asana has written a deeply insightful lament about the state of work, and one that echoes a lot of my groaning about the state of work tech tools and our reliance on email:

Justin Rosenstein, The Way We Work Is Soul-Sucking, But Social Networks Are Not the Fix

Surely someday people will look back on us with the same awe, wonder, and sympathy that we look back on previous times: Did they really spend all frickin’ day sitting in front of Gmail and Outlook?

[…]

Meanwhile, the concept of enterprise social networks — and that what works on Facebook will work for businesses — has certainly been appealing. (Not to mention that it creates an enviably straightforward product design roadmap for companies like Microsoft’s Yammer and Salesforce’s Chatter teams: just clone Twitter’s and Facebook’s features, one by one). Such networks do have some advantages over email.

But they are small, incremental improvements. It’s an indication of just how bad the status quo is that even small Band-Aids can represent a billion dollars’ worth of value.

So you might wonder what does he think the answer is? He suggests that we look at the work graph — the network of people (the nodes on the graph) and metadata about them, their relationships (the arcs on the graph), and the ‘units of work’, which are information elements (tasks, ideas, clients, goals, milestones, and so on). And then there are additional schemas — although he doesn’t use that term — that define ways that these work graph elements tie together. And then we must build tools that manipulate objects through work schemas on behalf of people in the work graph: not just passing messages from person to person in the social network.

Rosenstein states that enterprise social networks don’t meet what he thinks is the chief requirement of work tech: Having all the information we need when we need it. I disagree. That has been the value proposition pushed for decades by enterprise software types: the right information to the right people at the right time. But I think he is still correct when he says that today’s work tech doesn’t effectively fit with today’s work graph. But that’s because the now dominant tools are structured around old notions of collaborative control, rather than new notions of cooperative autonomy, and failed to push into emergent value based on strategic learning.

Here’s what he said, though. He gets awfully close to my point above:

The upshot of the latter data structure is having all the information we need when we need it. Where the enterprise social graph requires blasting a whole team with messages like “Hey, has anyone started working on this yet?”, we can just query the work graph and efficiently find out exactly who’s working on that task and how much progress they’ve made. Where the enterprise social graph model depends on serendipity, the work graph model routes information with purpose: towards driving projects to conclusions.

Imagine having more clarity, sanity, confidence, time, and autonomy. Not drowning in email or worrying about whether the i’s are dotted and t’s are crossed. Not having to sit in status meetings or through annoying boss interruptions to find out what’s going on. Instead of worrying about delays or missing deadlines, we can focus on achieving goals and working together effortlessly.

At the heart of this is rethinking how we design our tools. We’ve been able to get by until now on a patchwork of solutions and incremental improvements, but that’s just addressing a need. Attaining our future desires, however, will be about tools that are designed from the ground up for helping people work together.

I totally agree. As I wrote last October

The coming cooperative organization is scary, because it places ambiguity and uncertainty at the center of organization dynamics. It is based on not knowing exactly what to do, in a world increasingly difficult to read. It values experimentation over execution, places agility above process, and puts learning ahead of knowing. It asks more questions than it can answer, and it may not even know how to answer them.

And we certainly don’t have the tools to do that, yet. Visionaries like Dustin and Justin are likely to be the folks cooking up new approaches though, not the large established vendors of last century collaboration tools.