Author Archives: Bruce Caron

What is an online community architect?

Architecture

I was recently asked why I call myself an online community “architect.” A fair question. My use of the label “architect” is meant to highlight how intentional communities, such as virtual organizations, can design, assemble, and use cultural practices to become more effective at achieving their goals and their vision.

The “unintentional” communities that we find ourselves belonging to (or resisting) in our society, from our neighborhoods and schools to our language groups and nations, use cultural practices that are grounded in longer histories and broader social structures. These represent the culture we are submerged in from birth; often they are the practices that represent our sense of identity and position in society.

These practices (and associated beliefs) are what anthropologists call “culture.” They remind us that much of this is learned and then used unconsciously, as habits and behaviors that come naturally to the enculturated members of the society. Intentional communities are made up of members that carry their own cultural habits from their society. On top of these habits, an intentional community agrees to add practices that are mutually agreed upon and available for discussion and revision. 

Some intentional communities are created as counter-cultural groups, where their practices are designed specifically to conflict with those of the larger society. But many more intentional communities, from workplaces to voluntary societies and virtual organizations simply want to define their core values and to design governance practices to support these.

Often, corporations and networked communities fail to recognize that they need to develop an intentional culture to support their collaborations. They rely on the unconscious cultural habits of their members and on imposed management schemes to compel participation. Management practices can seem more effective and cheaper than the expense of building cultural practices and governance. However, in situations where corporations need to pivot quickly, or where virtual organizations need to rely on volunteers, there is no substitute for shared values supported by governance practices.

The literature on the costs and benefits of a robust corporate culture is quite large. But how can organizations gain expertise in developing intentional cultural practices? Just as a building architect is used to create an efficient and effective envelope of space, a community architect can help an organization create an envelope of practice. Every effective corporate culture is based on shared intention and honest design. It is the role of the community architect to become familiar with those design patterns that can help a new virtual organization build a robust cultural fabric to support its vision and its goals.

Photo Credit: “On The Saturday Before That” by Thomas Hawk on flickr

On the road to governance? Get a handle on your logic and keep an eye on practice.

Barn Raising

Building practices for an emerging governance gives your virtual organization community tools to explore how they want to govern their own participation. Too often, governance planners start by thinking of structures: committees, boards, and assemblies. The structures will emerge more organically if planners start with practices and their logic.

Twenty some years ago, anthropologist/sociologist Pierre Bourdieu wrote Le Sens Pratique (Logic of Practice). He noted that cultural activities were not simply reasoned, but also became embedded in their practice. Their performance included tacit knowledge that was not available to the performer, having been learned directly through the body. The cultural norms and skills are carried by their members without the need for reflection or conversation. This is precisely why “culture” is often considered as difficult to change.

How does this theory inform the work of building an intentional community governance? Mainly, I will propose that governance needs to “make sense,” not just as a reason-able activity, but as a practice that feels right. Because this community is intentional, its practices are available for reflection and conversation, and change. This is the real difference between culture out in the world and the culture of a company or a virtual organization. Any organization that loses the ability to direct its internal culture is trapped in a single loop of progress and error and will never learn its way out of this. Your culture belongs to you, and not you to it.

How can practices feel right? How do you know if a practice feels wrong? The main way is to create a small list of provisional core values. These become the touchstones that members use to judge how right or wrong a proposed practice feels. If “maximal transparency” is a core value, then a practice that hides disagreement is going to feel wrong. If “diversity of approach” is a core value, a practice that opens up to a great variety of inputs will feel right.

Don’t feel like these provisional core values will need to be written in stone. Make one of them “community owns its values” and encourage the members to embrace and celebrate them, changing them when they want to. 

Remember that governance is not simply about decision making. There are a lot of expressive opportunities that it can enable that will help your members to embody the organization’s culture through their interactions. Governance needs to encourage leadership and resolve conflicts. It should promote best practices and reward service.

Are you ready to gather your fledgling community together and start planning a governance approach? Get them to outline a handful of key values first. Then challenge them to find practices that uplift and promote these. Then you can add in use cases and scenarios for them to build structures that use these practices. Before you know it, your community will have a first draft of their bare-bones governance scheme.

Photo Credit: Elgin County Archives, Wallacetown Women’s Institute fonds on Flickr

Achieving a consensus culture for your virtual organization

4784376842_02d97e9e3c_b

Decision making for your virtual organization needs to optimize the decision process and impact. If your organization relies on a wider community of unpaid volunteers, then you will need to find ways to involve this community in your decision process. Where decisions need to be made on a day-to-day basis, you will want to have paid staff with the authority to make these, and to also be accountable to the executive body of your virtual organization. Involving the wider community usually involves two complementary modes of decision making: election and consensus.  For large organizations these two modes are sometimes used together in a multi-step process of delegation and consensus.

Why is consensus important? What type of consensus is the best? How do I create a culture of consensus? Previously, I outlined the arenas where staff and volunteer decision making occur, here I want to focus on the role of consensus. Consensus is primary important as a decision process where this can positively impact the quality of the decision and/or the efficacy of its outcome. The road a consensus decision opens up the discussion to include every member’s perspective and intuition. This process brings in the full range of the group’s knowledge to bear on the issue. During this discussion, aspects of the problem may be illuminated that were previously obscure. The result can be a decision that is stronger or more astute. Even when the discussion leads to a compromise, that compromise can be based on real-world limitations, and so, might avoid trouble after implementation. Where the implementation of the decision will require the active participation of the larger community (e.g., a decision to support a certain data/metadata format) consensus carries an invaluable mark of community involvement and ownership for the decision.

Just enough of a consensus

Absolute consensus may be unreasonable, given the range and interests of various stakeholder groups in the membership. If this is the case, and it would probably become evident during the start-up of the community, then some sort of “working consensus” (or rough consensus) might be a reasonable alternative. This would be a type of super-majority that would allow for a few opposing views to be not included in the final decision, but to be included in a durable report of the decision process as a minority perspective. The logic is to be able to move ahead, while maintaining the conflict that emerged in the decision process on the surface of the final decision. This type of working consensus would need to have at least a 81% majority: in a group of 20, no more than three people can disagree with the final decision. The goal is always to achieve a total consensus, with the working consensus as a fall-back.

Consensus culture

Consensus decision making requires a consensus-aware culture for interaction within the group. There are some established cultural practice guidelines for consensus organizations. One of my favorites is the Seeds for Change organization in the UK.  The consensus decision process challenges each member to listen fully to the arguments, to state their own position clearly, and to be aware that they have more than just an option to support or block a decision. A member can also abstain, withholding their outright support and refusing to block a decision. It is important in the discussions leading to a decision that the facilitator (often a staff member) is also a process mentor, reminding members of the need for open minds and hearts in the process, and a clear-headed, well-founded motive when a member decides to block a decision.

Consensus decision making does not directly scale beyond a couple-dozen members. In a larger community, each stakeholder subgroup (this requires a fractal subsetting to sub-groups of no more than a couple-dozen members) is granted a representative to an executive council where the consensus discussion is held. At the point of a vote, the representative returns to their subgroup and outlines the issues and the proposed decision. Once a consensus is acquired within the subgroup, this is carried back to the executive group.

The process of arriving at a consensus is at the same time a process of listening to the best ideas and the strongest fears of the community’s stakeholders, and a means to forge a better solution as a final decision. A decision based on consensus carries the trust and the will of the entire community.

Photo Credit: CC licensed on Flickr by Tantek Çelik

Hitting the target makes all the difference for the software life cycle

Sky diver jumping from plane

At a recent, NSF-funded workshop that was looking at how a new institute might help scientists become better stewards of the software they create for their research, a day was devoted to discussing the entire software life cycle, and the differences between commercial software, open-source, community-led software, and academic science software. A long list to positives and negatives accumulated to describe the triumphs and the pitfalls of each of these arenas for software development. Most of the triumphs were in the commercial software column, and the great majority of pitfalls were common to science software development.

That evening, upon reflection, it occurred to me that commercial software was simply very good at determining a target (feature and/or customer) and then hitting this target. It seemed like academic software developers, admittedly working on shoestring budgets only seemed to cobble together whatever feature their next experiment might require, with the result being software that was almost secreted over time (I almost said excreted…) instead of crafted for the long-haul.

It struck me—reflecting back on my single skydiving adventure, in the days where you still took your first jump solo on a static line—that my focus at that time had been narrowed down to the single fear of getting out of the plane. I did not want to freeze in the door. Consequently, I seemed to have not paid as close attention as I might to what happens next. As a result I ended up landing in a field away from the airport (upside: I did not land on the Interstate). I hit ground, no problem, and without breaking anything, but I missed the target completely.

Again, commercial software developers are firmly focused on their targets, and they make software that helps others find the same target too. To do this they know how to jump and when to pivot in order to land right on that X. When Instagram created its software it focused on the simplicity of sharing photos.

Open-source, community-led software tends to lose that target focus, in part because the developer community usually has several simultaneous targets in mind. What they are good at is designing the parachute and the gadgets that help to figure altitude and wind. They make jumping safer and more fun, and their goal is to enable more people to do the same.

Getting back to science software developers, these are often individuals or small teams working as a part of a larger project. They wrangle the datasets and finagle some visualizations. They add a button or a drop-down list and call it a GUI. They tell their team how to use it and what not to do so it won’t crash. Then they go ahead and do their experiments and write it up. In software life cycle terms, all they know how to do it jump out of the plane. Forget the target, never mind the parachute…just jump.

The goal of the NSF workshop was to help design an institute that would support better software development practices across the environmental and earth sciences. To do that, science software developers need to focus all the way to common targets of resourceful, reliable, and reusable software. Do you have some ideas? Feel free to join the ongoing conversation at the ISEES Google+ Community.

Photo Credit: CC licensed on Flickr by US Air Force

Double-loop Organizations build policies from the bottom up: here are 3 ways to make policies that work

bottom up

Your virtual organization will work harder and better when everyone has a say about policies, and not just about procedures. Policy setting happens best in the second loop of a double-loop governed organization. That way the policy can respond directly to the vision of the organization.

A friend, a sysadmin at a major research university, was on his way to DEF CON when I ran into him on the street. He enjoyed hearing about the new security hacks he would be facing, and, as usual, he was not happy about the security measures on his campus. After describing how schools, departments, and centers had managed to grab the right to host their own Internet content—with predictably inconsistent results—he concluded that even his own department could use some new policies.

“Unfortunately, I can’t make policy,” he said, “I can only recommend procedures.” Faculty make policy, he explained. Staff implement this as well as they can. “I can talk all day, but some new PhD who thinks he knows enough will want to run his own server and connect into the department’s databases on my servers.” My friend has far more knowledge about computer security than he can implement, and he sees trouble ahead against which he cannot defend by making and enforcing better policies. When the system fails, when data are stolen or lost, he will be asked to explain and tasked to repair the damage. When the fan and the feces collide, he only hopes the precious work of graduate students is not collateral damage.

I could just recommend that you do not follow the model of a large academic department in a research university when you create your virtual organization. However, I doubt any of you (particularly those of you who have worked in a large academic department) had plans to do so. My point here is that every member of your organization can contribute to its policies and help defend it from failure.

Here are three ways you can make policies more effective for your organization:

1) When you create an executive panel or committee to make policy, be sure that this body is well connected with the larger membership.

2) Use a federated election process to preserve the voices of minority factions and edge groups, and empower contributions from across the membership.

3) Get additional feedback from the membership before you implement a new policy.

As a bonus, you will find that policies that are enacted with these practices are likely to be followed with greater rigor and care than those that simply appear in an email from the top.

Photo Credit: http://www.flickr.com/photos/bobcatnorth/21503266/ Some rights reserved by Bobcatnorth

Who’s afraid of the big bad MOOC…

DORIAN

In his new book, Who Owns the Future?, Jaron Lanier warns us about “Siren Servers” (sirens because they appear to offer amazing value for our lives and seduce us by not charging for this) sucking the worth from our futures while externalizing risk and hoarding the aggregated value of our contributions as their own assets. He is talking about Facebook and Amazon and Google and Apple, etc.. In our present economy, he argues, she who owns the server owns the future.  Many of his concerns apply rather starkly to the big MOOC consortia. As he notes, “(h)igher education could be Napsterized and vaporized in a matter of a few short years.” (Lanier, 84).

In some ways, the picture of higher education as an advanced content delivery system—where MOOCs and other internet services will disintermediate the jobs of faculty by providing content universally—offers a Dorian Gray solution to the problems of accelerating costs in higher education. In this scenario, if you could MOOC-ify as much of the classroom content as possible, you could eliminate a majority of faculty jobs while offering city college students Harvard-level classes.  Higher education would look and work better and brighter, and be cheaper and more available than it is now. However, the real picture of higher education (presumably withered and grotesque, hidden in a locked closet somewhere) would remind us that learning only starts with content delivery and that understanding content (however this is delivered) is really just the first step in higher education. Everything beyond this improves with and through classroom conversations. In a recent (May 20, 2013) New Yorker article on MOOCs, Nathan Heller ends his exploration of online courses with a paean to in-class conversation: “Their discussion left an energetic silence in the room, a feeling of wet paint being laid on canvas.” If MOOCs were the only option left for students in the future, higher education would be as impoverished (in terms of learning) as its graduates are today (in terms of loans).

I discuss this issue more on HASTAC: Flipping the MOOC: networked badges and massive online peer evaluation (MOPE)

Image from the Picture of Dorian Gray… [Image used under CC license on Flickr: photo by MassafelliPhotography.]

This is Sad

this_is_water_the_glossary

I just finished listening to the David Foster Wallace commencement speech, entitled This is Water, given at Kenyon College in 2005. I bought the audio version online.

I found and purchased this because someone (The Glossary <http://www.theglossary.com/#home&gt;) with enormous talent took an audio excerpt from this and made a video that captured visually the core sentiment of the talk.This video was posted on the internet, and blogged on Open Culture and on other sites–from BoingBoing to the Drudge Report: with millions of views in its first week.  A few days ago I learned that the video was removed from the internet by the David Foster Wallace Literary Estate. <http://vimeo.com/65576562> This is Stupid.

I really like David Foster Wallace’s work. His New York Times piece on Roger Federer’s tennis game <http://www.nytimes.com/2006/08/20/sports/playmagazine/20federer.html?pagewanted=all> is fabulously fun to read. Again, this summer, I am looking to find time to read Infinite Jest. So I might at some point have Googled up David Foster Wallace and might have discovered this speech. But I didn’t have to go looking for it. The minute I finished the video, I keyed in “This is Water” and found the publisher’s store. I can fully imagine others, many, many others, doing the same. (The publisher’s eCommerce store also, predictably, sucks.)

IMG_1128The reason this is stupid is not simply because the video was an excellent, effective advertisement for the work, but because the videographers did a great job capturing the tone and message of the work. For his estate and publisher to not know and to not applaud this accomplishment is worse than stupid.

The talk is marvelous in many ways. It builds an argument for a liberal education that has nothing to do with careers, unless you consider living to be a career. And it’s short. Powerful and well crafted. Well worth the $4.95. I’ll listen to it a lot before I consider I understand it well.

Wallace argues that education is about giving students the ability to choose to not buy into the default narratives that surround them as water surrounds a fish, but to live consciously a mundane life that is no longer anywhere near mundane. That his estate is trapped by the default narrative of copyright protection, blind to the amplification that this mash-up offered to the work, makes them as dim as any unschooled individual who can see no alternative to worshipping money, or beauty, or power. This is sad.

You can hear his talk here: This is Water.

Lead your virtual organization from behind, and they will drive you forward

The back of the bus

In March, 2013, David Reid at Palantir tweeted a quote: “Drupal’s community is a bus driven by the collective screams of its passengers.” At first glance, this seems really unfortunate. But on reflection, there are some great things going on here. First, it’s a bus, not a limo. Second, it’s filled with passengers. Third, they are passionately engaged in the destination of the bus. And fourth, the bus is responding to them. In short, the Drupal community is doing a lot of things right. 

This tweet took me back to a sunny afternoon in Berkeley at BADCamp. I was in front of Dwinelle Hall (where I first met my wife way back before there was an Internet) talking with Jacob Redding, who, at the time, was the Executive Director of the Drupal Association. I had recently finished Jono Bacon’s book, The Art of Community, taken from his experience helping to lead the community of developers who support the Ubuntu distribution of Linux. I mentioned to Jacob that, compared with Ubuntu, Drupal did not seem to be grounded in a common vision that was written down as a statement somewhere.

Jacob said that the Drupal community doesn’t have a single vision statement but the leaders of the project each may have their own. The Drupal project does have a mission statement (drupal.org/mission). In the project there is a lot of non-visible leadership. The Drupal Association is a good example of that. The Association does not guide or direct the project, but it certainly does watch what is happening with the project and provides the necessary support and services to either sustain momentum on areas in the project or encourage more involvement. “You can say the Drupal Association is leading from behind,” he said.

There are visionaries across the Drupal developer network, dozens of active people who are building new tools and pushing for better code. There are occasions in the year (at big Drupal Camps or at DrupalCon) and moments in the development cycle (sprints and telecons, in discussions on Drupal.org and elsewhere) where these leaders would come forward with their visions, and, at some point, a decision would happen. But the Drupal Association, which runs DrupalCon and hosts Drupal.org, is not out in front breaking trail for these decisions.

I called Jacob last week to get some clarity on this “leading from behind” technique. I might be involved in a grand experiment on governance that the NSF has fostered. It’s called EarthCube, and it proposes to corral all of the geosciences and environmental sciences under a new organization that can manage and promote the multi- and transdisciplinary sharing of data and knowledge. To bootstrap this effort, a seed of governance will be funded. In the first months, this governance kernel will need to get out in front and open up online opportunities for thousands of scientists to step into new leadership positions and get to work. In the subsequent months, the funded governance kernel will need to step back and lead from behind as the community finds its own governance footing. In the final phase, the funds for governance will be passed directly to the community, and kernel will become a front office. But this transition from leading from the front to leading from behind is truly experimental.

“Part of it is allowing chaos to reign,” Jacob told me. The point, I would propose, is to not spend a lot of effort (and time) establishing and then defending a set of top-down decisions. He continued,“a lot of things go wrong when you have a benevolent dictatorship that says ‘this is the way’.” When the community feels the need to make a decision, the lack of a top-down process enables people step up to offer solutions.

Behind the scenes, Jacob noted, the leaders of the Drupal project pay very close attention to all of the blogs and the threads on discussions and comments, and keep track of who was working well with others and who was influencing their peers. It would be vital to have these people in the room for important decisions. This internal eco-system is fostered through support for travel to Drupal events, and through email lists and other back-channel communication. Out in the front channels, the Drupal bus riders are shouting out their visions and their peeves.

The other eco-system to which the Drupal project and Organization pays close attention is the larger CMS world, where big corporations and government agencies are looking to make long-term investments. “This way we can counsel corporate users, and use their feedback to counsel Drupal developers,” Jacob noted. One big part of leading from behind is also watching the road ahead.

You can find Jacob Redding at: http://jredding.info/

Photo Credit: by Guerilla Features | Jason Tester used under CC license on Flickr.

The next generation of environmental software needs a vision and some help

ISEES1

At a three day workshop, a group of scientists explored a vision of the “grand challenges” that eco- and earth science face in the coming decade. Each of these challenges, if answered, would provide invaluable new knowledge to resource planners and managers across the planet. And every challenge contained a workflow that called upon software capabilities, many of which do not currently exist: capabilities to handle remote and in situ observations and environmental model output in order to incorporate multiple data layers and models at several resolutions, from a prairie to the planet. Water cycles, pollution streams, carbon sequestration, climate modeling, soil dynamics, and food systems—achieving the next plateau of understanding these processes will require a massive investment in computing and software. The reason for this workshop was to help inform a new institute that can provide key services to make this investment pay off.

Much of this software will be built by research teams that propose projects to solve these grand challenges. These teams will be multi-institutional and are likely to be more focused on the science side of their project, and less on the value their software might acquire by being built on standards, using best-practice coding, and ready for reuse by others. The history of federally-funded science software is crowded with abandoned ad hoc project-based software services and products. I’ve helped to author some of these. One of the federally-funded products (a science education software package) I helped produce had its home-page URL baked into its user interface. After the project funding ended, the PI did not renew the domain name, and this was picked up by a Ukrainian hacker, who used it as the front end of a pornography portal. So the software UI (distributed in hundreds of DVDs) now pointed students to a porn site. A far more prevalent issue is that of software built with 3rd-party services (remember HyperCard?) that have subsequently changed or died, breaking the software after the funding is gone and the programmer has moved on. The point here is that there are dozens of lessons already learned by science software developers, and these need to be assembled and shared with the teams that are building new software.

There is still more value to be added here. A software institute can offer a range of services that will make funded software more reliable, more reusable, and more valuable to science. Much of the federally-funded software development will be done by university staff scientists and graduate students. Most of the latter are in the beginning stages of learning how to program. A crash course on agile programming and Git, or other basic programming skills, could help them get up to speed over a summer. An up-to-date clearinghouse of data and file format issues and recommendations, a help-desk for common CMS and data access problems, and particularly, personal (Skyped) help when the grad student hits a wall: these services can save a funded project from floundering. All together, these services can save the project’s software from an early grave. Research into extending the lifecycle of science software is needed to help science maintain the longer-term provenance of its methods and findings.

Isees2

This workshop was organized by the team that is looking to build the Institute for Sustainable Earth and Environmental Software. Here is their website: http://isees.nceas.ucsb.edu

Who says that “agile” is just for software? Architect an agile online community!

If you’ve familiar with object-oriented coding using any agile methods, you understand that the customer is at the center of the software development effort. The customers problems, her needs and goals, laid out in stories that the programmers return to every day: these keep the software from feature creep and UX failure. Delivering working software in small increments helps the customer reveal the moment they don’t need or understand something. The programmers can toss out that new feature and go back to the customer stories again with fresh insight.

They are testing all the code every day and releasing every week. So there’s never a time when the changing the software costs more than the last time. They are free to pivot toward some new capability that just might provoke delight in their customers; something they would never have tried if the cost of change was growing. Finally, they are solving their customers’ problems and building into the software new opportunities that might not have existed anywhere else in this way ever before. OK, so it rarely works out that well. But the philosophy of agile code development is sound and it offers valuable lessons beyond writing code.

Virtual organization community leaders would do well to consider how the Manifesto for Agile Software Development might be tweaked to be a working Manifesto for Agile Community Development:

Individuals and interactions over processes and tools

Working software (working volunteers) over comprehensive documentation

Customer collaboration (member collaboration) over contract negotiation

Responding to change over following a plan.

from http://agilemanifesto.org/

Let’s look at these one by one. Individuals and interactions are the daily work of the community leader. Staying in touch with members is more important than whatever tool (email, forum, listserve) is picked to accomplish this. Working volunteers build value and direction for the virtual organization. Having a grand, detailed volunteer guide is less important than having a team of members who want to move the organization ahead. Member collaboration means giving the membership as much ownership as possible. Staff are around to take care of day-to-day business, but budgets, planning, and the real work of the VO belong to the members. The staff are the sails, the members are the wind. Responding to change means having a full double-loop governance system and pivoting this to stay ahead of changes surrounding the organization. If you’re only following a plan, you are already lost.

Agile: it’s not just for software anymore!

photo credit: From flickr user magia3e  http://www.flickr.com/photos/magia3e/6236962059/sizes/z/in/photostream/