Tag Archives: economics

Thinking in networks: what it means for policy makers

Elegant, influential theories have a way to rewire your brain. In my formative years, it was not uncommon to joke that Marxist intellectuals could and would explain absolutely anything in terms of Marxist dialectics. For all our joking, exactly the same thing happened to me, as I dug deep into neoclassical economic theory. I did have access to non-neoclassical theories, but in the end it is the math that makes the difference. Mathematics gives you a grip on the model: by manipulating it, you can stretch it, adapt it, critique it, own it in a way that you can’t really any other way. In the end, the mathematical tools you use to think about the world become a default way to parse empirical data: when your only tool is a hammer, you see every problem as a nail and all that.

The hammer of neoclassical economics is functions. Not just any old function: convex, continuous, differentiable ones – designer functions with smooth hypersurfaces. If everything is a function of this kind, everything (say, your country’s economy) must have a maximum, because (bounded) continuous, convex and differentiable functions have exactly one max. This means there is a perfect (“optimal”) state of the world. You find it by calculus. You can then hack your way around the system with taxes, subsidies and interest rates until you push the economy to that maximum. If you are a consumer, or a worker, you also will be looking at a function, representing your well-being. Again, you can find its max, fine-tuning savings and consumptions, work and leisure into your personal sweet spot. There’s no such thing as unemployed: hey, the function is not discrete! What you are seeing is people that choose to allocate zero hours to work, given the existing wage rate (I exaggerate, but not much).

I spent the past five years learning how to use a new mathematical tool: networks. Going deep into the intuition of the math (as opposed to memorizing the equations) means, in the long run, a rewiring of your brain. What used to look like a nail suddenly makes much more sense as a screw. A good thing, since you are now the proud owner of a screwdriver! What I am seeing now as I consider public policies is this: I think of them as signals that the policy maker sends out. The interesting question is what carries the signal.

Traditional policy signals are broadcast: every agent in the economy receives the same message. Price signals (hence taxes and subsidies, too) are broadcast. So, in general, is regulation. Broadcast makes a lot of sense in an undifferentiated mean: if you want to reach a large number of recipients and they are all disconnected from each other, it’s a good technique. Just push that signal out in all directions, as loud as you can.

Once you really take networks on board, though, you start seeing them everywhere. And when you have all sorts of networks that could carry the signal for you, broadcast seems a blunt way to do things. Consider AIDS prevention policies. Broadcast policy sees that, as a category young people are more likely than old-timers to engage in unsafe sex, so it puts posters up in high schools. Since you can’t really be too graphic about it for political reasons, such posters tend to be quite bland, and immediately drowned by far stronger broadcasting signals that glorify sexual prowess and availability, those of commercial markets. Even if your average teen does become more careful, the epidemics still spreads through the very promiscuous few, who are unlikely to be impressed by a bland poster. All in all, near-zero impact is a good guess.

On the other hand, research has shown that networks of sexual partnerships are scale-free: a small number of individuals (not categories) have a very large number of sexual partners. These people are the main vector for the virus to spread. So here’s the networked version of AIDS prevention policy: go talk to the hubs. Dispatch researchers to identify them (it does not matter where you start, with scale-free networks it will take a small number of hops before you get to one); have one-on-one conversations with them. Spend time with them, they are important. Show them the data. Hire them, even. Should be cheap: it’s only a handful of people, who can have a disproportionate amount of impact on the epidemics by switching behavior. See the difference in approach?

In my talk at Policy Making 2.0 last week I tried to explore what it means, for policy makers, to think in terms of networks. I proposed that the gains from doing so are:

  1. impact: more bang for your taxpayer buck.
  2. reduced iatrogenics: policy becomes more surgical, so it causes less unintended damage.
  3. robustness to “too big to know”. Very simple network models exhibit sophisticated behavior. You can model several real-world phenomena without losing your grip on the intuition of the model, and therefore make more accountable decision.
  4. compassion. Networks owe their uncanny efficiency in carrying signals to large inequalities in the connectedness of nodes. Further, it is easy to build very simple models that produce inequalities even with identical nodes. This, at least for me, gets rid of the “underserving poor” rhetoric and fosters simpathy towards the smart and hard-working people out there that found themselves on the wrong side of system dynamics.
  5. measurability. Social interactions that happen online are now cheap to keep records of; you can use those record to build networks of interactions run quantitative analysis on them.

If you want to know more, you might find my (annotated) slides interesting. I am indebted, as ever, to the INSITE project and to all participants in Masters of Networks.

Why network science is humbling

(dedicated to Benjamin Renoust)

For several years now I have been fascinated with networks. While I have grown to appreciate the internal coherence and beauty of the math, as soon as I lift my gaze from the models and try to use them to tell complicated, real-world stories I am a part of (like Edgeryders, or the unMonastery), I struggle with counterintuition. Duncan Watts’ beautiful book hits the nail on the head: since we are humans, we tend to overestimate the role of humans in how things unfold. By implication, we underestimate the role of other factors at play, like chance or, indeed, network effects. Highly connected individuals in a scale-free social network (say, people with million of Twitter followers) are, understandably, tempted to claim credit for their privileged position. And yet, we have rock-solid models that explain the emergence of hubs based purely on the (realistic) characteristic of the growth process of a network – even when nodes are identical.

Of course, you could build more sophisticated models, in which nodes are different from each other. That would make them even more realistic: indeed, people do have different abilities, and in many domains these abilities can be ranked. Clay Shirky’s blog posts are better than mine. He deserves to have more incoming links than I have. But here’s the thing: network math can explain rich, complex behavior by assuming identical nodes and focusing only on patterns of connectivity. In fact, that’s the whole point . As you make that move, your math gets much more elegant and tractable: you get a model building strategy that carries through to a very broad range of phenomena (networks of genes,of food ingredients in recipes, of intermediate goods in an economy, of relay stations in a power grid…). But most importantly, if you, like me, are ultimately interested in networks of humans, you find yourself staring at a counterintuitive, yet probably fundamental, conclusion:

Identity. Does. Not. Matter.

Or, more accurately, your pattern of connectivity – for modelling purposes – is your identity. In most models, you can start with identical nodes, add some randomness and watch the system create hubs of influence and power. Given how uncanny the predictive power of these models is, it is hard to escape the conclusion that they describe reality to some degree; in other words, that who we are is largely the product of chance and network math.

I find this thought beautiful and humbling, in a way that I can only describe as almost religious (even though I am not a believer in any faith). As I contemplate it, I feel somehow closer to my fellow humans, the powerful and connected as well as the weak and isolated. This may sound like not very scientific a conclusion, but I feel it is not a bad stance for social scientists and economists. Our disciplines can always use some extra empathy. Within the context of the Crossover project, I have been advocating for network analysis to be included in the toolkit of the modern policy maker; empathy is yet another argument for doing so.

Meet the dragon hatchling: herding emergent behavior in an online community (long)

This is not a post, but rather an essay, longer than my normal posts. It concerns the Dragon Trainer project, that I already mentioned in this blog: together with my colleagues at University of Alicante and European Center for Living Technology I am researching a software for early-stage diagnose of emergent social dynamics in online communities, and for helping community managers to make informed decisions. I think it will be only the first one of a series.

Why is this important?

For some time now policy makers have been fascinated by entities like Wikipedia: non-organizations, loose communities of individuals with almost no money and no command structure that manage, despite this apparent lack of cohesion, to collaborate everyday in producing complex, coherent artifacts. Such phenomena are made even more tantalizing by the uncanny speed and efficiency with which they do what they do. Can we summon Wikipedia-like entities into existence, and order them to produce public goods? Can we steer them? Can we do public policy with them?

In order to do so, we will need to learn to craft policy into a new space, which – following Lane and others – we call the meso level. Such policies will not be targeted at individual behavioral change (micro policies); nor at the economy or the whole society (macro policies). They will be targeted at achieving certain patterns of interaction between a large group of people. Individual may and will move in and out of these patterns, just like individual water molecules move in and out of clouds; but this does not much affect the behavior of the cloud.

Operating at the meso level – running an online community of innovators, for example – entails managing a paradox. Structuring interaction among participants as a network of relationships, of which participants themselves are the nodes, can result in extremely effective and rewarding participation, because – under certain circumstances – each participant is exposed to information that is relevant to them, while not having to browse all the information the community knows. This results in a very high signal to noise ratio from the point of view of the participants; they often report experiences of greatly enhanced serendipity, as they seem to stumble into useful information that they did not know they were looking for and was sent their way by other participants.

This extraordinary efficiency cannot be planned a priori by community managers, who – after all – do not and cannot know what each individual participant knows and what she wants to know. The desirable properties of networks as information sharing tools arise from the link structure being emergent from the community’s endogenous social dynamics. The paradox stems from the fact that endogenous social dynamics can and often do steer online communities away from its goals and onto idle chitchat or “hanging out”, that seems to be the default attractor for large online networks. So, managers of communities of innovators need to let endogenous dynamics create a link structure to transport information efficiently across the network while ensuring that the community does not lose its focus on helping members to do what they participate in it to do.

Building Dragon Trainer: a case study

With this in mind, I joined forces with emergence theorists, network scientists and developers to build the prototype of Dragon Trainer, an online community management augmentation tool. It models an online community as a network of relationships, and uses network analysis as its main tool for drawing inferences about what goes on in the community. Generally speaking community managers build knowledge of their communities by spending a lot of time participating rather than using formal analysis; and they act on the basis of that knowledge by resorting to a repertoire of steering techniques learned by trial and error. The error component in trial-and-error is usually fairly large, because by construction there is no top-down control in online communities; the community manager can only attempt to direct emergent social dynamics towards the result that she sees as desirable. Control over the software does give her top-down control in the trivial case of prohibition: by disabling access, or comments, she can always dampen activity directly. What she cannot do without directing emergence is enhancing activity – which is what online communities of innovators are for.

DT aims at augmenting this approach in two ways. Firstly, it allows the community manager to enrich the “local” knowledge she acquires by simply spending time interacting with the community. Such knowledge is extremely rich and fairly accurate for small communities, but it does not scale well as the network grows. Network analysis, on the other hand, scales well: computing network metrics on large networks is conceptually not harder than doing it on small ones, though it can get computationally more intensive. In an ideal situation, a community manager might start to use DT when her network is still small and she has a good informal understanding of what goes on therein simply by participating in it; she could then build a repertoire of recipes. We define recipes as formalisms that map from changes in the mathematical characteristics of the network to social phenomena in the community represented by that network. Recipes of this kind enhance the community manager’s diagnostic abilities, and take the form:

Network metric A is a signature of social phenomenon B.

As she tries out different management techniques to yield her desired results, she would then proceed to build more recipes, this time mapping from management techniques to their outcomes – the latter being also be measured in terms of changes in the metrics of the network representing the community. Recipes of this kind enhance the community manager’s policy making, and take the form:

To get to social outcome C, try doing D. Success or failure would show up in network metric E.

She then might be able to lean on repertoires of recipes of both kinds to run the network as it gets larger, because the software does not lose its ability to monitor those changes. These repertoires of correspondences are going to be built by integrating inputs from two different sources. The first one is theoretical: the systemic theory of emergence in the social world that some of my colleagues are engaged in developing. The second one is practical: the firsthand experience of community managers, myself included. Once built, the two repertoires would make up DT’s knowledge base, its computational intelligence core.

What follows is an account of a concrete case in which network science helped formulate a policy goal, the completion of which could then be monitored through, again, network analysis. It is only a small example, but we believe directed emergence is at work in it. And if emergence can really be directed then yes, in principle public policies can happen in the mesolevel and become closer to Wikipedia.

Context

In March 2009 I was the director of an online community called Kublai, a project of the Italian Ministry of Economic Development. People use Kublai to develop business plans for creative industries projects or companies. At the time it was about 10 months old; we had about 600 registered members working on 80 projects. I directed a small team that did its best to encourage people to try and think out new things, and to help each other to do so. Most creatives find it hard to achieve critical distance from their pet ideas, and an external, disenchanted eye might help them become aware of weaknesses or untapped sources of strength. Even simple questions like “why do we need your project?” or “how do I know this is better than the competition?” can help.

These conversations happen online, in the context of a small, dedicated social network that used the Ning software-as-service platform. We customized Ning’s translation to change the names of the “groups” functionality into “projects”: the object in the database was still the same, but rhetorically we were encouraging people to come together to collaborate to a project’s business plan. Ning groups lent themselves well to the task, because each sports (1) a project wall for comments; (2) a forum for threaded discussion; (3) group-wide broadcast message functionalities at the disposal of the group creator. In March 2009 the largets projects/groups in Kublai had about 60/70 members.

Ruggero Rossi, like me, is passionate about self-organizing behavior in the social world. When he proposed to do his thesis by running a network analysis of the Kublai social graph, I supported him in every way I could. The thesis was supervised by David Lane, a complexity economist I admire, which was an added bonus.

March 2009: diagnosis

The first problem was to specify our network. We decided nodes would correspond to people: each user is a node. The links could be several things, since there are several types of relationships between members of a Ning social network: relationships might be created by adding someone as a friend, leaving a comment on her wall, sending her a message, joining the same group/project etcetera. We decided to focus on collaboration in writing business plans, which is Kublai’s core business; we also decided that, in the context of Kublai, only writing in the context of a group/project counts as collaboration.

So we defined the link as follows: Alice is connected to Bob if they both have posted a comment on the same project. This is a somewhat bold assumption, because positing some kind of communication between the two implies that everybody who ever posted anything within a project reads absolutely everything that is posted in that project. I thought that was reasonable in the context of Kublai, also given the short time frame in which the comments had been piling up. This implies a bidirectional relationship: in network parlance, the graph is called undirected, and its links are called edges. The edges are weighted: the edge connecting Alice to Bob has an intensity, or weight, equal to the number of comments posted by Alice on the project times the number of comments posted by Bob on the same project. If they collaborate on more than one project, we simply add the weight of the link created across all projects on which they are both posting comments.

Eventually Ruggero crunched the data and showed me his results, that boil down to this:

  • all active (posting) members of Kublai were connected in a giant component: there was no “island”.
  • a kernel of people who were highly connected to each other acted as Kublai’s hub, connecting each participant to everybody else in the network. All of the paid team members were part of this kernel: no surprise here. More surprisingly, many non-team members were also part of the kernel. So many, in fact, that if you removed all of the team members from the graph it would still not break down; everybody would still be connected to everybody else.

Summer-fall 2009: policy

This was an epiphany for me. I discussed these results with the team, and our interpretation was this: a core of dedicated community members was forming that was buying into Kublai’s peering ethics. They took time off developing their own projects to help others with theirs. This was a very good thing, in two ways.

  1. it implied efficiency. With more people participating in more than one project, Kublai could do a better job of transporting information from one project to another, and that is the whole point of the exercise. Alice is stuck with her project on some issue, and it turns out that Charlie, somewhere else in the network, has run into the same problem before. Alice does not know this, but she does collaborate with Bob, and Bob is a collaborator on Charlie’s project. So Bob can point Alice to what Charlie already did: Alice needs not walk Charlie’s learning curve all over again.
  2. it implied resilience. If enough people do this, we thought, maybe the Ministry can turn Kublai over to the community, which will keep running it at little or no cost to the taxpayer. This would have created a public good out of thin air. Not bad!

So, we decided to encourage this self-organizing feature. How to do it? A way to go about it was to encourage especially people who were developing projects (progettisti) to interact more. What could bring them together? Purely social stuff like football or celebrities discussion groups were not even considered: they would mar the informal, yet hardworking atmosphere of Kublai. According to my readings on the early days of online communities, something that any community loves to do is discussing itself. So, we thought we would turn over some of the control over the rules of Kublai to the community, and we would put a significant effort in it. We created a special group in Kublai, the only one that was not a project at that point, and called it “Club dei Progettisti”. Joining was unrestricted; also, we actively invited everybody in the kernel and everybody who had started a project up to that point. We did things like coordinate to welcome newcomers and discuss the renovation of the Second Life island we used for synchronous meetings. The atmosphere was that of the inner circle, the “tribe elders” of our community. This went on from about May to the end of 2009.

December 2009: policy assessment

Was the policy working? It was hard to say. The Club dei Progettisti grew to be by far the largest and most active in Kublai, but that does not mean that people interacting more in that context would then go on to collaborate on business plans in the context of individual projects, that was our real goal. It did feel like we had a vibrant community going – but not all the time. And then vibrant with respect to what? And how does vibrancy translate into effectiveness? We spent a lot of time online, and sailed by instinct. Instinct checked green, but let’s face it – after one thousand users and 150 projects it was hard not to lose the overview.

With another round of network analysis I would have been able to have a stab at policy assessment. In network terms, I wanted the kernel to be bigger: more people not from the Kublai team, collaborating across more projects, would facilitate the information flow across projects and improve efficiency. But Ruggero had finished his thesis, and the administrative structure running Kublai was at this point so rigid that contracting him was next to impossible.

Only recently, two years later, did I get the chance to crunch an export of the Kublai database. We at the Dragon Trainer group extracted a snapshot of Kublai at March 23rd 2009 (the same day Ruggero scraped it for his thesis) and one at December 31st 2009.

In these two images the nodes, representing members of the Kublai community, have been color coded according to a measure called betweenness centrality, indicating how often the node is in the shortest paths connecting other nodes (it is often interpreted as an indicator of brokerage efficacy). Yellow nodes are the least central and blue nodes the most central, with orange ones in an intermediate position; nodes representing the Kublai team employees (typically very central) have been dropped from the graph altogether. In March 2009, a handful of community members, less than ten, collaborated on several projects on a regular basis – and, as a result, did most of the brokerage of information across the network. In December, however, their number had about doubled, despite the fact that attaining orange or blue “status” required a lot more work (the most central node in the March network has betweenness centrality 1791, the one in the December network 7740). At the end of the year, Kublai’s kernel was both larger and more connected than it had been in March. This growth is an emergent social dynamics: there is no top-down control in these graphs, anybody I could tell “go form a link with X” has been dropped from the dataset. But this emergence is somehow directed: we wanted to get to a social arrangement whose graph looks like this.

You can see how powerful this thing is. We can already say something just by looking at the graph; we have not even started to crunch the numbers, let alone do more sophisticated things. We could (and we will) compute and compare measures of network centralization; respecify the network in many different ways, allowing for link impermanence (if Alice and Bob are linked but don’t keep interacting, after a while the edge fades out), bipartite networks (what about a people-project graph?) directed graphs (links representing monodirectional help rather than bidirectional collaboration: if Alice posts on Bob’s project, she is helping him, but Bob might not reciprocate); and play with the data in as many ways as we can think of.

We keep working on this, and we will continue to share our results and our thoughts. If you want to be a part of this effort, you can, and are absolutely welcome. Everything we do (the data, the code, the papers, even the mailing list) is open source and reusable. Download what takes your fancy and let us know what you are doing. We are looking forward to learning from you.

  • Download the raw data (database dump, anonymized).
  • Download and improvethe code to export the data into file formats supported by the main network analysis software.
  • Download the exported data if you would like to jump right into the network analysis. .net files (Pajek projects) are importable also in Gephi and Tulip.
  • join our mailing list if you want to be involved in our discussion. Everyone welcome, no technical background is required. We are online community managers mathematicians, coders, public policy practictioners, committed to being interdisciplinary and therefore to going out of our way to make anyone feel welcome.