Author Archives: Bruce Caron

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/

Sharing Creativity: Talk given at 2012 ESIP Federation Summer Meeting.

Here is a talk I gave at the recent (Summer 2012) ESIP Federation meeting. Sharing Creativity:

I am hoping that this talk will lead to some conversations over the potential for virtual organizations to achieve, with more efficiency and effectiveness, a capacity for creativity and predictable innovation. This capacity—in large part due to Internet-enabled capabilities for coordination and collaboration— can, I believe, rival (at various scales) the capabilities of dedicated R&D facilities/programs such as Bell Labs and Xerox PARC on the corporate side, and the Manhattan Project and the Apollo program on the government side.

Bohr, Oppenheimer, Feynman, and Fermi: Key requisite variety of knowledge assembled for the Manhattan Project. http://en.wikipedia.org/wiki/Manhattan_Project

Large research and development operations such as these were built as national laboratories, with hundreds or thousands of employees and forefront facilities. They were designed to assemble a critical mass of talent and direct this toward innovation. They were also enormously expensive: the Apollo program had cost more than $25 billion by 1973 (in 1973 dollars). The successful ones are rightfully famous.

Today’s top technology companies (Apple and Google, for example) often add to their innovation potential by buying forefront start-up companies, as much for their talent as for their technology. Their goal in a highly competitive market is to own enough talent, enough intelligence, enough creativity, to stay ahead of their rivals.

The basic business-school rule for improving the odds for successful innovation is to assemble a requisite variety of knowledge: a range of knowledge at least as large as the problem being tackled. The three ways to do this are the following: Hire it (add to your team); Grow it (reeducate your team); and, Buy it (purchase a rival company/team). All of these methods assume that you need to own the requisite variety of knowledge.

Science, on the main, has only one rival: the unknown. Scientists are relatively free to seek out new collaborators from anywhere. And, through Internet-based services, they are now enabled to become collaborators everywhere. This is one reason why the NSF has been promoting virtual organizations and research networks as the future of science collaboration (instead of building new centers at institutions). A good part of the potential that virtual organizations offer government and private funding agencies comes from a new logic for innovation: assemble and share the requisite variety of knowledge.  With the right sort of organizational governance and funding, a virtual organization can achieve what the older “think tank” R&D centers could: predictable, successful innovation.

There are some social aspects of the ESIP Federation that might be key to this capacity for creativity. These aspects are not secret, however, and can be fully copied and applied in other arenas. They are also not expensive (the Federation budget is remarkably small), but they are of great value, in that they have been worked upon by dozens of volunteers over the course of more than a decade.

Virtual organizations (VOs) come in many forms and sizes. The science of building and managing VOs is still being explored. There are many examples of early failures, and only a few examples that herald their potential success. Members of virtual organizations need to be sufficiently engaged to build collective intelligence. Take a look at the YouTube video and let me know what you think.

From carrots and sticks to donuts and heroin: what academic software producers need to learn from their commercial counterparts.

Carrot and Stick

I’ve spent much of the past decade managing software development projects. These projects can be sorted into two types. One type involves collaboration with academic organizations, mainly with government agency funding. The other type is with commercial partners and an eye toward the open marketplace. Software project management for both types is similar in most ways. Both types used the same agile software development process. The agile project management process includes a conversation about user experience and engagement. In fact, it starts with user problems and stories and use cases.

The notion of customer-driven design is a central feature of all good software development. So too is the goal of creating something of immediate use and widespread need. There are some differences that, when teased out, suggest arenas where academic (and other, open-source) software developers might want to learn something from commercial software development practices. The reverse is not as obvious at the software development level, but is more evident in the user licensing and IP level.  At the code level, the process of development and design for academic/government agency software can be quite different than commercial software. This difference is mainly a matter of user expectations. As Doc Searls noted, “…Microsoft needed to succeed in the commercial marketplace, Linux simply needed to succeed as a useful blob of code” (Searls 2012, Kindle Locations 2262-2263).

A couple of conversations in the academic software code arena can illustrate how far apart these two types are. In the first, I was told that “we can deliver this with the warts showing, as long as it works.” And in the second, someone noted that some combination of “carrot and stick” could be applied to make sure people used the software service. Compare this to the goal that Guy Kawasaki promotes for software: enchantment. “There are many tried-and-true methods to make a buck, yuan, euro, yen, rupee, peso, or drachma. Enchantment is on a different curve: When you enchant people, your goal is not to make money from them or to get them to do what you want, but to fill them with great delight” (Kawasaki 2011, Kindle Locations 185-187). No warts or sticks allowed if your goal is enchantment. In fact, not that many carrots, either.

I countered the carrot and stick suggestion with one of my own, “How about donuts and heroin?” In commercial software development, it’s not uncommon to ask “So, what is the heroin in this software?” The idea is that the customer would be so enchanted with the software that they would gladly use it every day. Even the worst experience should still be a donut, and not a wart, and certainly not a stick.

Certain realities do intrude here. Academic and agency software developers work on the tiniest of budgets. They tackle massive problems to connect to data resources and add value to these. They commonly have no competition, which means they solve every problem on their own. A “useful blob of code” is better than no code at all. But still, they might consider imagining how to enchant their users, and provide a few dimples and donuts along with the worts and the carrots. Because their users spend most of their digital lives on the daily heroin supplied by Apple and Google and Facebook, being handed a carrot may not do the trick.

Kawasaki, Guy (2011-03-08). Enchantment: The Art of Changing Hearts, Minds, and Actions. Penguin Group. Kindle Edition.

Searls, Doc (2012-04-10). The Intention Economy: When Customers Take Charge. Perseus Books Group. Kindle Edition.

Photo credits, CC licensed from Flickr:

carrot and stick: bthomso

carrot on plate: malias

donuts: shutterbean

eating donut: Sidereal

The Intention Economy: a window into the next phase of the Internet

Doc Searls

Doc Searls: The Intention Economy. used under CC license from dsearls on flickr.

I just finished Doc Searls’ latest book. This book is several things, all of them good. This is a knowledgeable look at the future of being a customer in a world where the Internet realizes its potential as an information commons (instead of a storefront). The book is simultaneously about being a consumer and a customer (not exactly the same), and about big data and little data (the data you should be in control of), and about the Internet and the economy. Doc introduces a new (5 years old or so) effort to create software services that enable customers to announce to the world their intentions, and to then receive bids from vendors who wish to sell the products and services that might be some value for those intentions. This is a reversal of rules and roles which currently lock customers into the loyalty silos that companies use to corral their wallets.

Every chapter in this book is a revelation on an important topic, from the coming collapse of the advertising bubble, to the need for customer-based contracts instead of the current lopsided boilerplate contracts of adhesion, to the Internet as a managed commons, which can support individuals owning their own data and negotiating with an open market for what they need: based on their own intentions, rather than from some expensive (in money and effort) algorithm devised to mine their data and ferret these out. Who knows their intentions better than the customer?

The new economy, based on fourth-party brokers that act on behalf of the customer —not the vendor—will be open (newcomers welcome, no silos allowed), efficient (no more guessing intentions, transactions are knowledge-full), effective (allowing vendors to work together), and it will bring the Internet closer to its potential as a free exchange of knowledge that can also support innumerable transactions and contracts. In the end, this is also a story of a work in progress, as Doc and others have already started to build software services to explore this new economy. This is an important work, that announces what could, and I would argue, should be a new direction for an Internet enabled economy.

As a bonus, the work is extraordinarily well written at the prose level, and is not simply a blog-to-book. Each chapter adds substantially to the overall argument. I cannot recommend this book too highly. I am encouraging friends and strangers alike to give it a read.

I would also submit that there are corollaries to the commercial vendor/customer relationship that Doc’s logic and services would help improve. How much better would civil society be if the intentions and the capabilities of citizens, and the problems they face, were announced in this fashion to their local governments? How much more effective would continuing education be if the student could announce the skills they require to the world and have multiple offers for training? The Internet as a managed commons (Doc does a great job of advancing Lewis Hyde’s work on the commons) extends to many facets of our social interactions, not just those that involve transactions for money. Doc does talk about micro-transactions, but there are also new efforts to enable a sharing economy that would benefit greatly from these services.

Doc Searls: The Intention Economy: When Customers Take Charge. Harvard Business Review Press

http://www.amazon.com/The-Intention-Economy-Customers-Charge/dp/1422158527

Hulk want Negroponte Shift in publishing now

It’s one of those weeks where the clanking chains of the ancient devices of academic publishers have been more than a bit annoying, and it looks like no amount of WD40 will smooth the transition into digital delivery without first demolishing these anachronistic machines and their devilish DRM schemes.

This morning on NPR there was a bit on how public libraries need to subscribe each year to access the same digital files for eBooks, in order to provide these in serial increments to individual users. No overdue books here, the narrator notes, the digital files simply disappear from the user’s device, forcing them to queue up (and wait for weeks or months) until the digital file is again available. The more popular the book, the longer the wait.

I also had the opportunity to search for and find a book published by an academic press in Europe, and was informed by their website that I could download a digital copy for only $100+. Makes the iTunes bookstore seem cheap.

And then, with a link from William Gunn, I made myself read a response to the open access demands by scholars, students, and libraries, by a (IMHO fatuous) mouthpiece of the publishing industry in the Guardian. At one point he justifies the bloated profits of the industry by noting that they pay taxes on these (not if they can help it) and the government uses these taxes to fund (wait for it)… research. For profit academic publishers are the “research producers” that keep the wheels of science rolling. Lord help us if the (socialist) open access lumpen masses get their way.

On the more hopeful side, John Wilbanks and the Open Access Gang of Four are most of the way to a successful open access for research petition on the White House petition site. And if only the intern who programmed the Drupal user authentication for that site had hooked in a better module, then it’s likely that the necessary 25,000 signatures would have already been accomplished.

At last look, over at The Cost of Knowledge, 11,923 scholars have pledged to not give their services to Elsevier.

And, today we will find out if Redditors can oust Texas representative Lamar Smith, who co-authored SOPA.

We are all waiting for everything to digital and available and searchable and browsable, and linked, and curated, filtered and yet without the bubble, semantically rich, and, of course, free. We are not there yet, plenty of cruft to clear away. Time to point the Hulk at the entire academic publishing enterprise and say “SMASH.” It couldn’t hurt.

10 Rules for a Santa Barbara Charrette (Part Two: the Final 5)

Part One is here

RULE 6: Use big paper Post-its to gather ideas.

The table conversations need to be captured first on big Post-its. Have the table choose a recorder. All comments are written down. This means that each person’s contribution is captured and made visual for the table. Do not simply write these on a computer. Sometimes the person who made the comment will want to revise this, or expand on it. Sometimes the recorder will not understand the comment, and will ask for clarification. Everyone’s voice is heard in this process. The conversation moves as fast as people can talk. When silence breaks out, the facilitator will come by to ask if the table needs another question.

RULE 7: Create narratives from the Post-its and put these online immediately.

Have a volunteer at each table (graduate students are good for this) who merges the contents of the big Post-its into a narrative. This narrative might be one paragraph, or several. I like to open up a Forum space on a Drupal site for each question, but you can capture these narratives in any way that works for you. Google documents, shared Dropbox: whatever you are most familiar with. The Post-its and these narratives are the output from the meeting. They are the gold you have woven from the ideas of your participants. It is tempting to skip the Post-it and go right to a computer. Do not allow this. The Post-it step is there to keep the conversation flowing and the let each person know their ideas are being captured.

RULE 8: Many conversations in one room.

Workshop planners often make the mistake of having a plenary room and then breakouts in separate rooms. Set up the main room in round tables; all the conversations will happen there. It will get loud, but people will also gain energy from the buzz in the room. And when they are voting with their feet, they only need to meander to another table and join the conversation.

RULE 9: No long introductions. No formal report-outs, but quick checks. No breaks, break anytime.

At the start, have each person stand and say their name. Then have them give three words that express their hopes for the day. This should take only 10 minutes.  During the course of the day, have a volunteer print out the narratives from the tables and post them on the wall near the coffee in real time. Let the display of these become an ongoing marker of the accomplishments of the workshop. Do not have any special report-out breaks, this only slows down the conversation. Do not schedule coffee or other breaks (except for lunch if you started in the morning), but encourage everyone to take a break any time they feel like it. They can get coffee, walk around the block, and do whatever they need to gather their attention back to the workshop. Once an hour, the facilitator will do a quick check-in with the room. Stop the conversations briefly to ask if there are any concerns about the process, and remind people to go look at the report-out wall.

RULE 10: Facilitator keeps the conversation going.

The Santa Barbara Charrette is a fast-moving symphony of conversations and inspirations. The key is to keep the ideas flowing, capture these as effectively as possible, and support each table with a supply of questions and a recording mechanism. The main facilitator will walk among the tables ready to supply a new question, or to gather the “hot topic” questions for other tables to answer. The facilitator will also decide when to rotate the tables, and can help keep the process on track.

At the end of the day, be prepared for the participants to be excited and exhausted. They will feel like their ideas have been heard, and their contributions have been saved. When they browse the report-out display, they will see how their table’s answer to the questions exposed different solutions from those of other tables. They may want to be alone after eight hours of constant conversation. They might be ready for some beer. At the end of the day, you will likely have a document that is hundreds of pages long, with multiple insights into the key questions that your organization faces. You will have mined the best ideas from 35 people. And these 35 people will leave the workshop satisfied that their time and their expertise has been well used and honored.

 Final Words

The Santa Barbara Charrette can be used for a wide range of planning and design problems. I’ve also done successful “mini-charrettes” with two or three tables. When you ask anyone who has participated, they will tell you how much fun they had getting their brains picked. They might also note that other workshops, where they are forced to watch PPTs in a room with 100 others, and then raise their hands one-by-one to speak, now seem boring and inefficient. This is the downside of the Santa Barbara Charrette: once you’ve gone there, you can never go back.

10 Rules for a Santa Barbara Charrette (Part One: the First 5)

Building maximum engagement into your workshop

Some years ago I organized a workshop to brainstorm how ocean scientists could find new research and communication capabilities through the use of social networking and social media. With funding from the Paul G. Allen Family Foundation, a team based at UC Santa Barbara was looking to create the next generation of internet-facilitated science. We called the project DigitalOcean. But first we needed to gather as many ideas as we could from thought leaders in a wide range of domains. We needed to have confidence that our plans were well scoped and in the forefront of emerging opportunities.

Participants came from across the US to help the DigitalOcean (DO) team envision this new suite of tools for ocean science. To support the discussion, I looked at a wide range of meeting types, and focused, finally, on an open meeting-style workshop, with a clear set of rules. For an entire day, thirty participants, split into groups of 6-7, discussed a range of issues and provided the DO team with a broad picture of how to move ahead.

I chose the term “charrette” to describe the event in part because of my experience in architecture charrettes at UC Los Angeles, and in part because of design outcomes we desired matched the intensely reflective process that a charrette produces.

In subsequent years, I’ve used the Santa Barbara Charrette model a number of times, and each time I’ve received the same feedback. It goes something like this: “I’ve just worked harder and I’ve also had more fun than I have ever experienced before at any workshop.” At the end, people actually complain of “brain fatigue,” a condition we help cure with beer.

If you are interested in doing your own Santa Barbara Charrette, you follow these 10 rules (The first 5 are here, the next will be in the next blog):

RULE 1: Pick a place that’s right in town and give them dinner/lunch

Before the charrette starts, make sure you feed to participants. Pick a downtown hotel near cafes and bars. Never do this at an airport hotel. If your charrette starts after lunch, feed them a good lunch first. If your charrette starts in the morning, feed them dinner the previous night. But do not try to gather them for breakfast before the charrette. People have a variety of breakfast desires. Have a table with coffee and snacks in the room.

 RULE 2: The ideas need to travel at the speed of conversation. No more than 35/36 people. Small groups all day.

The charrette planning should focus on getting a wide spread of expertise in the room, but no more than about 35 people (7 tables of five, or 5 tables of 7, or 6 tables of 6). The whole day will be used to promote critical conversations at these tables. As soon as the conversation lags at a table, give it something new to do (e.g., another question [see #4 below]).

RULE 3: Open with a blue sky session, get the creative juices going.

Start the conversations with a real “blue-sky” design problem. Let everyone add their fantasy to the solution of a problem. Give them paper and markers, scissors and glue. Give them props and tape. This is the only session where there is a brief report out. Let the groups compete for the most fantastic solution. Have them map their ideas on big Post-its and then stick these on the walls of the room. This beginning session is designed to help the group achieve an open conversational mode of interaction.

RULE 4: Give them real questions to answer, and let them add to these.

After the blue-sky exercise, each table is given a question to tackle (not necessarily the same question, although most tables might end up answering every question). In the weeks before the charrette, spend real time coming up with 10-12 key questions. Map out how the answers to these add up to a larger picture. Rank these questions as “central” or “if time allows”.  Create some colored sheets of paper that say “Hot Topic” on them. Give each table a few and encourage people to create their own question. Give these questions to OTHER TABLES. Never let someone answer their own question. Some questions will be better answered by tables with specific expertise, others by tables of mixed expertise (see below). This rule was provided by Susan Colitan, Vice President of the Paul G. Allen Family Foundation. The better the questions the more knowledge you will extract from the workshop!

RULE 5:  Break up groups 2-3 times over the course of the day and vote with your feet.

Give each member a name tag (first NAME on both sides). This tag should also tell them which table at which to sit (designated by color, number, animal, etc.). You might want to start by mixing up the expertise at each table. For example the COLOR designated tables might include a technical expert, a managerial expert, some content domain specialists, and others. After a couple hours, have everyone switch to the NUMBER table, which might be grouped by expertise. Later, they might switch to an ANIMAL table, etc. At the end of the day have a final question back at the original table. At any time anyone can move to a different table. This is called “voting with your feet.” Announce this at the beginning and also every time your swap out table designations.

The next 5 rules will be found here: Last 5 rules for a Santa Barbara Charrette.

Imagine your virtual organization (VO) as a street festival

Photo from Flickr. CC by Jesslee Cuizon

I once spent several years studying how communities assembled festival productions in the streets of their towns and cities. This includes almost three years in Kyoto, Japan, and other experiences from South India and the US. The impetus behind this (no, it wasn’t the beer, but that helped) was to see a form of cultural production that was forced to renew itself regularly, and to describe and explain how that cadence of activity could sustain an enormous volunteer effort every year. I was also interested in festivals as they often included activities and behaviors that were not available or advisable on the streets during the rest of the year (aspects of comedy, nudity, violence, politics, joy, and sex: stir together and stand back). The time and space of the festival did not just occur on the street, it transformed the street. Much the same could be said for the impact of the event on the lives of the participants.

I also saw a lot of festivals that failed to transform the street, that had been, somehow, reduced to parades and pageants, to a semblance of their former glory. In these events participation was simply another chore. As such, participants required payment. Volunteerism declined. The vestigial energy of the festival was provided by the music and the movement. But the ability to transform the lives of the participants was lost.

The craft and the logic of a festival event are in many ways similar to that of any virtual organization that hopes to engage its members. The face-to-face meetings or your organization may not achieve actual festivity, but the power of your organization to transform the capabilities and empower the hopes of its members should never be forgotten.

Several years ago I wrote a piece for the Kyoto Journal, “Imagine the festival as a building,” in which I asked readers to imagine their community-based organization (festival or virtual) as a building, a house that is rebuilt from scratch every year. The main messages of this article outlined how the process of designing and constructing the house each year supported the neighborhood in vital ways, and explored how this event would certainly be destroyed when its festival logic is violated, even if an event kept happening.

The essence of a festival logic is honest and free voluntary participation and expression.      A radical form of intimacy emerges. Some scholars tie this back to ancient forms of human physicality (e.g., Cox 1969; Stallybrass and White 1986); however, Anthony Giddens (1992) anchors this form of intimacy also as a hallmark of current modernity. We all want to achieve more moments of intimacy.

Festival logic informs the whole process of design and performance. When you incorporate a similar festival logic into your community-led virtual organization you unleash new levels of member engagement. Street festivals generally focus this energy into artistic forms, while your organization might focus this on product development, creativity, and innovation. If you can imagine your VO as a street festival, you might discover its festival logic. If you cannot, then you might want to ask yourself how to add this logic to your organization.

References

Caron, Bruce. (2011) Imagine the festival as a building… [Internet]. Version 1. lightblueblog. 2011 Dec 25. Available from: http://lightblueblog.wordpress.com/article/imagine-the-festival-as-a-building-2l8t3cliewok9-48/ .  From Caron 2003 http://junana.com/CDP/corpus/COMMENT20.html

Cox, Harvey (1969) The Feast of Fools. Cambridge: Harvard University Press

Giddens, Anthony (1992) The Transformation of Intimacy: Sexuality, Love and Eroticism in Modern Societies. Stanford: Stanford University Press.

Stallybrass, Peter and Allon White (1986) The Politics and Poetics of Transgression. London: Methuen & Co.