Quantcast

Archive for the ‘How We Work’ Category

Collaboration and leadership

Sunday, November 29th, 2009

Much of our work on the social business side focuses on a key question: how do we collaborate online, or more simply how do we talk to each other with online tools to get things done? Part of the solution is in finding the right tools, or combination of tools, to be effective. Some tools just won’t work in many contexts.

Wiki, for instance, is a tool (or a set of like patterns implemented in various tools) designed to support collaboration, but a wiki often fails to support successful collaboration because one or more essential members of the group don’t (or can’t) use it. This is often because wiki is so undesigned – which can be a strength in making it adaptable, but turns out to be a weakness for those who need more structure, more of an imposed information architecture. Just one essential member’s failure to adopt can produce failure, so the wiki format has succeeded only where it’s been modified (as in the SocialText “wikiblog,” which became less of a wiki as it became more of an enterprise application).

I’ve seen resistance to pretty much any collaborative tool. We tend to use Basecamp, which combines several communication patterns (messaging, wiki, shared to-do lists, file sharing), and we find that among those who have used Basecamp before, there can be a small but significant percentage who push back – who are looking for an effective alternative for whatever reason.

A few years ago I was involved in multimodal “happenings” to create collaboratively a paper published by Joi Ito, called “Emergent Democracy.” We initially combined audio teleconference with a form of realtime chat that included color-coded flags and a “hand” you could “raise” if you wanted to talk. The chat was partly used for these visual cues, and partly as a backchannel that added more depth to the conversation. We took notes on a wiki. The draft of the paper was intially shared as a Word document with change tracking, then dropped into QuickTopic where it could be collaboratively edited. It was finally dropped into a wiki for more collaborative editing. The collaboration was very successful. Today we have reasonably inexpensive tools, like GoToMeeting, that incorporate voice, chat, and shared presentation – very similar to the combination of patterns in the happenings.

More tools are emerging for collaboration, and one that we’ve been studying with keen interest is Google Wave. It’s still very beta, with limited adoption, so our experiments have been limited so far. However it’s promising: in Wave you can create a conversation, add participants at any point after the conversation starts, and play back the conversation as needed to keep track. Wave accommodates collaborative editing as well as conversation. It’s not an application that Google is developing, but a protocol that is being developed with Google in the lead, but with many external developers participating. The intention is to have a far more robust communication protocol that will replace email.

Finding the right tool set is key, but another crucial challenge is social: how do you keep a conversation on track and focused on decision and action? This is especially challenging with flatter hierarchies and headless organizations. In the emergent democracy discussions, we talked about a concept of emergent leadership, which was an acknowledgement that you must have leaders to make decisions and get things done, and in a context where no one is elected or appointed to lead, we look for one or more leaders to emerge. There are questions around how that leadership emerges, how it’s identified, acknowledged, accepted by the group, etc.

In companies and organizations where leadership is based on assignment or election, the questions about leadership are more traditional: how to get buy-in from the group, consensus on decisions, agreement on action items. This is partly about leadership quality (is the leader acknowledged and accepted by the group?), but also about organization (how well is group input and ultimate consensus orchestrated and managed?)

Bijoy Goswami of Bootstrap Austin and I recently worked together on a presentation called, an earlier version of which can be found on Slideshare. In defining how to create effective communities – communities that get things done – we considered Bijoy’s “human fabric” of three personality types: maven (knowledge-oriented), relater (relationship-oriented), and evangelist (action-oriented). We suggested that communities, like individuals, can be characterized on a scale between any two of the three personality types. For instance, a community might fall on the axis between maven and relater – i.e. be focused on knowledge and relationships. This is where we would place an online community like the WELL, where members “hang out” and have casual conversations that are not focused on any action or deliverable. We went on to say that action-oriented communities would have a strong evangelist flavor, and would include one or more evangelist types who push for specific results.

This is probably true for any collaborative environment, including a small meeting. An evangelist or action-focused leader could be more effective in getting specific actions accomplished. This person might fall naturally into the leadership role. However a strong evangelist should be sensitive to the relevance of the other personality types: it’s important to have enough of the right knowledge to move forward, and getting things done can require attention to relationship.

In summary, effective online collaborations (meetings, projects, organizations) depend on tools that work for all stakeholders, or at least on a shared commitment to adopt and use the same tool set and patterns for communication/collaboration. Social considerations and leadership are as important as adoption of and commitment to the right tool set. It may be effective to include evangelists in action-oriented workgroups, and to have them lead, but sensitivity to the balance of personality types and strengths is important. And, of course, the reality is far more complex than we’ve taken time to capture here.

Evolution of the social web

Tuesday, November 3rd, 2009

At Social Web Strategies, we’ve been saying that the future of the social web includes data portability. An April Forrester report drew the same conclusion.

Today’s social experience is disjointed because consumers have separate identities in each social network they visit. A simple set of technologies that enable a portable identity will soon empower consumers to bring their identities with them — transforming marketing, eCommerce, CRM, and advertising. IDs are just the beginning of this transformation, in which the Web will evolve step by step from separate social sites into a shared social experience.

Brian Solis at Social Media Today writes about Forrester’s report, saying that social networks are evolving into a social operating system, and that “social networks and sites will recognize the preferences of users, but more significantly, they will also recognize personal identities and relationships to customize the experience based on preference and behavior….I believe that the combination of semantic and collective intelligence systems will improve the content and overall interaction within sites and social networks over time.”

None of this is really news, maybe clarification. I was in conversations with Tim O’Reilly and others in the early 2000s that acknowledged that the Internet/Web was an operating system and inherently social. Those conversations led to the paper Tim and Dale Daugherty wrote that loosely defined concepts labeled “Web 2.0.” The Data Portability Project kicked off in 2007, and we’ve been trying to get our heads around individual data management since the 1990s (thinking of P3P). Thinking about the semantic web has been brewing since the turn of the century. Various data interchange formats and semantic web projects have emerged since then.

What’s interesting in Solis’ piece is the concept of SRM – Social Relationship Management – vs Customer Relationship Management and Doc Searls’ idea of Vendor Relationship Management. CRM and VRM combined make a whole greater than the sum of its parts. We get to a point where customers and vendors are transparent to each other, and are part of a larger social ecosystem that can facilitate authentic and symmetrical relationships. Solis says

The biggest opportunity for the expansion of social networks is to build bridges between these isolated islands to deliver a more fulfilling, meaningful and productive experience. As I see it, we will start to see a the social web not as a collection of distributed islands, but as one greater collective better known as a human network – a contextual and relationship-based network that consists of like-minded individuals no matter where their profile resides.

Seven Laws of Projects

Thursday, October 1st, 2009

Social Web Strategies is a project company inspired by the same kind of thinking that Tom Peters discussed in his Fast Company piece about “The Wow Project,” and I’ve been doing project work for decades, so Matthew May’s article “The Seven Laws of Projects, and How to Break Them” resonates very clearly. These laws are about the very human dysfunction that can creep into project work. Many projects fail, but many more kind of succeed, but are broken because of these laws, which according to May exist

because our eyes are bigger than our tummies. We have delusions of success. We take on more than we should, routinely exaggerating the benefits and discounting the costs. We over-scope, over-scale, and over-sell. At the same time, we under-estimate, under-resource, and under-plan.

He follows with another paragraph about the fundamental truth of projects:

Projects—even small ones—are complex and challenging. Interests often compete and conflict. Individual performance varies widely. Continual shifts in direction and frequent stalls that slow momentum demand constant planning, adjustment, and improvisation—skills that only come with battle scars.

He then gives an example of a project that broke the laws – the Mars Pathfinder project – and succeeded in big ways, with a combination of creativity, obsessive testing, and incorporation of speed and flexibility into the design.

(I’d like to read, or maybe even write, a whole book on how to break the laws, with case studies!)