Tag Archives: collaborative networks

Don't Ban Facebook – Op-ed in today's G&M

You can download the op-ed here.

The Globe and Mail published an op-ed I wrote today on why the government shouldn’t ban face book, but hire it.

The point is that Web 2.0 technologies, properly used, can improve communication and coordination across large organizations and communities. If the government must ban Facebook then it should also hire it to provide a similar service across its various ministries. If not it risks sending a strong message that it wants its employees to stay in your little box.

One thing I didn’t get into in the op-ed is the message this action sends to prospective (younger) employees. Such a ban is a great example of how the government sees its role as manager. Essential the public service is telling its employees “we don’t trust that you will do your job and will waste your (and our) time doing (what we think are) frivolous things. Who wants to work in an environment where there own boss doesn’t trust them? Does that sound like a learning environment? Does it sound like a fun environment?

Probably not.


Facebook Revisited

MAY 17, 2007 AT 12:38 AM EDT

Today’s federal and provincial governments talk a good game about public-service renewal, reducing hierarchy, and improving inter-ministry co-operation. But actions speak louder than words, and our bureaucracies’ instincts for secrecy and control still dominate their culture and frame their understanding of technology.

Last week, these instincts revealed themselves again when several public-service bureaucracies — including Parliament Hill and the Ontario Public Service — banned access to Facebook.

To public-service executives, Facebook may appear to be little more than a silly distraction. But it needn’t be. Indeed, it could be the very opposite. These technology platforms increasingly serve as a common space, even a community, a place where public servants could connect, exchange ideas and update one another on their work. Currently, the public service has a different way of achieving those goals: It’s called meetings, or worse, e-mail. Sadly, as anyone who works in a large organizations knows, those two activities can quickly consume a day, pulling one away from actual work. Facebook may “waste time” but it pales in comparison to the time spent in redundant meetings and answering a never-ending stream of e-mails.

An inspired public service shouldn’t ban Facebook, it should hire it.

A government-run Facebook, one that allowed public servants to list their interests, current area of work, past experiences, contact information and current status, would be indispensable. It would allow public servants across ministries to search out and engage counterparts with specialized knowledge, relevant interests or similar responsibilities. Moreover, it would allow public servants to set up networks, where people from different departments, but working on a similar issue, could keep one another abreast of their work.

In contrast, today’s public servants often find themselves unaware of, and unable to connect with, colleagues in other ministries or other levels of government who work on similar issues. This is not because their masters don’t want them to connect (although this is sometimes the case) but because they lack the technology to identify one another. As a result, public servants drafting policy on interconnected issues — such as the Environment Canada employee working on riverbed erosion and the Fisheries and Oceans employee working on spawning salmon — may not even know the other exists.

One goal of public-sector renewal is to enable better co-operation. Ian Green, the Public Policy Forum chair of Public Service
Governance noted in an on-line Globe and Mail commentary (Ensuring Our Public Service Is A Force For Good In The Lives Of Canadians — May 8) that governments face “increasingly complex and cross-cutting issues … such as environmental and health policy.” If improving co-ordination and the flow of information within and across government ministries is a central challenge, then Facebook isn’t a distraction, it’s an opportunity.

Better still, implementing such a project would be cheap and simple. After all, the computer code that runs Facebook has already been written. More importantly, it works, and, as the government is all too aware, government employees like using it. Why not ask Facebook to create a government version? No expensive scaling or customization would be required. More importantly, by government-IT standards, it would be inexpensive.

It would certainly be an improvement over current government online directories. Anyone familiar with the federal government’s Electronic Directory Services (GEDS) knows it cannot conduct searches based on interests, knowledge or experience. Indeed, searches are only permissible by name, title, telephone and department. Ironically, if you knew any of that information, you probably wouldn’t need the search engine to begin with.

Retired public servants still talk of a time when ministries were smaller, located within walking distance of one another, and where everyone knew everyone else. In their day — 60 years ago — inter-ministerial problems were solved over lunch and coffee in a shared cafeteria or local restaurant. Properly embraced, technologies like Facebook offer an opportunity to recapture the strengths of this era.

By facilitating communication, collaboration and a sense of community, the public services of Canada may discover what their
employees already know: Tools like Facebook are the new cafeterias, where challenges are resolved, colleagues are kept up to date, and inter-ministerial co-operation takes place. Sure, ban Facebook if you must. But also hire it. The job of the public services will be easier and Canadians interests will be more effectively served.

David Eaves is a frequent speaker and consultant on public policy and negotiation. He recently spoke at the Association of Professional Executives conference on Public Service Renewal.

Messina and Firefox

So I know I’m late to the party but wanted to contribute some thoughts to the Messina debate on Mozilla.

What I find most interesting are not the specifics of the discussion, but the principles beings discussed and the manner by which they are being discussed.

Break Messina piece down and he is essentially making two assertions:

1. “I don’t understand Mozilla’s strategy” and (unsurprisingly!) here are my ideas
2. “Let the community rule”

The response, has been fairly quiet. Some were clearly frustrated. Others saw it as an opportunity to raise their own pet issues. What I haven’t seen (on Planet Mozilla) is a post that really engages Chris’ ideas and says “I don’t agree with Chris on ‘a’ or ‘b’, but he’s right about ‘c.’ ” To be fair, it’s hard to react well to criticism – especially from someone you count on as an ally. When you spend your day fighting billion dollar beasts you don’t exactly want to spend time and energy defending your rear.

However, the silence risks increasing the gap between Mozilla and those who agree with Chris (which judging from his blog may or may not be a fair number of people). I was struck that one commentator said: “I didn’t know somebody could talk like this about Firefox until now.” Such a comment should be a red flag. If the community has some sacred cows or self-censors itself, that’s a bad sign. For this, and other reasons, the thrust of Messina-like rant’s may have significant implications for the future of Mozilla.

The problem is that as the Mozilla community grows and the choices for where to concentrate resources become less and less ‘obvious,’ the community members will increasingly want be part of the strategic decision-making process. When the objective is clear – build a better open browser – its easy to allocate my scarce economic resources towards the project because the aim is obvious (so I either buy-in or I don’t). But as success takes on more nebulous meaning, I need to understand why I should allocate my time and energy. Indeed, I’m more likely to do so if a) I understand the goal and b) I know I can help contribute to deciding what the goal should be.

In this regard Mozilla need to constantly re-examine how it manages strategy and engages with its community (which I know it does!). Personally, I agree with Messina that Mozilla is not a browser company. Indeed, in a previous (not entirely well formed) post, I argue that Mozilla’s isn’t even a software company. Mozilla’s is a community management organization. Consequently its core competency is not coding, but community management. The concern (I think) I share with Messina (if I read between the lines of his rant) is that as Mozilla grows and becomes more successful the decisions it must make also become increasingly complex and involve higher stakes. The fear is that Mozilla will react by adopting more corporate decision-making processes because a) its familiar – everybody knows how this process works and b) its easy – one can consult, but ultimately decisions reside with a few people who trust (or at least employ) one another.

However, if Mozilla is a community management organization then the opposite is true. Mozilla needs a way to treat its strategy like its code, open to editing and contribution. I know it already strives to do this. But what does open-strategy vs. 2.0 look like? What does community management 2.0 look like? Can Mozilla make its community integral to its strategy development? I believe that at its core, Mozilla’s success will depend on its capacity to facilitate these discussions (I may even use the dreaded term… dialogues). This may feel time consuming and onerous, but it pales in comparison to the cost of losing community members (or not attracting them in the first place).

If Mozilla can crack this problem then rants like Messina’s won’t be a threat, they’ll be an opportunity. Or at least he’ll a place where he can channel them.

New Book Review: Robert Axelrod's "The Evolution of Cooperation"

About 6 weeks ago during a trip to Ottawa David Brock urged me (for a second time!) to pick up a copy of Robert Axelrod’s “The Evolution of Cooperation.” As the title suggests it is a book about the conditions under which cooperation might emerge. While I’m willing to concede that this book may not be for everyone’s cup of tea, it is still a fine cup I belive many would enjoy. Indeed, given how frustrating and empty game theory felt while I was in grad school I wish I’d had this book at my desk.

I’ve written a review of the book you can find here. In short, I’m glad I moved it to the top of the batting order – it was completely worth it. Thanks D-Rock.

Wiki's and Open Source: Collaborative or Cooperative?

This is a follow up to my previous post Community Management as Open Source’s Core Competency which has become the most viewed post on this site. I’ve been meaning to follow it up for some time, sorry for the delay.

Online communities, and in particular their collaborative nature, have been generating a lot of buzz lately. But are online communities collaborative?


The more I reflect on it, the more I suspect the answer is a qualified no. While at present there is a tremendous amount of online cooperation, this is not the same as collaboration. This is not to say the cooperative capacity of online communities has not been a boon, but simply an effort to recognize and concern ourselves, with its limits.

I suspect the world’s most interesting and challenging problems cannot be solved in isolation from, or even in cooperation with ,others. Elegant and effective solutions (those most useful to users or consumers) likely benefit from, and probably require, an interplay of ideas and perspectives. Consequently, for those involved in online collaborative projects – such as Wiki’s or open source – understanding the distinction between cooperation and collaboration is critical. If online communities cannot foster collaboration then they will fall short of the hype and ambitions they have set for themselves. Conversely, communities that figure out how to enable their members to collaborate (as opposed to merely cooperate) may end up having a decisive advantage.

Defining the problem

Why distinguish between collaboration and cooperation? Because the subtle difference between these words describes a lot about where we are versus where we need to be vis-à-vis online communities. Admittedly, Websters’ defines the two words very similarly. However, I would argue that collaboration, unlike cooperation, requires the parties involved in a project jointly solve problems.

Truly collaborative processes enable differing and possibly conflicting views to merge and create something new and previously unimagined (think of Hegel’s thesis and anti-thesis coming together in a synthesis). Many online projects – offered up as collaborative – do not meet this standard. For example, some on-line projects, particularly open-source software projects, break problems down into smaller pieces which are tackled by individuals. Sub-dividing a problem and allowing a network of volunteers to opt-in and provide solutions it is a highly efficient. However, those involved in the project many never need to talk, exchange ideas or even interact. Indeed tricky problems may often end up relying on a single clever hacker, operating alone, to solve a problem. While this can be part of a cooperative effort – people with a common goal contributing labour to achieve it – I’m not sure it is collaborative. Equally, many wiki’s simply replace old information with new information, or rely on an arbiter to settle differences. This is at best cooperative, at worst competitive, but again probably not collaborative. (Side note: Please understand, I do not mean to belittle the incredible success of online communities. Indeed the achievements of open source projects and wiki’s are remarkable. However, my concern is that cooperative approaches may only be able to solve a specific, and limited, problem type. Cultivating collaborative communities may be necessary to solve larger, more complex and interesting problems.)

Why Open-Source systems tend to be cooperative and not collaborative

My guess is that unlike cooperation, online collaboration is rare. Why? Probably because online collaboration it is hard. Few people should find this surprising since face to face collaboration can itself be pretty hard. (I make a living off helping people do it better…) People approach problems with, among other things, different assumptions, stated and unstated goals, and data sets. Effective collaboration requires people to share these differences and resolve them. Anyone who has ever been to a business meeting (even among colleagues from the same company) knows that the process for achieving this is often neither self-evident nor easy. Numerous issues can sabotage collaborative efforts – including those that have nothing to do with the substance of the problem. For example, our ideas often end up being linked to our identity. Even just modifying our idea, or worse, adopting someone else wholesale, can feel like admitting someone else is smarter or better – something that may be difficult to do, especially in a voluntary community where your value and credibility is linked to your capacity to solve problems or provide ideas.

From what I can tell online projects only exasperate the challenges of face to face collaboration. Without personal relationships, trust, body language or even intonation, it is easy for communication to break down. Consequently, it is difficult for people to resolve differences, exchange ideas, or brainstorm freely. In short, it is difficult to collaborate.

Successful online projects seem to manage this by being either a) small – relying on a tight-knit community whose strong relationships enable them to collaborate; or b) large – achieving success by doing the opposite of collaboration: separating problems into discrete pieces that individuals can handle alone.

In the large group scenario, interaction may often be limited to peer review processes where criticism – not constructive problem-solving – is the dominant form of dialogue. Consequently, interactions are limited, and usually arbitrated by some central authority. This has the benefit of capping the level of conflict but the discourse among members may remain highly combative.

Such tension can be healthy: collaboration is inherently conflictual. Most ideas spring from parties sharing differing, conflicting perspectives and jointly working to develop a solution that meets both their interests. Eliminate all conflict and you eliminate the opportunity for new ideas. However, too much conflict and the opportunities for collaboration diminish. Large communities – particularly those involved in projects that have some cache – are insulated from the inevitable burnout and frustration that causes members who skin isn’t “thick enough” to drop out. Other community members jump in and fill their spot. It isn’t pretty, but it is sustainable, in a manner of words.

Some recommendations for community managers

Consequently, the goal of online communities should be to determine how to manage, not eliminate, conflict.
So far, to be collaborative – to enable people to work together and jointly solve problems – online communities appear to have two options: (please send others!)

1) Build relationships between their users – stronger relationships can (although not always) enable people to overcome breakdowns in communication. However, building relationships generally takes time and is to scale. To date, the voting system on the Omidyar network – which rewards those perceived as having ‘good’ behaviours and ideas – is the most effective I have seen to date. Although the behaviours are not defined, one can presume that those with higher ratings are likely to be more trustworthy and easier to collaborate with than those with lower ratings. However, this system does not help users develop collaborative behaviours or skills, it simply rewards those who are already perceived as being more collaborative then the mean. Consequently, users with poor collaborative skills, but possessing expertise or substantive knowledge essential to the success of a project, may struggle to contribute. Even more troubling, the vast majority of your users could be inept at collaborating, and this system will do nothing to raise the bar or improve the community. It will only highlight and identify who is least inept.

2) Develop online communities with built in methodologies and processes that encourage or even compel users to jointly solve problems. Here one can imagine an online community that forces users to work through Chris Argyrisladder of inference. While likely more difficult to design, such a system could compel users to be collaborative (possibly even regardless of their intentions).

A lot of the theory around collaborative decision-making is explored in greater detail in negotiation theory. This post is part of my continuing effort to flesh out how (and even if) negotiation theory can be applied to online collaborative networks… I promise more thoughts in the future – in the meantime please send or post yours!

One closing note – if there is a compelling link between negotiation theory and collaborative online networks then it would suggest a new interesting area for inter-disciplinary studies. For example, Stanford has the Centre for Internet and Society and the Gould Negotiation and Mediation Program. It would be interesting to know if these two centres believe they share this area of mutual interest. Maybe I’ll work up the courage to email Lawrence Lessig and ask…

Community Management as Open Source's Core Competency

Reaction to this post has been overwhelming – I made it the basis of a presentation at the 2007 Free Software and  Open Source Symposium at Seneca college. You can watch it here as a slidecast.

A good friend of mine, Mike B. and I have been exchanging thoughts on open source projects. Mike’s experience is grounded in the ‘traditional’ world of open source – he works on the web browser Firefox (which if you don’t use, you should). I freely admit my own open source credentials are more suspect – I draw my lessons from my experience engaging in a form of open source public policy through Canada25. Beyond, that, what I know is based on what others are kind enough to share with me, and what I am able to learn through articles, books and podcasts.

For those not interested in the whole spiel below the short version is this:

Companies or foundations that run open source project are not software firms, they are community management firms whose communities happen to make software. Consequently to survive and thrive these projects need to invest less in enhancing governance structures or employees who/that will improve their capacity to code. Instead, we should consider skills and structures that emphasize facilitation, mediation, and conflict management – tools, skills and structures that will enable the community to better collaborate.

More detailed thoughts I’m fleshing out an idea flow that goes something like this:

  1. Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package. (I’ll talk more about Canada25 as open source in the future)
  1. The core competencies of a community management organization are different from those of a software firm. Specifically, core competencies reside in their capacity to support and enable the community to collaborate and contribute to the project. Furthermore, the community’s contributions will not likely be limited to a single function (such as coding new features) but will need to include all aspects of the projects evolution including discussions about the direction of the software or marketplace and its impact on strategy. As people volunteer more time and become more invested my hypothesis is that they will want (at least) input (not to be confused with decision-making authority) in more strategic decisions.
  1. Consequently, the structures and skill sets of those working on an open source initiative need evolve over time:
    1. In the beginning, because of their size, open source projects can pretend to be software firms – this is because the community is sufficiently small that everyone knows one another so that levels of trust are high and the need for formal community structures are low. In this earlier phase:

i. Respect and influence is based on raw brain power/problem solving capabilities – rather than seek permission those who code solutions to problems earn respect, and others listen and/or follow their lead

ii. Common values and operating assumptions in the community are not, and don’t need to be encoded – it is small enough that those who ‘get it’ opt in, and those who don’t opt out.

    1. Success changes everything. As open source projects becomes increasingly successful (and, possibly, more political) the context around the community changes:

i. Success means more people join the community. This is not only true of the number of people, but also of the type of people (e.g. skill set, cultural background, etc…). This increase places stress on the community infrastructure. Specifically, an increase in participants can:

1. reduce levels of trust and the sense of community, raising transactions costs to effective collaboration

2. erode the assumed common community value as new entrants join the project for different reasons

3. decision-making becomes increasingly complex as the consultative nature of open source projects does not obviously scale. This may cause individuals/groups to feel disenfranchised and/or frustrated (and never underestimate the damage to productivity frustrated people can cause – thank you for this Shaver)

ii. As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.

    1. Community Management as Cope Competency. My interest in all this is how we can take the ideas, methodologies and tools that come out of the negotiation/conflict management/collaborative decision-making arena and port them over to the open source space.

i. Training up in facilitation skills. Getting the core group of project employees trained up on how to collaboratively solve problems. Some basics might include:

1. using interests and not positions when resolving disagreements

2. using Chris Argyris’ theories about how (particularly smart technical people) fight over conclusions, by failing to share the data and analysis behind their thinking – often referred to as the ladder of inference.

ii. Rethinking decision-making processes – chiefly by setting expectations of how decisions will be made, what criteria will be applied when making them. It is likely essential to give community members a common set of criteria to use to evaluate decisions, that way they we can reframe discussion from what they like more to what adheres to the communities standards the closest. This is true for technical decisions, but also strategic or governance questions. The key around decision-making is not how democratic it is, but how well we set expectations for community members and then adhere to those expectations.

iii. Open source communities may fear accepting that even greater collaboration and openness is their core competency because it raises the underlying question no one wants to ask: Is the open source model scalable , and competitive?

The false answer is no: To believe that becoming more competitive and/or moving quickly means we need to consult less.

The true answer is yes. We can’t be competitive by running away from our core-competency, if we do that the we end up playing by the rules of the established corporate players, rules that we can’t win using. Forget their playbook, we have to get back in the box. We have to become faster, more efficient and easier to use at what we do best: engaging and enabling everyone in the community (customers, volunteers, etc…) to collaborate.

  1. Leaders Matter: The good and bad news is for project leaders – for example, paid employees of the project – is that you are THE role model for the community. Every action you take validates or invalidates certain behaviour types. If a employee behaves in an unconstructive way it will be hard to tell others in the community that this behaviour is out of bounds.

I suspect that most open source projects:

    1. Know this
    2. It causes nervousness
    3. Because participants are smart, we rationalize ourselves out of this problem

But… we can’t. And we shouldn’t. This is our single most important chip. It is what allows us to shape the behaviour and culture of the community. Let’s embrace it and use it.

Sorry for the long post – generated out of some thinking with friends at Canada25, Canada2020 and Firefox. Hope you have lots of thoughts, reactions and comments, definitely want to refine my thinking and there is likely a lot of refining to do.

UPDATE: If you found this piece interesting I’ve written a follow up on to this piece, entitled Wiki’s and Open-Source: Collaborative or Cooperative?