- Recent
- Popular
- Tags (0)
- Subscribers (2)
- Brokerage and ClosureDecember 2
-
Some time ago, I blogged about the difference between in-the-flow and above-the-flow uses of wikis and social software more broadly. At the time, I argued that "above-the-flow" use cases fail to generate adoption for the same reason that knowledge management failed in the 1990s: because it's really hard to motivate people to step outside their daily flow of work and do something extra. My conclusion was that social software delivers maximum business value when workers use it to collaborate transparently "in the flow" for things like managing projects, writing trip reports, capturing meeting notes, etc.
In short, my attitude was: In-the-flow rocks, above-the-flow flops.
This way of putting this has been bugging me lately. I've had the nagging feeling that my attitude towards above-the-flow was overly dismissive. A recent conversation with Nat Welch from the Center for Applied Research finally clarified for me what my analysis had been missing. Nat pointed me to the distinction between brokerage and closure articulated by Ronald Burt, a business school professor at my alma matter, the University of Chicago. Burt describes the distinction this way:
Brok
- Six Steps to Company-Wide AdoptionDecember 2
-
Social software is changing in ways that profoundly impact the way companies should approach adoption.
A year ago, the focus was on individual technologies (wikis, blogs, RSS, etc.). We are rapidly evolving to more comprehensive solutions that integrate multiple technologies into unified platforms for enterprise interactions. That's the insight behind Socialtext 3.0, and it's the level at which companies are implementing.
As the market has shifted from individual technologies to integrated solutions, we're also seeing a dramatic shift in the level at which companies are implementing. A year ago, companies were piloting social software for individual teams or departments. As the solutions become more comprehensive, companies are evaluating them for enterprise-wide deployment. They are looking to social software to transform their organizations--their entire organizations. They're trying to change behavior on a grand scale, not shake up a team or two.
That calls for a very different approach to adoption. Last year, everyone was asking what makes for successful social software pilots. Now it's time to answer the question at a strategic, company-wide level: How can forward-thinking managers use integrated social software suites like Socialtext 3.0 to garner adoption across their entire companies?
The answer is not "Do what you did in the pilot, only bigger." Company-wide deployments are very different
- Groups and NetworksOctober 8
-
Stowe Boyd recently posted the following statement:
I disagree with the notion that Enterprise 2.0 is about groups not the individual. On the contrary: Web 2.0 is based on the person and personal relationships in networks, not group membership.
It came in response to a post of mine about Enterprise 2.0 adoption where I wrote that:Enterprise 2.0 posits the group as the primary unit of activity; email posits the individual
Boyd's drawing a really important distinction here. In our daily lives, we are all members of various groups: our families, neighborhoods, church groups, ethnic groups, etc. Also at work, we are members of groups: departments, business units, project teams, carpools, weekend soccer players, etc. These are collections of people--more or less dynamic, more or less formal--who share some common set of attributes, activities, or interests. At the same time, we all have our personal networks--the individuals whom we know and interact with. There is of course a lot of overlap between a person's groups and her network; we know many of the people in our groups. But an individual's personal network typically spans multiple groups. My network, for example, includes my colleagues at Socialtext, my former McKinsey colleagues, my neighbors in Philadel - Structure and Corporate CommunitiesSeptember 24
-
Dawn Foster of Fast Wonder Consulting recently posted a really useful, practical discussion of different types of structures for corporate communities. She puts corporate communities into three categories: emergent, highly structured, and adaptive.
- Emergent Approach: Community has little or no structure at launch, and a structure emerges over time
- Highly Structured Approach: Communities have a detailed, thought-through taxonomy at time of launch
- Adaptive Approach: The community launches with a few very broad categories, from which structure emerges and develops over time
Dawn advocates the Adaptive approach in most cases as being the most flexible and easiest to implement. I wholeheartedly agree, and will chime in with a few supporting observations.
I've seen plenty of examples of communities that launched with a high degree of structure. Many of them worked...after a fashion. But these "communities" usually are really publishing tools where a few people post things and everyone else consumes. (I've seen this a lot in professional services firms, which tend to have large knowledge management or practice staffs whose very job it is to post industry updates, pitch packs, methodologies, etc.) This isn't necessarily a bad use of the tools; many companies are much happier on a collaboration platform than on a larger, more expensive, and le
- In-the-Flow with Acumen FundSeptember 23
-
I blog a lot about the importance of in-the-flow collaboration: the idea that organizations adopt collaborative tools only when those tools are integrated into the flow of daily work. That idea resonates with a lot of readers, but so far I haven't said very much about how to do it.
The other day, I saw a really great example of an in-the-flow collaborative tool at Acumen Fund. When project champions Brian Trelstad and Rob KatzĀ set out to implement a knowledge management system, they quickly realized that the organization already had all sorts of processes and mechanisms for capturing knowledge and ideas. The question was how to tap into those resources in a way that would create transparency, access, and reuse across the organization's four locations in Hyderabad, Karachi, Nairobi, and New York.
Brian and Rob came up with some really great techniques to redirect Acumen's flow of work through the collaborative workspace:
- "Instead of email": Acumen already had a culture of sending company-wide emails containing interesting articles and thoughts and triggering discussion threads. But those threads were lost in everyone's in-boxes and archives. So Brian and Rob created a button called "Instead of Email" and then approached Acumen's top emailers to use Instead of Email instead of email. Acumen even created a set of email aliases that allow users to send emails to Instead of email. (The language gets a little count
