Yesterday morning I had the chance to fire a potato into a forest using a rocket launcher.
A first for me and found it to be a strangely gratifying experience.
The spud gun is capable of shooting a potato 200+ yards. Courtesy of Make Magazine's Bre Pettis who was at Seattle Mind Camp 3.0.
Below is Bre preparing the gun with hair spray.
Google's Peter Wilson is to his left, an engeering director at their Kirkland office, who appears to be considering how he might search for his foot after he's blown it off with a potato cannon.
Andrew McAfee, an associate professor at the Harvard Business School has identified a user segment within organizations that he describes as the 'Empty Quarter'. The context is within the types of users who become the early adopters of Enterprise 2.0' applications (or social media behind-the-firewall). In McAafee's experience, there are two types of early adopters of these types of technologies: Newbies and Techies:
"'Newbies' here means new entrants to the workforce; as I wrote earlier, recent graduates find it natural to socialize, collaborate, and find what they're looking for via technology platforms (think of MySpace, Facebook, Flickr, Wikipedia, LastFM, del.icio.us, etc.). In addition to point, click, drag, and drop, their baseline computer skills include search, link, tag, and post.
'Techies' are IT staffers, and also those people scattered throughout the rest of the company who are the natural early adopters and advanced users of whatever technologies are available.
...If these observations are accurate, then a graph with technophobia on one axis and years since graduation on the other reveals who's more and less likely to use Enterprise 2.0 tools if they're made available:
The 'empty quarter' of non-adopters is the upper right-hand section of this graph. These are the folk who are relatively unlikely to pick up new tools and run with them."
McAfee goes on to argue that encouraging the Empty Quarter to participate in the production of social media within the Enterprise will benefit the company as a whole, since a great deal of the knowledge produced by this segment is where the institutional knowledge and corporate memory really resides. He goes on to propose ideas around how these users can be encouraged, including focus on the development of the tools themselves (e.g. make it more useable) and policies that might be introduced:
- "Maintain a blog for your group / department. Identify who's in charge of it, and update it at least once a week.
- Maintain a blog for each project your lab is working on. Post whatever non-confidential information you'd like your colleagues to know about each one.
- Keep your personal page up to date. Make sure it lists your areas and industries of expertise.
- Use the wiki to make sure your portion of the org chart is up to date."
I agree with McAfee that in order to get the Empty Quarter to adopt the use of social applications it will require both the combination of good technology and efforts around cultural change. Since he's asking for others to share their experience around what has (and presumably hasn't) worked, here are my thoughts and observations on the topic:
the Del.icio.us Lesson
This one is more to do with the technology design, rather than efforts to socially engineer adoption. The idea is called The Del.icio.us Lesson - a key social software design principle. To summarize Joshua Porter's post (who originally coined the term):
"The one major idea behind the Del.icio.us Lesson is that personal value precedes network value. What this means is that if we are to build networks of value, then each person on the network needs to find value for themselves before they can contribute value to the network. In the case of Del.icio.us, people find value saving their personal bookmarks first and foremost. All other usage is secondary."
Creators, Synthesizers, and Consumers
Bradley Horowitz of Yahoo made the observation that social software sites don’t require 100% active participation to generate great value. He used a data point relating to Wikipedia to illustrate the point: half of all edits are made by just 2.5% of all users. Horowitz formalized this idea with the following chart::
"As Yahoo! has been gobbling up many social media sites over the past year (Flickr, upcoming, del.icio.us) I often get asked about how (or whether) we believe these communities will scale.
The question led me to draw the following pyramid on a nearby whiteboard:
The levels in the pyramid represent phases of value creation. As an example take Yahoo! Groups.
- 1% of the user population might start a group (or a thread within a group)
- 10% of the user population might participate actively, and actually author content whether starting a thread or responding to a thread-in-progress
- 100% of the user population benefits from the activities of the above groups (lurkers)
There are a couple of interesting points worth noting. The first is that we don’t need to convert 100% of the audience into “active” participants to have a thriving product that benefits tens of millions of users. In fact, there are many reasons why you wouldn’t want to do this. The hurdles that users cross as they transition from lurkers to synthesizers to creators are also filters that can eliminate noise from signal. Another point is that the levels of the pyramid are containing - the creators are also consumers."
Of course, 'value creation' for a media company such as Yahoo means content that attracts eyeballs, that begets participation, that begets content, that begets further eyeballs and so on. However, I think it would be unwise to then dismiss the general 'natural law' observation around how social media is created, synthesized and consumed as irrelevant in the Enterprise 2.0 context (especially since the observation is provided by someone with a great deal of experimental experience on large scales).
In the context of behind the firewall social media, maybe the key to getting more users to participate is to accept that you can't get everyone to become a content creator. The implication being that one should therefore design efforts to encourage the Empty Quarter with this in mind, and recognize that the role of Synthesizing is just as critical a role in the Enterprise 2.0 space as the the role of creation.
David Winer's view - Don't Bother to Change the Culture
Last year Dave Winer attended a session at Seattle Mind Camp 2.0 that I ran with Michael Blay, Geoff Froh on the topic of behind-the-firewall tagging.
"Dave Winer attended and described the session as a 'intense lightning-fast discussion'. However, he came to the early conclusion as part of that discussion that there was no conclusion - that is a waste of time to try and encourage employees to adopt a tagging culture to share knowledge inside corporate firewall. That users either get it or they don't. You can't force them."
At this post, Dave explained the reasoning behind this view:
"I promised I'd explain once and for all why it's hopeless to "try to get the users" to use social bookmarking software unless they're already using it. Here's why: I don't know. But I do know it never works. It's so bad that when I try to solve the problem (I'm a geek, so I fall into this trap myself, can't help it), I hack at making it easy and painless, figuring it's a user interface problem (if you're a geek you're nodding your head right now, right?) but when I make it so easy anyone would have to do it, not only doesn't anyone else do it, I don't even do it myself! Why? As I said, I don't know! Makes no sense to me at all. But there you are.
I do know that Dan Bricklin posed something like a law to explain the phenomenon, as best as a geek possibly can. Software that rewards you for doing something one percent of the time will get used (email, word processing, SimCity) and software that punishes you for doing it only 99 percent of the time will not get used (calendars, PIMs, categorizing stuff, social bookmarks). The genius of del.icio.us is that it falls into the former category, even though it appears at first to fall into the latter.
Never say Bricklin isn't a smart dude, if you remember his rule, you'll avoid hours of interesting discussions about how important it is to do something that is impossible to do."
I agree and I disagree with Winer.
I agree that if the software is useful for the individual using it, they'll use it (back to the Del.icio.us Lesson). What that says to me then, is that if the software is designed right it can succeed - if not, they won't. I got that.
But then he argues that social bookmarking 'punishes you for doing it only 99 percent of the time': i.e. if you don't always use social bookmarking then 'it' loses it's value. Here I disagree, as that has not been my personal experience. The tagging I do comes and goes in terms of how regularly and how disciplined I am in my tagging stuff. Somedays I just don't tag stuff, somedays I do. When I don't tag stuff for a few days, it doesn't mean that the value of those things I have already tagged diminishes. Those artifacts are still there. Of course, sometimes I wish I had tagged things that I didn't, but that doesn't brake the overall system. It just means it could be better.
So I'm not sure if I fully understand Winer's point here. That said, I do agree with his experience that that some people just will never 'get it'. But I don't think that should mean you shouldn't try.
Culture change can and does work if done right - I know, I've done it within Microsoft. An example is that program managers, software developers and testers are now blogging in our team that weren't before I joined the team: they just needed some encouragement, see the benefits of doing so, receive some training and be provided some support. Not all of our team are blogging of course, but enough to make a significant difference in the way we communicate with customers. And the more bloggers there are, the more that decide to blog. It has also affected the way we communicate inside the firewall too - amongst ourselves within our product team but also with other teams inside of Microsoft. More to do, but the demand for internal blogs and wikis is there. The early adopters will naturally run with these tools but others will require a little more cajoling to see the benefits.
This week, while at DevConnections I attended a session on migrating from Sharepoint 2003 to Sharepoint 2007. Halfway through, the presenter (Bill English) stopped and made the point that all the technical advice he was providing was worth nothing if there wasn't also a culture change effort too: just because the software is there doesn't mean that it'll be used. Effort is required to create awareness of the benefits, training, etc...without these things, you won't succeed.
I'd write more on this but I have to go now. In the meantime, do share your thoughts on this.
I signed up for a Microsoft internal preview for employees a few weeks ago and had a play - it's amazing. Now it's your chance.
"The Photosynth Technology Preview is a taste of the newest - and, we hope, most exciting - way to view photos on a computer. Our software takes a large collection of photos of a place or an object, analyzes them for similarities, and then displays the photos in a reconstructed three-dimensional space, showing you how each one relates to the next.
In our collections, you can access gigabytes of photos in seconds, view a scene from nearly any angle, find similar photos with a single click, and zoom in to make the smallest detail as big as your monitor."
From the Photosynth team blog:
- Q. What does Photosynth do?
- A. Photosynth combines hundreds or thousands of regular digital photos of a scene to present a detailed 3D model, giving viewers the sensation of smoothly gliding around the scene from every angle. The scene can be constructed regardless of whether the photos are from a single or multiple sources. It’s like a hybrid of a slide show and a gaming experience that lets the viewer zoom in to see greater detail or zoom out for a more expansive view. By viewing the photos in a 3D context you are able to get a better sense for the place where they were captured.
If you want to see what this is all about without installing anything, check out these videos. Want to know how it's all done? Read this.
REST Web Services, a book in progress by Leonard Richardson and Sam Ruby piqued my interest yesterday. From the introduction:
"We want to restore the World Wide Web to its rightful place as a respected architecture for distributed programming. We want to shift the focus of "web service" programming from a method-based Service-Oriented Architecture that just happens to use HTTP as a transfer protocol, to a URI-based Resource-Oriented Architecture that uses the technologies of the web to their fullest."
"...a lot of people have gotten the impression that REST just means "whatever you want to do, so long as you don't use SOAP". That it's a sloppy no-methodology used to justify bad design, malformed XML, and, in particularly troublesome cases, Extreme Programming."
I've come across this perspective a few times and it is justifiable given some of the APIs I've seen described as RESTful. The intro goes on:
"To counter this, REST advocates have come up with a new term, "HTTP+POX", to describe URI-based web services that aren't RESTful. But that just brings back the arguments about what REST is and isn't. Is it like pornography, where you only know REST when you see it? Or is it like communism, where if a service fails it must not have really been REST? Can a service be somewhat RESTful, or is that like being somewhat pregnant? How many resources can dance on the head of a pin?
...We're writing a book to codify the folklore, define what's been left undefined, and try to move past the theological arguments."
My bet is that this project, the book and the concept of ROA as an effort to standardize aspects of RESTful architecture design is going to do very well, because I agree this is needed. Example provided:
- ""REST" is an abused term. Many alleged REST services (such as Flickr's, which says REST right on the website) are actually HTTP+POX: service-oriented APIs that happen to use nothing more the basic technologies of the web. Classifying services as resource-oriented or service-oriented makes it easy to see which ones are more and which less RESTful, without wasting time on minutiae."
In this post, Leonard further explains the idea behind the book:
"I got the idea for a REST book when I started seriously trying to figure out what was and wasn't REST. I noticed that though certain best practices showed up repeatedly in REST folklore, they never really progressed beyond that point. I decided to write a book that would set down the folklore and hopefully create some new canon, some common ground. I got Sam Ruby to agree to do the hard parts. And when I started work on the book I discovered a basic rule of thumb, a framing device that really focuses on what's important about REST, and makes it easy to tell what's RESTful and what's not.
We call this framing device the Resource-Oriented Architecture (we're not the first, but the other uses are compatible with ours), and I'm going to be writing about it a lot more in NYCB. It's too good to keep hidden in a book along with a bunch of implementation details."