Last week, we convened a gathering of the Government 2.0 #fail crowd.

The purpose of the meeting was to:

(a) Determine the format of the event,
(b) Identify the target audience, and
(c) Start to craft the topics that would bring forward some of the most pressing issues in government; let alone Government 2.0.

Emma Attunes, Maxine Teller, Steve Lunceford, Justin Franks, Dan Mintz, Steve Guagliardo, and myself were in attendance. Steve Radick, Mark Drapeau, Lewis Shepherd, and Lena Trudeau were not able to make it because they were at conferences, on travel, or some combination of the two.

It was probably one of the most productive meetings I have ever been in. It’s great to work with people who are both smart and equally committed to the cause. One of my action items was to close inform all interested parties on what decisions were made and where we are going from here.

We arrived at decisions in four areas – Audience, Attendance Management, Format, and Title

Target Audience

We are looking for government workers (Federal, state, local, tribal, international, . . .) who:

(a) Are skeptical of the value of social software in government
(b) Have problems that involve bringing together large numbers of people or have sizable datasets that need to be organized, rationalized, and/or shared
(c) Think they have a problem that can be solved with social software, but are not sure
(d) Are responsible for (or have some degree of responsibility for) the problem

As you read this list, may think that you (or someone you know) only fit into one of the criteria above. That’s ok. We want to meet you or your friends even if only one component of the criteria applies.

Semi-Invitational Event

Encouraging people to talk about complex and important issues like risk, agency objectives, and real/imagined obstacles is a central objective of this workshop. The audience and speaker composition involves people who have been involved in multiple aspects of a Government 2.0 implementation or solution. This audience and speaker set would include detractors that often do not wish to spend time attending “another Web 2.0 conference.”

Our approach to getting the people we want in the room is to make this an invitation-focused event. To this end, we will be sending out invitations to a limited number of people. This list may be expanded with an invitation-by request process. Certainly, we will want the invitees to suggest others people they know that might be good speakers or participants at the event.

I recognize that this may seem a little exclusionary. I further recognize that this approach runs counter to our collective ethos of transparency and openness. However, I think that we are demanding a lot from people who are on the fence of adoption. My personal opinion is that we need to give a little to get a little. In this case, we need to make the event more private so that those who are not comfortable sharing publicly today, may share publicly tomorrow.

Format and Progression of the Day

We will be using a one-day “round-robin” format I’ve written about in a previous blog. Each attendee will select a track or interest area. The agenda structure will look something like this:

08:30 – Welcome and Introduction
09:00 – Introductory Speaker
09:30 – Workshop Track 1 (Room A)
Workshop Track 2 (Room B)
Workshop Track 3 (Room C)
11:00 – Lunch
12:30 – Formidable Opponent Debate: Celebrity Guest Appearance by Steven Colbert (ok just kidding – But we will have 2 experts in web security intellectually duke it out)
12:30 – Rotate
12:45 – Workshop Track 1 (Room B)
Workshop Track 2 (Room C)
Workshop Track 3 (Room A)
14:30 – Rotate
14:45 – Workshop Track 1 (Room C)
Workshop Track 2 (Room A)
Workshop Track 3 (Room B)
16:15 – Keynote speaker
17:00 – Close

Finally . . . The Title

After brainstorming a wide cast of titles and themes we settled on:

Mapping Success: Can Government 2.0 Work for You?

We selected this title because it balanced out our desire to state the challenge space in a positive way, but also express the potential for strategic, technical, and implementation #fails.

Next Steps

We have scoped enough of the workshop’s details to proceed with defining the agenda, tracks, and budget. I’ve already received some very excellent ideas through e-mail and from comments on this and related blogs. Thank you soooooo much for those.

We’ll be iterating on those ideas and others over the next two weeks and we’ll get an agenda out to everyone as soon as we can line-up the presenters and speakers. We are shooting for an February date for the workshop.

Thanks for reading and we’ll see you in February!

Evolving a conversation we started back in September, I think are quickly arriving at a solution to the nagging feeling that we need to take the Intra-Government 2.0 movement to the next level.

The Goverati are a small group of committed individuals. It’s not new news that the conversation has become an echo chamber. As a result, I opened a dialogue with Steve Radick, Steve Lunceford, and Lena Trudeau at the very end of the Gov2.0 Summit about how we can get more people, enthusiasm, and get some tough issues on the table.

This is by no means a reflection on the quality of the Gov2.0 Summit or the Expo. Both events, for the first time, drew out some new faces and new questions. The one group we continue to not hear from are the detractors or skeptics of social software.

Deep and Complicated Issues Are Emerging

Larry Lessig wrote a spectacular piece for The New Republic entitled “Against Transparency.” Larry supplies a very cogent argument against the disclosure of too much data from Congressional members. He wraps together several threads and arguments that the government transparency movement advances and dissects the second and third order impacts. For instance, the dangers of drawing conclusions from data (like campaign donation amounts) in the absence of context may have the opposite effect desired. Another example, the richness of some data betrays how poor it actually is because it requires deep analysis to understand it. Lastly, my favorite argument from Larry is the increasingly prevalent phenomenon of the public’s short attention span. We have so many mandatory reports that Congress members need to complete, but very few people in the public at-large are (a) willing to go through it all and (b) no one has the patience to listen to why it matters.

Lessig’s perspective is entirely undervalued in the Government 2.0 community. We need to hear from more people with similar perspectives and ideas.

Voices in the Wilderness of Failure

In addition to the slim number of public, cogent arguments against Government 2.0, our own discussions about failures are truncated. I’m noticing our Government 2.0 conferences either trumpet the achievements of the few or recast a failure as a success.

We all learn something valuable from failed projects. I think, however, that the presence of politics changes the equation. Gene Krantz’s immortal quote, “Failure is not an option,” is the mantra of many Federal executives, Congressional overseers, and taxpayers. And budget dollars are getting more scarce.

As a result, few people in this political environment wish to speak-out about their failures or their agency’s/department’s failures. Yet again, we are robbed of a unique point of view that should be shared, but no one feels insulated/comfortable enough to share it.

Reaching the Unconverted

The problem, in summary, is that the richness and depth of our conversation around Gov2.0 needs to be enhanced. So, in early 2010, our small federation of planners will be hosting a workshop on The Shortfalls of Government 2.0. We want to draw together the informed detractors and advocates who have been hinting at strategies and solutions that are helpful to everyone. We seek a dialogue that informs each side and allows us to advance mission objectives.

The Environment

Intimate settings, NO ATTRIBUTION– In order to hear from those who are the most afraid of embarrassment or political blow-back, we are shrinking the size of each break-out and building it around close conversations. While the number of people coming may be quite large, we will have enough break-out sessions so the there is topical variety and small gatherings.

The Format

Round-Robin Break-outs– One of the chief complaints of participants is that they never get to see everything they wanted to see. We will be working against that problem by having repeating topical sessions. So if you didn’t catch the session on “The Security Vulnerabilities of Web 2.0 Technologies” at 10:00 . . . don’t worry . . . the same talk will be held at 12:00 and 3:00.

Less Talk At You– I find that I learn more by talking to others. In a departure from past conferences and more in line with the Government 2.0 BarCamp, we will be having a conversation-centric format. Facilitators will expect questions from participants. Participants should expect answers from facilitators (and participants).

The Speakers

Detractors and Strategists– We want a morning that is heavy with the dangers and issues around Government 2.0 implementations. This will be a combination of speaker keynotes, debates, and perspectives on the issues around social software. Buttressed against these sessions will be a cadre of strategic thinkers and battle-scarred veterans who can answer your questions and address each issue as it is raised.

What We Need

You. We need participants, presenters, and assistants to build the agenda. Our small planning committee have a few topics we want to address like: Smart Procurement Strategies, Policy, the Law, and the Difference, Detailed Case Examples (what worked, what didn’t), etc.

If you have a topic you think should be covered, submit it to this blog or e-mail me at: bdrake@deloitte.com

In a former post, I talked about the beginnings of a moral framework for collaborative behaviors. The question of what rights an individual inherits in such an environment was the next area to explore.

Contextualizing

Image Credit: Marvel Comics, Inc.

Rights Entail Responsibilities

This may sound strange, but the Principle reinforces a common understanding about the environment. It articulates the expectation that people should behave professionally while having fun and delivering enhanced client service. It also allows the end user to “opt in” or “opt out” of the conditions governing the space. The user is given the choice to accept the benefits and subscribe to the responsibilities being levied upon her/him. Acceptance of these responsibilities becomes a social contract between the individual and the collective corporation. In reality, by already being an employee they have already signed-up to our high standards of ethics and individual responsibility. So in the example of D.Wiki, when a user elects to become a member of the space, they accept the power and responsibility of contributing valuable, meaningful content.

Responsibilities to a Collaborative Space

A behavior I commonly observe in collaborative environments is the “vacuum effect.” This is the user practice of consuming information, but never contributing back into the space. They may also pump the system/people for information, but can’t be found when others are in need. Worse still, the person does not volunteer information that may be of value to others. These are examples of someone leveraging their right to access information, but not taking-on the responsibility to build on the knowledge base. My colleague Justin Franks wrote brilliantly about this topic sometime ago.

The Business and Ethical Implications

There is both a business and ethical impact if this behavior is allowed to continue. On the business side of the equation, the vacuum effect will literally suck the oxygen out of the environment. Trust evaporates. No one will wish to contribute to a space when they discover that their content is being shared and used, but that no one is willing to reciprocate. The stovepipes you sought to demolish will resurface. The cost efficiencies you sought to create will not materialize. And the capital invested into your collaborative environment will be lost when people stop contributing.

On the ethical side, the relationship between the sharer and the consumer is not balanced. It is still true that information is power. Continuing that power imbalance ensures that valuable pieces of knowledge are not shared and denies other participants an opportunity to grow. More to the point, the vacuum marginalizes those who have the best ideas. In an organization with a “vacuum effect”, the information extractors now get credit for the ideas of others. This is intellectually and professionally dishonest because the extractors did not do the cognitive work and will be rewarded for staking claim to it.

It’s just like it was in grade school: No one wants to be the kid that everyone cheats off of.

It All Comes Back to Responsibility

The extension of credit to originators is a fundamental ethical responsibility in a collaborative environment. Extending that credit can occur by tracking the digital exhaust of contributors and consumers, linking to content that is relevant to your idea/work, or by explicitly citing their work. Finally, pushing that such metadata forward in a transparent and easily accessible manner ensures that knowledge theft is pulled into check. Ultimately, regardless of the technical platform, there is always the risk that others will steal your work without you knowing it. In a transparent environment it is aggravating to know people are actively acting against your personal interests. If you find yourself victimized by a knowledge thief, remember to take the high road. Changing a culture of information hording occurs one user at a time. If you believe in the value of collaboration, don’t compromise your own sense of ethics in favor of short-term rewards.

It was a thrill to participate in the Gov2.0 Expo and Summit this past week. Tim and his staff did an outstanding job. The venues were top notch. The sponsors were helpful and insightful. Best of all the crowd of attendees was truly unique and I had a lot of very interesting conversations over the three days. The evening networking opportunities were perhaps the most productive use of my time.

What Was Lacking

There were a few areas where I felt the conference just didn’t quite hit the mark. First was the whole “Government as a Platform” theme. I found myself agreeing more and more with Andrea DiMaio on the idea that government is quite the opposite. At several points during the conference I just felt that the analogy wasn’t exactly a fit. I don’t think this issue was as damaging as I feared. I was glad to see the volume on this dial tone turned down.

The second issue I had was with the focus on citizen participation. Clearly the focus of the Summit was on showing government executives the value of citizen developers. “Just open the data up!” was the transmission and our receivers were on. I felt like this focus often left out those of us working inside of government and do not have a way/responsibility/reason to liberate data.

Third, and finally, was the composition of some of the panels and speakers. Aside from the issue of gender and racial representation at both the Expo and the Summit, I felt that some of the content just didn’t resonate with the mundane, but important elements of working for the government.

What I Was Hoping For . . .

I was hoping for more speakers and sessions that:
Inspired the audience (Thanks, Clay! Awesome stuff)

Challenged the audience

Engaged the audience

Shared obstacle defeat strategies

Tapped into the collective creativity of our tribe

Focused on behaviors first and technology last

Doing Something About It

I spoke with a number of people during and after the conference. In particular, I spoke with Emma Antunes, Steve Radick, and Lena Trudeau about having a Government 2.0 practitioner-focused event. My vision is to have the same type of vibe and enthusiasm of the Summit, but focus the sessions around Enterprise 2.0 deployments and/or the internal difficulties of liberating data. While I also really enjoyed the Government 2.0 BarCamp, I think I would like to take a page out of Tim’s playbook and target an audience of people having with real, non-technical deployment problems.

Atmospherics Count

What made the “over spill” at the Summit the place to be was the more relaxed atmosphere it fostered. So, at this event we will have no theater-like presentations. Round tables; no rows of seats. Face-to-face interactions for sure. Staring at the back of a stranger’s head? Not so much. Intimacy first, distance last. Jokes? Yes. Passion? Absolutely. Work products? For a change – YES! Think fireside chat, but with computers and WiFi.

Next Steps

In the coming weeks, Lena, Steve, Emma, myself, and anyone else who wants to join up, will be meeting to discuss logistics, agendas, speakers, and the like. An event like this will probably take some time to pull together. I’m thinking that we’ll probably hold it in the Spring (at the latest). I’m looking forward to getting my hands dirty and helping out some executives in need. I hope you’ll join us.

So I get this e-mail . . .

A user of my client’s collaborative environment wanted to lodge a complaint against a fellow user. The e-mail sender (User A) submitted an idea for collaboration to a wide audience of other users. User A was asking the community for insights and ideas on a problem he had. This type of data trolling is common and encouraged. The prevailing understanding of the collective is that when data is shared for this purpose, it is usually going to be used for a work product by the requestor. Many people view the request, assess the data available to address the problem, and then a few of the collective offer their perspective. Then a lurker (User B) enters the environment near the end of the collaborative event. He agrees with the collective conclusion of the group and then decides to use the information to advance a localized need and, in turn, advance his career.

So back to this e-mail . . . User A wants User B disciplined for unethical behavior in the environment. On the one hand, I am totally unsympathetic. User B was faster to produce his work product and satisfied his customers in a more timely manner. On the other hand, User A submitted the information in good faith and had an expectation that the collective would respect the product he was working on. It occurred to me that these were really two moral frameworks in conflict. In this case, it was the needs of the community versus the needs of the individual.

Data Poor

This whole episode made me realize that such conflicts of interest and behaviors will only become more common in collaborative spaces. This worries me quite a bit since we lack the moral framework to even understand and frame these ethical problems. Stepping back further, we don’t even have the moral framework to even argue one perspective or another.

I did a fair amount of reading on the topic online and in the library and have formulated some initial thoughts around this framework. I decided to write a blog series about ethical collaboration and this post is the first of many that will follow.

Towards a Moral Framework

In order to understand the “right” or “wrong” of a situation (ethics), you first need a common moral framework to interpret what we know (ontology) and how we learn (epistemology). Why is this important? In order to broker and mediate knowledge sharing conflicts, ethics and situational conditions directly impact the resolution of the situation. So what is the moral framework in a given collaboration space? More directly, what rights to you inherit as a participant in a collaborative space?

As knowledge workers, we expect to have a few immutable rights. This is by no means an exhaustive list, but some of those rights would include:
• Free speech and expression
• Free to interact
• Free to not interact
• Free to supply data access to others
• Free to not supply data access to others
• Free to take action with information

A person has these freedoms and can elect to undertake or reject all of them or each individually. I’m still thinking about this concept, but it is also possible that information has rights too. The idea of endowing an artificial construct with rights is a stretch for me now, but I think the concept is interesting.

Access to Information as a Right?

These freedoms impart both responsibilities and rights on people. It can be argued that people have a right to obtain access to information. Why? We are given one natural defense as humans; our brains. As social and cognitive beings we have biological needs that can only be fulfilled with access to information and sensory stimulation. We are learning beings. We need to learn and understand simple things like how to use a toilet, how to read a book, how to perform mathematics, etc. These simple needs are critical to our ability to function in society. Without access to these basic learning opportunities, a person is deprived of their ability to fulfill their potential. More precisely, people are denied access to other basic rights and liberties.

This brings us to the beginning of a moral foundation for our ethical framework. If actions are taken that restrict or erode a person’s access to information it eventually hinders their freedom of action. This alone is neither “good” or “bad” because situational elements are the ultimate arbiter of “goodness.”

So back to the e-mail I received. The offender (User B) did not “accept” the notion that the information provided could not be used for alternative purposes. In fact, User A had two reasonable expectations in the environment. First, they expected that he would get something in return for sharing the information. Second, they also expected that the collective would gain additional unrealized value by sharing the data. What User A did not expect is that the information would be used for purposes that worked counter to their larger strategic goal.

Having rights means that you also have responsibilities. But more on that in my next blog.

I have been given the honor to be on the planning committee for the Gov 2.0 Expo. O’Reilly Media is co-producing this event with a wide collection of Enterprise 2.0 vendors. This will be the first time that O’Reilly Media has applied its Expo model to showcase government services. The goal of the Expo is to highlight the projects that are leading the way in government innovation, leveraging the web as a platform, driving transparency, participation and collaboration, and reducing costs while increasing value.

What Does This Have to Do With Me?

We are seeking submissions to the Expo. The deadline is 30 June 2009. Don’t worry, there’s still plenty of time. The form is simple and direct:
Proposal title

Description: Brief overview for marketing purposes, max. length 400 characters—about 65 words

Topics (select the most relevant to your proposal):

- Process
- Provider
- Partner
- Protector
- Peacemaker

Session type: 5 minute presentation (no other option)

Abstract: Self-explanatory

Project Environment: Describe the government environment in which your project exists.

Challenges: Describe the situation before your project was implemented. What problems were you trying to solve or the question you were trying to answer? What were the impediments?

Results: How did your initiative change the situation? What were the outcomes? How did you overcome the barriers?

External Links: Are there urls we should reference for additional information? These include project sites, blogs, twitter feeds, etc.

About the Presenter: Tell us about the presenter and and why you/they took on this project.

So What’s In It For Me?

The top four projects in each category will be presented at Gov 2.0 Expo Showcase. O’Reilly Media will bestow a Gov 2.0 Award on the top six projects, chosen the day of the conference.

If you are interested, please submit a proposal through the site here.

If you build it, Joe Jackson will probably not show-up and thank you

You’re Either the Michael Jordan of Collaboration Or . . .

I don’t care what you might hear/read from others, collaboration is a lot of hard work (Randy Nelson is a very cool guy BTW). Does it make your job easier, faster, cheaper, and better? I think it does. But like anything worth doing, its a difficult path to victory. There are some people out there that make it look easy, but even then they will tell you it has been a challenge to get to that level of professional implementation. Even those folks will tell you that getting people to work collaboratively is a grinding, ceaseless battle.

. . . You’re Crazy

I think there are many reasons that people fall into the “just build it” mentality. One reason is the very human (American?) desire to show immediate results. You may have been tasked with creating a collaborative experience or environment, but if there is a disconnect between the organization’s goals and the task then its activity at the expense of progress.

Another reason stems from standing up the technical solution first and then getting business practices to align. Sometimes it is necessary to make this compromise to get the collaborative inertia going. This can not be, however, your only approach. Thinking about collaboration as a multi-faceted business process change problem is much more productive then landing on a technical solution before knowing what the adoption picture looks like (there are some smart guys over there at Wikipatterns.com).

The final reason, I think, has roots in social science community’s theories on psychological dissociation. Clinically speaking, I do not think that just saying “build it” means that people are dissociative (“The unexpected partial or complete disruption of the normal integration of a person’s conscious or psychological functioning that cannot be easily explained by the person”). However, when we pair the entertainment industry’s notion of “suspending disbelief” and clinical dissociation, I think there is something compelling to explore. When faced with a very serious challenge, the human brain can become overtaxed and people are unable to make decisions. As the severity of the consequences rises for the individual, so does their inability to effectively make decisions. This was a highly contentious point of discussion in the nuclear warfighting literature during the Cold War. In the context of collaboration, you’re not making a life-or-death decision, but the enormity of the task might overwhelm your senses and mental logic processes. Given the enormity of a collaboration task, you may be more willing to suspend your sense of disbelief or pessimism in favor of a more favorable projected outcome. The logic trail might go something like this:

Thought A: This is a really big problem
Thought B: We don’t have enough time to figure it all out and build a solution
Thought C: Well, we could just start building it and figure it out later
Thought D: Besides if we build it, people might just start showing up and that would be good

The pain of giving in to the voices comes later when either (a) your customers scream and complain about the solution you selected or (b) don’t show up.

What to Do: Thinking Beyond the Technical

I’m certainly guilty of focusing on technical solutions prior to thinking about the problem. What keeps me on the straight and narrow is asking two simple questions:
1. What is the objective of the activity?
2. Who are the customers?

Be it a conference, brainstorming session, or technology implementation, these questions are important framing devices for any collaborative effort.

Just remember three things: planning, more planning, and executing. Have an idea of what you want to do and what you want to get out of it. Engage early with the customer of your effort to find out how they can help you get what you want and what they want. Finally, be prepared to follow-though on what your customers have asked for. If your budget or other constraints won’t allow you to accommodate all their needs, then you can choose to manage customer expectations or pick the best amongst the ideas to move forward. Just remember if you start hearing whispered voices, please seek professional help.

Ok, I am guilty of taking an occasional swipe at SharePoint. (Much to the chagrin of my dear friend Lewis Shepherd.) So given all the pot shots I take at the platform, I thought I should do the noble thing and advance the debate. I had a recent client experience that highlighted for me the strengths and weaknesses of SharePoint.

Share-Biblio-Point

I think it helps to start-off with a basic frame to understand the design of SharePoint. Think of SharePoint like a virtual library, where librarians decide what you get to search, read, checkout, and use.

SharePoint, at its heart, is a list-oriented database. Like books in a card catalog, SharePoint compartmentalizes functions and data in “lists.” The document library is a list, the picture library is list, the discussion board is a list, etc. The data hosted in each of these functions is then placed into this list superstructure; like books on a shelf. Each of those lists can then have features like access controls, audience customization, data visibility controls, and data feeds imposed over top of the hosting environment.

Screenshot of a typical SharePoint site

For SharePoint, files and documents are king. Any collaborative effort and knowledge creation occurs within the documents and presentations themselves. Some consultants parse this as the difference between document management and records management. This perspective illustrates that we are really talking about file-oriented objects and work products which revolve around the quality of the content resident in the file.

Using Its Powers for Good

SharePoint is well-suited for a few defined business processes. It is ideal for hosting Microsoft Office documents (doc, ppt, xls, etc. – don’t forget to add the “x” at the end of your files if you have Office ‘07). SharePoint tightly integrates with these file extensions and enables features like sequential edits, workflows, and refined document management (check-in/out function). These features make a traditional shared drive model look outmoded.

The platform also integrates with other Microsoft tools like Windows (Instant) Messenger and can supply presence awareness for those who are also logged-on to the network.

Simple web design and customization makes even the most junior SharePoint developer look like a wizard. For those who invest a fair amount of time to understand how the webpart system works, you can quickly deploy a blog, discussion board, or a survey. Your boss and coworkers will start referring to you as “Gandalf” when you can establish a team site within 15 minutes as opposed to 15 weeks.

Then There’s that Evil Thing . . .

An often overlooked issue with SharePoint is the hidden cost of an implementation. That hidden cost manifests itself in many ways. Let’s talk about the Microsoft marketing strategy . . .

Investing Small, Losing Big

If an organization/company purchases enterprise licenses for Microsoft Office, they will throw in the SharePoint software in for “free.” Along with that they may offer some light consulting services to assist with the implementation. As a CIO, you’re thinking, “Free collaboration software? Score! Maybe this will shut those ‘web-savvy’ customers up.” Unfortunately, by the time you complete the implementation and training, you learn too late that the platform doesn’t bend as easily as you may think. Some of the functions that you may want to suit your business needs will likely require the purchase of additional web parts. Its at this point where the Internet becomes your enemy. The number of vendors offering enhancements to SharePoint seems never ending. Users will come pounding on the CIO’s door to make SharePoint do things that it was never intended to do. If you do choose to install some of these apps, you have new licensing and upkeep costs for a wide variety of vendors.

Content Management and Critical Mass

Most collaborative environments thrive on the achievement of critical mass. In SharePoint, the opposite is true. The platform performs best when the collaborative ethos is well established, tight, and contained to a group of about 10 – 30. Why is that? The search features of SharePoint are not as robust as you may think. As evidenced by the rise of third party vendors around search, SharePoint’s search and discovery capabilities are seriously lacking. Files, upon which the environment is predicated, are not easily found. So the more people you have contributing content to the environment, the more difficult it is to find said content.

Making It Too Easy

While one of the greatest strengths of the environment is its ability to quickly deploy web parts to users, it is also its greatest hindrance. With just some light self-driven training, a user who is granted “Design” or “Owner” privileges can deploy any capability they desire. This is often a path to disaster because said “owners” deploy everything out-of-the-box regardless of the business need. This blog said it best:

First let me say that I think SharePoint is a fantastic idea . . . Have you ever heard the “KISS” theory? Keep it simple stupid. Well unfortunately nobody on the Microsoft SharePoint Portal Server team seems to have heard about it. First off, let me say that SharePoint Portal Server is an awesome tool, in theory! However, it seems to have been designed by people that thought they were rocket scientists, and expected some massive adoption . . . Another basic rule in Microsoft has again royally broken, is the “Less is more” rule. Especially when you are dealing with non power users.

The end result is that users who you would like to attract to your site are immediately confused by all the functionality and walk away. It’s always easier to default to your existing business processes than try something new.

One of the things that is rather elegant about a WordPress or MediaWiki installation is that it requires users and developers to think about why and how each environment functions. That thought process surfaces important discussions between developers and users about the business rules that govern the placement, disposition, and processing of data.

It’s Still About Collaboration

Above all else, in my humble opinion (and other’s), SharePoint is not a collaborative environment. The value and Achilles’ heel of the platform is its security model. It is far too easy to restrict data from the prying eyes of others. If you are operating in an organization where data sharing (let alone collaboration) is not the norm, SharePoint does not improve this condition. If there is one thing I have learned in collaboration consulting, if you offer the average user two options of restricting or sharing their information, they will choose the most restrictive option.

The document-centric/list orientation of the environment also makes it difficult to process, analyze, or manipulate data. This document-centered view of information grounds an organization in a print and publication model that is quickly becoming irrelevant.

In summary, SharePoint installations result is pouring digital concrete down organizational silos. I understand Ian Morrish’s perspective that SharePoint does not create silos because there are ways to add authenticated users. With the greatest respect to Ian’s work, this is precisely the problem. Security, once again, is the determining factor for the sharing of information in SharePoint. As long as the information management model prefers access controls, then your chances for bumping into unknown sources of data and knowledge are greatly reduced. This is a highly important feature of truly collaborative environments.

I have grown tired of the term “leadership buy-in,” because what qualifies as “buy-in” is rarely that. Case and point: This video collected by Melcum about leadership’s willingness to allow a SharePoint implementation at ERM. The interviewees praise their leaders for allowing employees to participate in blogs and adopt an “employee-centric” model. These interviewees claim that without leadership support, the collaborative environment would not have been implemented. I have arrived at the conclusion that leadership “buy-in” is necessary, but not sufficient for transformative change within an organization.

I don’t work for ERM and I have never seen their implementation. So it is highly possible that their environment is vibrant and robust with leaders that swap truck-loads of knowledge regardless of company rank or position. It is equally possible that the leadership passively observes and is informed by the events that transpire within SharePoint.

More often than not, the later condition is more common in organizations. Leaders “permit” what occurs in the collaborative space, but they do not contribute to it.

Truly collaborative solutions have two immutable features: (1) transparency and (2) a merit-driven incentive structure. Such solutions are highly threatening to people and organizations that rely on opacity and a incentive structure that is not grounded in merit.

So what are the factors that shape a leader’s decision to participate or not participate in a transparent meritocracy?

Longevity vs. Achievement

Some organizations believe your ability to perform is overshadowed by your tenure in the organization. In the Federal government career system, this is certainly true. This is, of course, also balanced against a set of knowledge, skills, and abilities (KSAs) criteria built around each leadership position. Still, time-in-service is a strong determining factor. In addition, Federal managers are expected to take-on more job responsibilities for personnel reviews, special panels/reports, and other largely administrative tasks. The Federal manager is quickly taken away from the day-to-day activities of their employees and starts to filter office information to maintain a basic level of situational awareness.

When a leader is occupied with other tasks that are not germane to their mission, the decisions she/he has to make are based on less information and contain higher degrees of uncertainty. Collaborative solutions challenge the occupational longevity model by exposing the decision calculus of the careerist leader who only has incomplete pieces of data. A transparent information environment can make leaders look incompetent because they did not consult the wider body of institutional knowledge. Logically speaking, it is in the better interests of leaders to not adopt transparent technologies because they do not assist in improving the integrity of her/his decision calculus.

The Opacity Monopoly

Bosses are bosses because every organization, no matter how informal, needs a hierarchy to make decisions. As such, bosses need unfettered access to information. As a boss you have the right to know about personal leave schedules of every person in the office and you have the right to ask why a person is taking an “unusual” amount of leave. You have a right to know if there is an employee behaving “unprofessionally.” As a boss, you also have the responsibility to discipline people for their behavior. As a boss, you can mandate collaborative behaviors and information sharing regarding the office’s business interests. You can even enforce this perspective by hitting people in their wallets. However . . . that mandate does not flow both ways. Being the boss means that you have the authority to know all there is to know about an office, but you have no obligation to share that data.

Leaders have a information opacity monopoly for legitimate and illegitimate reasons. There is some data that is not appropriate to share in the workplace. For instance, it would be irresponsible for a boss to share the salaries of everyone in the office. Then there is other data that needs to be shared early and often. As an example: Changes in the strategic orientation of the company/organization. The rules are such that leaders derive a significant degree of power from the information they possess. These same leaders also have a responsibility to restrict some information from the workforce. And there is always the possibility of “spooking the herd” by disclosing information that is inappropriately timed. In the view of many leaders, their incentives to share information are laden with risk rather than benefit.

Legacy Business Processes as the Center of Gravity

Everett Rogers advanced a theory back in 1962 that there is a diffusion of innovation effect in any consumer marketplace. He argued that four categories of people surface along any innovation curve: Early adopters, pragmatists, conservatives, and laggards. The Web 2.0 community has incorporated this theory in many ways to explain why certain people gravitate toward one technology or another. I am skeptical of its applicability to organizations because I have seen the model proven both right and wrong.

In any event it is a helpful frame to understand why it is difficult to shift toward collaborative solutions. E-mail, as a common business practice and a technology, is a good example of a business process center of gravity. E-mail fails at doing many things especially collaboration.

Organizations use e-mail as a primary mode of communication. It was the electronic replacement of the old paper-based memo system. It is now the primary means of documenting important business decisions, deciding on where to have lunch, determining who’s bad-mouthing who, and sending around corporate spam newsletters. Leaders are only a reflection of this bias toward this electronic center of gravity.

When Opacity Collides with Collaboration

Jumping the Early Adopter Chasm

I can’t take credit for this analogy, but I think it is a perfect illustration of what happens when collaborative technologies are dragged-and-dropped into an organization. As Chris Rasmussen has explained, the Intelligence Community has installed a robust set of collaborative technologies, but still can’t seem to move past the information product-oriented nature of the culture. As a result, the community finds itself suffering from a perpetual early adopter phase. There are many possible reasons, but my guess is that one of the principal reasons is because the collaborative technologies available to leaders do not help them abandon their e-mail inboxes.

Its important to keep in mind that to leaders e-mail is safe, private, and warm. They trust the recipients of their e-mails will not inappropriately forward the messages to others. This imposes an interesting social pressure for recipients and inserts a high degree of ambiguity over how the information in the e-mail can be shared. In the case of the Intelligence Community, add on top the classified nature of the business. Now it becomes even more difficult to justify abandoning e-mail because it may compromise secrecy. In the meantime, the analysts who work intelligence problems continue to push for more openness through collaborative technologies in spite of the organizational bias toward static information products. Leaders may see the positives in changing the mode of delivering intelligence, but do not feel comfortable enough to make the switch. So the users of solutions like Intellipedia and A-Space find themselves flying over the early adopter chasm in the General Lee wondering what’s going to happen after the commercial break. In the meantime, I would guess that the pressures of intelligence production continue to push on leaders and the preference for e-mail overwhelms the usage of collaborative venues.

The specifics of the Intelligence Community’s problems aside, it appears to be a truism that if the organization is dependent on e-mail so are the leaders that run it. So from a structural/organizational stand-point, as long as leaders continue to rely on e-mails to send information to the workforce, then the collaborative posture of the organization will not improve.

It’s not enough that leaders “permit” collaborative environments, there has to be a wholesale change in the way business is conducted across the enterprise. Technology can do many things, but one thing it can’t do is make an organization flatter. Flatness requires a leadership element that actively seeks to restructure the organization around collaborative outcomes and processes. Change out the rules, not just the servers.

If the Government 2.0 Barcamp did nothing else, it gave me a lot to think about. There were so many great people, conversations, and issues that I encountered I barely know where to begin. One conversation, in particular, has really stuck out in my mind.

During and after the Congress 2.0 session, a contributor made the following statement (I am paraphrasing a bit here):

It seems to me that all we ever do at these conferences is go through this collective catharsis about the government. Everybody says its too hard or there are too many problems with doing this or that. What’s it going to take to just go out and make something happen? When are we going to stop talking about getting things done and actually get things done?

The comment was a little off-putting to me because I work in this area day-in and day-out and I think there are many people making great strides in government leveraging Web 2.0-like apps. Recognizing that I may be biased, I have spent some time critically thinking about this contributor’s comment and wanted to do an little out-loud thinking.

Collective Catharsis? Or Collective Action?

Part of the wisdom of getting the Government 2.0 Club together for the first time was getting the tribe to meet one another. Face-to-face interactions are an important trust building measure and information sharing alone has a degree of value. Before I work with anyone I want to know something about them. Whether that’s a resume, having a meal together, or relying on the recommendation of a trusted colleague. Getting well-intentioned people together is a valuable exercise. This event was one of many to build a larger movement. A movement that will shape and change government for its citizens. Getting people to start talking to one another is an important step in collective action.

One thing is certain, a lot of data was produced from the event that now can be shared with everyone.

Where I Agree

In many ways I sympathize with the contributor (name obscured to protect the innocent). I felt like the participants at the barcamp were of such varied skill levels and experiences that no one ultimately walked away with a high degree of satisfaction.

Me, Raz, and Drapeau at the Government 2.0 Barcamp (Thanks to Ray Smith for the pic)

I was happy to hear people talking about the regulatory, legal, and political issues that face this community. That communicates to me that people are thinking through the implementation process and are seeking advice on how to make their project succeed.

Avoiding Programmatic Disaster

Anyone who has implemented a software solution for the government knows that regulatory and legal compliance processes command respect and with good reason. These are what I call killer issues. “Killer” in the sense that if you ignore them, then someone will close down your operation. You can follow a “just do it” philosophy and you may succeed. You are, however, taking a gamble. And you are gambling with taxpayer dollars tied to Congressional and Executive Branch reporting requirements.

Nothing infuriates me more than a software implementation where no one thought through the legal or regulatory issues that need to be addressed. Perhaps the one exception is not having a reason to implement the particular software solution. [steps off soapbox]

Simply put, you can not ignore these structures for two reasons (1) those are the rules and (2) other smart, well-intentioned people put those rules there for a reason. You may not agree with their reasons for putting those rules there, nonetheless they are the rules. Those who put the rules there have thought through their reasons for writing down control mechanisms. It would be prudent to at least consider their reasons before disregarding them. Bottom-line: Ignorance of or “wishing away” these regulatory and legal barriers is folly. Simply because ignoring those who wrote or enforce those laws/regulations have the power to end your program.

Where I Disagree

The good news is that there are many people in our community who have already encountered and fought these battles. So when I hear people going through the “catharsis” described above, instead of whining I hear people asking for help. Instead of despondency, I hear the exasperation of scarred social software evangelists. Instead of fear, I hear hope. There is no doubt, admiring the difficulty of navigating the government regulatory environment is an approach that some have taken. It is the perspective of some, not all. I would rather give those trying to do good the benefit of the doubt before I pass judgment on their feelings and statements. I hope that in this time of dynamic change we can all help our fellow lead adopters. Even if that means just listening.