The twelve posts of Christmas, part 2

I interviewed Susan Scrupski, the founder of Change Agents Worldwide, back in February, and she shared her thoughts about building a network of change agents that work with or in large companies.

SB: You’ve now started Change Agents Worldwide. What’s the vision for that group?

SS: My vision has remained constant since I started tracking this space. I’ve always advocated for advancing the liberating, evolved freedoms that come along with the adoption of more human-based technologies and processes for the large enterprise. I learned a lot about networks and how people behave and what they can achieve together in networks via my experience with the Council. More importantly, I learned that there are a lot of people around the world who share my beliefs, and that there is a certain DNA required to do this sort of work.

Change Agents Worldwide is the next evolution of the work I’ve been doing since 2006. The group’s vision is squarely centered on helping large companies transition from old world models established in the industrial era to modern network-based, agile models that improve not only the work experience for the workforce, but lead to top-line gains in innovation and growth. We are a small cadre of professionals from various disciplines (HR/learning, IT, Marketing, R&D, OD, KM, Innovation) who share the same vision and values, and we run our company in the way we’re advocating by putting these principles in practice.


We see ourselves more as a coalition and engagement within our network is fairly high. When we’re talking about project work, we like to describe our network as a “collaborative sharing economy model for consulting.” We don’t have employees; we have network members who consult. So, the same way Airbnb is in the hospitality business without hotels, we are in the consulting business without employees.

I wrote about the history of the terms social graph and the work graph back in May (see Forget the social graph: pay attention to the work graph):

However, over time I came to appreciate that the social graph is actually a larger formulation than social networks: it is a graph (or network) of people as well as social objects — the things that people are talking about, or sharing, that shape the relationships between the people in the social networks.

It turns out that the term was originally offered up by my friend, Jyri Engstrom, the founder of Jaiku, back in 2005, when he wrote Why some social network services work and others don’t — Or: the case for object-centered sociality:

Social network theory fails to recognise such real-world dynamics because its notion of sociality is limited to just people.

Another friend, the cartoonist Hugh MacLoed (@gapingvoid) popularized the term in the years following, as in Social Objects for Beginners.

Justin Rosenstein of Asana spelled out that in the work context the social graph becomes the work graph,

A work graph consists of the units of work (tasks, ideas, clients, goals, agenda items); information about that work (relevant conversations, files, status, metadata); how it all fits together; and then the people involved with the work (who’s responsible for what? which people need to be kept in the loop?).

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.

And I concluded that the problem with conventional work management tools stray too far from the work graph:

My sense is that the reason we are seeing a stall in the uptake of the current generation of work media apps (enterprise social networks, social ‘collaboration’ tools, etc.) is that they don’t stick close enough to the work graph and pull communications, and focus too much on the network and push communications.

Don’t get me wrong. I am not saying all we need is a shared file system and a way to chat. On the contrary. But we have to get the dynamics right. When people are talking about work, or sharing work objects, the objects must almost be treated as people too, with deep metadata, persistent identities, and following/follower relationship with other objects and people in the graph.

In Why do Americans work so much?, I looked at the numbers showing that 85.8% of US men and 66.5% US women work more than 40 hours per week, almost 500 hours per year more than the average French worker.  And it doesn’t make us happy.

We should learn from the Danes, the happiest nation on Earth.

As Alexander Kjerulf points out,

Not only do Danes tend to leave work at a reasonable hour most days, but they also get five to six weeks of vacation per year, several national holidays and up to a year of paid maternity/paternity leave. While the average American works 1,790 hours per year, the average Dane only works 1,540, according to Organization for Economic Cooperation and Development (OECD) statistics. Danes also have more leisure hours than any other OECD workers and the link between sufficient leisure and happiness is well established in the research.

Only 10% of Danish workers are actively disengaged as work, compared to 18% of Americans, and one of the key factors is overwork. We need to expect — demand — a work environment that is based on work happiness — or what the Danes call arbejdsglæde — and

spend more time daydreaming, learning new skills, walking the dog, or relaxing with friends and family.

A few weeks ago, I wrote about the information deluge, and how companies are not doing a great job helping workers deal with it.

The Deloitte team cited Julian Birkinshaw and Jordan Cohen, who researched how knowledge workers can deal with demanding schedules and they found, unsurprisingly, that the best course is to eliminate or delegate unimportant tasks and spend more time on important ones. Forty-one percent of an individual’s time is wasted on discretionary activities that could be handed over to others to make room for important, fulfilling activities or more down time.

The pair led “interventions” with 15 executives at different companies with this strategy, and it led to six hours less of desk work and two hours less of meetings. At one company, a sales exec chopped administrative tasks and meetings to focus on helping her staff. Sales increased 5 percent over a three-week trial period.

These are the costs of feeling entangled in a web of commitments that many company cultures engender. Instead of trying to decrease overcommitment and making the company fast-and-loose, there is a steady pressure to focus on nonessential, time-wasting activities: sitting in on weekly status meetings, reading reports from other groups, filling out expense reports. All those should be eliminated.

When forty-one percent of the average person’s work time is spent on inessential tasks, it’s easy to see why companies slow to a crawl as they grow, because of more and more wasted time.

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.