One of the benefits of being an academic is the ability to attend seminars that seem to have nothing to do with your own work.  A while back I heard John Gourville, a colleague in HBS’s Marketing department, talk about his research investigating why so many new consumer products fail to catch on with their intended audiences despite the clear advantages they offer over what’s currently on the market.  

His explanation was fascinating, and very insightful.  He said that we need to stop thinking about consumers as highly rational evaluators of the old vs. the new products, lining up pros and cons of each in mental tables and then selecting the winner.  Instead, we need to keep in mind three well-documented features of our cognitive ‘equipment’ for making evaluations.  

• We make relative evaluations, not absolute ones.  When I’m at a poker table deciding whether to call a bet, I don’t think of what my total net worth will be if I win the hand vs. if I lose it.  Instead, I think in relative terms —  whether I’ll be ‘up’ or ‘down.’

• Our reference point is the status quo.  My poker table comparisons are made with respect to where I am at that point in time.  "If I win this hand I’ll be up $40; if I lose it I’ll be down $10 compared to my current bankroll."  It’s only at the end of the night that my horizon broadens enough to see if I’m up or down for the whole game. 

• We are loss averse.  A $50 loss looms larger than a $50 gain.  Loss aversion is virtually universal across people and contexts, and is not much affected by how much wealth one already has.  Ample research has demonstrated that people find that a prospective loss of $x is about two to three times as painful as a prospective gain of $x is pleasurable.  

When combined, these three lead to what the behavioral economist Richard Thaler has called the "endowment effect:"  We value items in our possession more than prospective items that could be in our possession, especially if the prospective item is a proposed substitute.  We mentally compare having the prospective item to giving up what we already have (our ‘endowment’), but because we’re loss averse giving up what we already have (our reference point) looms large.  

And Gourville points out three factors that make the situation worse for product developers who want their offerings to succeed.  First is timing:  adopters have to give up their endowment immediately, and only get benefits sometime in the future.  Second, these benefits are not certain; the new product might not work as promised.  Third, benefits are usually qualitative, making them difficult to enumerate and compare.

As if all this weren’t enough, Gourville also highlights that the people developing new products are very dissimilar from the products’ prospective consumers.  You don’t go work for TiVo (to use his example) if you don’t ‘get’ the potential of digital video recorders and think they’re a really good idea.  And after working for the company for a while, having TiVo becomes part of your endowment; you think of things in comparison to TiVo, instead of in comparison to a VCR.  Both of these factors make it harder for developers to see things as their target customers do.  

Because of all of the above, Gourville talks about the ‘9X problem’ —  "a mismatch of 9 to 1 between what innovators think consumers want and what consumers actually want."¹  The 9X problem goes a long way to explaining the tech industry folk wisdom that to spread like wildfire a new product has to offer a tenfold improvement over  what’s currently out there.² 

After I was done talking about the glories of Enterprise 2.0 at the New New Internet conference, one of the attendees asked how I could be confident that the new generation of collaboration technologies was going to succeed to a greater extent than had the previous generation of ‘groupware,’ the most popular version of which was probably Lotus Notes.  I answered that groupware actually imposed a surprising amount of structure on people’s interactions, and that because Enterprise 2.0 technologies let structure emerge, rather than imposing it, they would be more popular.  

Gourville, I think, would have given a different, less optimistic, and more helpful answer.  He probably would  have said that acceptance of a new piece of technology among people who are free to use it or not is very much  like consumer acceptance of any other new product.  And therefore the endowment effect applies.

Email is virtually everyone’s current endowment of collaboration software.  Gourville’s research suggests that the average person will underweight the prospective benefits of a replacement technology for it by about a factor of three, and overweight by the same factor everything they’re being asked to give up by not using email.   This is the 9X problem developers of new collaboration technologies will have to overcome.  

In most companies, groupware didn’t solve the problem; it wasn’t that much better than email.  The current generation of Enterprise 2.0 tools that I and other have been writing about is clearly different than groupware, and we believe it offers advantages.  But that’s not really the critical consideration.  The critical consideration is brutally simple:  are these tools 9 times better than email for collaboration?

Consider how high this sets the bar.  Email is freeform, multimedia (especially with attachments), WYSIWYG, easy to learn and use, platform independent, social, and friendly to  mouse-clickers and keyboard-shortcutters alike.  It’s the ultimate example of what Dion Hinchcliffe calls a ‘comfort app‘ (a phrase I love, and plan to steal (with attribution) shamelessly).  It would actually be a pretty tough competitor even if it weren’t the universally-used incumbent, and so the beneficiary of the 9X problem.  In short, it’s not going anywhere.

So as we Enterprise 2.0 enthusiasts keep talking about the benefits and new capabilities offered by the new tools, we had better hope that the innovators who are actually developing these technologies are aware of the 9X problem posed by email, and are working on ways to deal with it.

There are, it seems, two broad strategies.  Enterprise 2.0 technologists can try to increase the perceived benefits of their technologies (in other words, what the user feels she’s getting), or lower their perceived costs and drawbacks (what the user feels she’ll be giving up).  Demos and training are part of the former strategy, but they feel like weak measures.  Stronger ones are a clear explanation of what the technology does, network effects, peer pressure, word of mouth, and an extremely effective user interface and layout.  

Of the items on this list, I have the most faith in the final one.  The other items might bring users to the technology, but the UI is going to determine what they do once they get there — whether they’ll spend time exploring and learning, or leave quickly.  I really didn’t know what del.icio.us was or how it worked when I first went to the site, but once I went there I was sucked in; I wanted to learn more, and found it easy to do so.  

I’m not a usability expert at all, so I’m not even going to try to set out guidelines for a great Enterprise 2.0 UI.  I just want to point out the sharp difference between the look and feel of most corporate technologies, and most Web 2.0 ones.  My favorite Web 2.0 sites are elegant, uncluttered, and bright; they have a jewel-like quality to them.  I can’t really say the same about most of the corporate systems I’ve seen and used.    

A great UI not only heightens the perceived benefits of a proposed collaboration technology, it also lowers the perceived costs.  An intuitive interface lets users quickly say to themselves "Oh, I understand.  This isn’t hard at all.  In fact, it’s about as easy as email."

The greatest challenge here, I think, doesn’t have to do with making the browser sufficiently application-like (AJAX is a pretty powerful set of technologies).  It has to do with making technologists sufficiently user-like —  getting them to stop thinking in terms of bells and whistles and elaborate functionality, and to start thinking instead about busy users with short attention spans who need to get something done, and who can always reach for email.  From what I’ve seen (and learned from Gourville) this isn’t easy, but it is critically important.

I want to end this post on an optimistic note, so let’s concentrate on the biggest advantage Enterprise 2.0 technologies have over email. As I wrote in my initial SMR article, email is a channel technology.  It creates a private conduit between the sender and receiver.  Other parties don’t know that the email was sent, and can’t consult its contents.   Wikis, del.icio.us, Flickr, Myspace, Facebook, and YouTube, on the other hand, are all platform technologies.  They accumulate content over time and make it visible and accessible to all community members.  

Prior to the arrival of Enterprise 2.0 technologies, companies had few effective platforms for sharing knowledge work, and no platforms that fostered emergence.  So the new tools are not direct substitutes for email; instead, they’re intended to provide capabilities that email can’t.  Will they succeed?  It depends  heavily, I believe, on whether companies and their managers want technology platforms for collaboration.  This desire will be an important factor in solving email’s 9X problem. 

¹Gourville, J. T. (2004). "Why consumers don’t buy: The psychology of new product adoption." Harvard Business School Note #504-056

²Andy Grove, "Churning things up"  Fortune, July 21, 2003

At Wednesday’s New New Internet conference Google’s Rajen Sheth gave a great talk.  As part of it, he drew a distinction between application deployment within the enterprise and on the Web.

I think he was being kind to the enterprise model when he described it as managers and technologists trying to figure out what users within the company want, then trying to deliver it to them.  He got the three constituencies right, but soft-pedaled the real goal of most enterprise IT efforts.  

They’re not about the users, even though they’re often positioned and discussed that way. They’re about the enterprise —  what’s best for the organization as a whole, what will make it more productive, efficient, analyzable, etc.  

There’s no guarantee that what’s best for the enterprise will be best for all or most enterprise IT users.  In fact, there’s a near guarantee that some people and groups will be worse off after a new enterprise system (ERP, CRM, eProcurement, SCM, etc.) goes in.  They’ll get an application that’s by definition less tailored to their specific needs than the legacy stovepipe system that’s being replaced.  They’ll have to learn new screens, transactions, and processes, some of which are going to be less friendly or efficient than the previous ones.  They’ll have to go through lots of training that takes them away from their jobs.  And at the end of the day they’ll be encouraged (read ‘forced’) to use an enterprise application that gives them  fewer places to hide and less freedom.

I want to stress yet again that  this is not a bad or unintelligent thing for companies to do.  The work redesign, standardization, and monitoring capabilities provided by Enterprise IT are powerful and in many cases vital.  But acquiring them entails a particular arrangement among managers, technologists, and  users.  To put it bluntly, managers negotiate with each other about how the system will work, collaborate with technologists to configure it, then deploy this system regardless of whether or not users want it, or like it.

This sounds like a heartless process, and one that no self-respecting modern day business school professor could advocate, but I actually think it’s the right idea a lot of the time.  Companies are simply not going to get 100% consensus or up-front ‘buy-in’ from all  parties affected by a new enterprise system, so trying for it is a waste of time and effort, and can actually be counterproductive.  A 1994 study concluded that “… a culture of consensus decision making at the top of the organization can delay [business process] reengineering efforts and even make completing them impossible.”¹  So a fairly heavy-handed, top-down adoption process driven by management is often the smart approach.

On the Web, of course, this approach is completely infeasible.  There are no managers, for one thing, and there are no mandatory sites or tools.  As people from Google are fond of saying, "the competition is always only one click away."  So in this environment technologists have had to operate very differently if they want their offerings to be adopted by users.  They’ve had to make them incredibly easy to understand and use, because our tolerance for unfriendly technologies and sites is very low.  Web technologists have also often started by introducing a tool that did only one thing, but they made sure that it was an important or valuable thing and that the tool did it very well.  Once users were both hooked and educated the tool could incorporate other features, as long as they were also easy to use.  Del.icio.us and Google are  two good examples of sites that have become gradually and seamlessly more complex.  And as I’ve written here before, the technologists of Web 2.0 have often tried hard to get out of users’ ways, to stop imposing structure on them and instead give them tools that let structure emerge.

So so far within enterprises we’ve seen managers and technologists imposing technologies on users, and on the Web we’ve seen technologists offering technologies to users, with only the best surviving and not a manager in sight.  

And now, with enterprise 2.0, we’re starting to see something new.  The easy, intuitive, and powerful Web 2.0 technologies — like blogs, wikis, tags, RSS feeds and aggregators that attract users and foster emergence — are starting to spread behind the firewall.  Sometimes this is happening by stealth and sometimes it’s happening with the explicit approval of line executives and CIOs, but what’s really interesting is that in every case it’s happening in an environment where there’s a third constituency —  managers —  in addition to the normal duo of technologists and users.  

How will this play out?  As I said in my talks at both the New New Internet and Interop, it’s simply too soon to tell.  The appropriate choreography among managers, technologists, and users for deploying big enterprise systems is pretty well understood (it’s hard, but the steps are clear).  The choreography between technologists and users on the Web has also been rehearsed enough times that it’s starting to fall into place.  But when managers are added to Web 2.0 tool deployment, transforming it into Enterprise 2.0, no one knows exactly what to do yet.

I’m pretty sure that proceeding as if managers aren’t there at all is a bad idea.  They can help encourage adoption, for one thing, and they’ll also likely be hostile if they get blindsided by these technologies, so they need to be in the loop.  But it also seems clear that it would be fruitless and silly for managers to try to deploy these technologies the same way they’re used to rolling out ERP.

The research I’ve done and the discussions I’ve had with Enterprise 2.0 pioneers has convinced me that line managers have a large role to play in deployment.  I’ve seen and heard too many examples of successful managerial intervention, and seen and heard too many instances of Enterprise 2.0 deployments that failed because they never got the ‘activation energy’ they needed, and so just faded away.  I don’t see how managers can effectively dictate blogging, tagging, wiki editing, etc., but I can easily see how they can encourage these kinds of activities within their teams, and provide good coaching.  In short, there’s definitely a role for managers in the new choreography of Enterprise 2.0 deployment; we know they’re not center stage all the time, but they’re definitely part of the ensemble.

Another highlight of the New New Internet conference for me was listening Michael Arrington of TechCrunch.  He made some fascinating points about how much cheaper, easier, and faster it is to get an industrial strength site up and running today, compared to only a couple years ago.  He said that TechCrunch will soon have an enterprise section (or separate site).  I’m planning to read it faithfully.

And thanks to Dion Hinchcliffe for putting together a great conference.

¹Bashein, B. J., M. L. Markus and P. Riley 1994. Preconditions for bpr success and how to prevent failures. Information Systems Management 11(2): 7-13.

I’ll be giving an opening keynote address at the Office 2.0 conference in San Francisco on October 11.  This looks to be a great event; I’m looking forward to listening to the panel discussions and meeting people who to date I know only from their blogs.   I think it’s filling up quickly, so register if you’re interested and please do introduce yourself; it would be great to meet more people who think that the emergent enterprise could be important.

Wikipedia is facing a showdown, and it looks like it could be an important one, between contributors who think it should be a repository for all sorts of information ("Why shouldn’t my middle school have an entry?" ) and those who believe it should it should keep out content that’s not notable ("Why should your middle school have an entry?" ). The former call themselves inclusionists, the latter deletionists.
As the Enterprise 2.0 meme gains currency, a similar tension is appearing. Some are using it as a catch-all phrase that encompasses several converging trends within the enterprise software industry. Others are advocating a narrow definition that focuses only on the use of a new generation of digital collaboration tools within organizations.

I find that I’m a Wikipedia inclusionist and an Enterprise 2.0 deletionist, for the simple reason that an encyclopedia gets more useful the bigger, broader, and more all-encompassing it is, while a definition gets less useful. I think that if "Enterprise 2.0" becomes "All the changes in the enterprise software market that I (whoever I am) think are noteworthy" or "All the changes in the enterprise software market that you (whoever you are) need to be aware of" than the term itself loses most of its explanatory power and risks descending to the level of marketing hype.

So while I’m happy to see MR Rangaswami at Sandhill.com get excited about Enterprise 2.0, I was less happy to read his definition:

"Enterprise 2.0 is the synergy of a new set of technologies, development models and delivery methods that are used to develop business software and deliver it to users.

Whether created by software vendors, internal IT departments, line-of-business units or service providers, the software of Enterprise 2.0 will be flexible, simple and lightweight. It will be created using an infinite combination of the latest – and possibly, some old-fashioned – ingredients, including the following:

• Technologies – Open source, SOA/Web services (AJAX, RSS, blogs, wikis, tagging, social networking, and so on) Web 2.0, legacy and proprietary – or some combination
• Development Models – Relying on in-house, outsourced or offshore resources – or any combination; pursuing a global development strategy; and/or pursuing co-creation with users, partners or both
• Delivery Methods -Downloading individually; paying for a license; and/or, using on-demand/SaaS or via a service provider." (Vinnie Mirchandani concentrates on delivery methods in his recent piece on Enterprise 2.0)

By this definition, a company’s new travel and expense reporting system would qualify as an Enterprise 2.0 application if it were developed in Chennai, rented to customers, and accessed via an AJAX-capable browser. This T&E system could be mandatory use, assign users to roles (submitter, approver, auditor, etc.), check to make sure all fields were present, and pre-define ironclad approval and reimbursement workflows, and still be considered an Enterprise 2.0 application.

This is pretty close to the opposite of the definition of Enterprise 2.0 I proposed a while back:

"Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.

Social software enables people to rendezvous, connect or collaborate through computer-mediated communication and to form online communities. (Wikipedia’s definition).

Platforms are digital environments in which contributions and interactions are globally visible and persistent over time.

Emergent means that the software is freeform, and that it contains mechanisms to let the patterns and structure inherent in people’s interactions become visible over time.

Freeform means that the software is most or all of the following:

• Optional
• Free of up-front workflow
• Egalitarian, or indifferent to formal organizational identities
• Accepting of many types of data"

(This is a definition of a noun. When I use ‘Enterprise 2.0′ as an adjective, I mean "supporting of emergent collaboration." )

This definition is explicitly NOT about development models or delivery methods, and it’s only about a small set of technologies that are visible to end users. Tags, for example, are visible to end users; Service-oriented architectures are not.

Ray Lane and Rod Boothby have been working with an appropriately narrow definition of Enterprise 2.0, and are doing a great job of articulating its impact. Dion Hinchcliffe has taken one of Rod’s graphics and extended it a bit. The points it communicates are all about changes to collaboration, not to development or delivery models.

Enterprise 2.0, as these folk and I define it, is a trend that we think should be on the radar screens of non-technologist business leaders. Talking about development models and delivery methods is a good way to ensure that it doesn’t get there, or doesn’t stay there long.  Business leaders’ eyes will glaze over, or they’ll quickly mentally file the topic as ’something for my tech team to worry about.’

Of course, there are many other possible audiences for insight and analysis about technology trends: CIOs, CTOs, IT managers, entrepreneurs, investors, etc. Lots of these groups are interested in development models and delivery methods, even if line managers generally aren’t. But we already have terms to describe recent developments in these areas, many of which can be found in Rangaswami’s definition above. So why stretch ‘Enterprise 2.0′ to encompass all of them?

Maybe we do need a new phrase or term to describe the confluence of recent developments in technologies themselves, their development, and their delivery.  But let’s not just Shanghai a pre-existing term that was doing useful work and force it into a whole new set of duties.

And one piece of free advice:  Don’t use ‘2.0′ as part of any new term; people seem to be getting tired of it very quickly.

Optimize Magazine just posted the discussion that editor Paula Klein had with me and JP Rangaswami, who as CIO of investment bank DrKW deployed the closest thing I’ve seen to a company-wide Enterprise 2.0 infrastructure.

What I didn’t know is that Optimize asked Tom Davenport to respond to the discussion.  And instead of agreeing with us wholeheartedly (JP and I were doing enough of that with each other), Tom provides counterpoints to our points.

Like everyone else who works at the intersection of IT and business and wants to do so intelligently, I’ve been reading Tom’s work for years.  He is both prolific and insightful, and has a wonderful ability to explain new developments in technology and communicate their importance without ever becoming a hype merchant.  He also has a great deal of experience and perspective, and so is ideally positioned to place allegedly novel technologies and trends in context, to separate the wheat from the chaff, and to see when old wine is being put in new bottles.  I referenced Tom’s work pretty heavily in my original Enterprise 2.0 article.

So it was with no small dread that I read early in Tom’s article:

"I believe these social media have their place, but they’re not revolutionary or even worthy of a new name. They won’t put any previous technology out of business or wipe out organizational hierarchy. They’ll live largely on the margins of organizations because they don’t fit their mainstream needs."  

In questioning the importance of Enterprise 2.0 technologies, he concentrates on blogs and wikis.

Blogs
Tom says that despite blogs’ positive aspects, "they have a tragic flaw: No one has the time to read them."  As a result, they should be used sparingly.  "If you’ve got some experts or highly authoritative individuals and you want to get their opinions more broadly distributed, blogs can be just the ticket. But make sure you don’t clutter up the internal blogosphere by empowering too many of them."

When I look at my own blog consumption, I see Tom’s point.  I faithfully read exactly one blog, and it’s got nothing to do with my job.  But I drop in for a quick visit on probably more than a score of different IT and business blogs each week, and a different set every week.  This opportunistic cherry-picking is guided by Google, Google blog search, Technorati, del.icio.us, and comments and trackbacks I get on my own blog.  The blogosphere is both navigable and extraordinarily useful to me; I treat it more like a newspaper I assemble myself as needed, rather than a set of so many books-in-progress that I could never keep up with them all.  

There may be downsides to empowerment, but cluttering of the internal corporate blogosphere isn’t one of them if decent search capability exists on the Intranet.  As I wrote in my article, linking and tagging help develop this capability, and Google and others are happy to sell a company a search appliance.  Tom says my HBS blog is not easy to find (and I really should update my official faculty information page to link to it) but I just typed "Andrew McAfee blog", "Andrew McAfee Harvard blog", "Andrew McAfee HBS blog", and  "Andrew McAfee Enterprise 2.0" into Google, and in every case my blog was returned as the first result.  With "Andrew McAfee" it was second.   I’m not sure how to make it much easier to find.

Wikis
Tom seems wary of wikis’ egalitarian and non-credentialist natures.  As he writes:

"With Wikipedia, I always have a nagging doubt about who contributed the knowledge and what their agendas might be…  I once asked a group of MBA students to come up with a knowledge-management strategy for NASA. They argued that the centerpiece of the strategy should be a set of wikis about each knowledge domain. But if I’m an astronaut being fired into space, can I afford to trust the democratic process? I’ll want the best knowledge from the best experts to be used in guiding my launch."

Of course NASA wouldn’t design a manned rocket’s heat shield based solely on the NASAwiki’s content and then fire that rocket into space without first testing it.  But would a NASAwiki be a good place to discuss the design of the heat shield, the appropriate next set of tests, etc.?  Would it be a waste of experts’ time to have their views subject to scrutiny on the wiki, or would it be a good idea?

And, is NASA really the best example to bring up in support of traditional knowledge management approaches?  We’ve lost two space shuttles, so something about knowledge flows within NASA’s pretty clearly isn’t working well.  As Edward Tufte, the Rogers commission, and others have convincingly showed, the Challenger disaster was due in part to the fact that people who understood the tight and dangerous relationship between low launch temperatures and o-ring failures couldn’t get this knowledge the visibility it deserved.  It sounds like a more egalitarian, evidence- and logic-based process for sharing information and discussing risks might be exactly what NASA needs.  

Nitpicking
A couple of minor points.  There’s a danger in confining our discussion of Enterprise 2.0 technologies to blogs and wikis.  I imagine Tom considered only these two because of space considerations, but I’ve noticed elsewhere a tendency to equate Enterprise 2.0 with corporate blog + wiki use.  This viewpoint is far too narrow.  The phenomena, and the supporting technologies, of initially freeform and eventually emergent collaboration are rich and varied; let’s try to make sure we’re not leaving any of the important ones out.

Also, I need to offer Tom one gentle correction.  He writes that "McAfee argues that these tools are bringing about a participatory revolution."  I’ve actually consciously avoided using the word ‘revolution’ in any of my writing on this topic; I just checked through my blog and original article, and I’m pretty sure that it never appears.  In addition to the fact that ‘revolution’ is one of the favorite words of technology vendors and hype merchants, which is reason enough not to use it, it’s also not the right word.  Revolutions are precipitate, traumatic, quick, and unignorable; I haven’t seen evidence that Enterprise 2.0 is any of these.

Tom finishes by observing that "We can wish that power and capability were more evenly distributed, but a set of technologies isn’t going to make it so."  Certainly not, but the combination of new technologies and dedicated individuals has already led to some interesting power shifts.  It’s probably fair to say that both Trent Lott and Dan Rather lost their jobs in large part because of bloggers.  The venerable Encyclopedia Britannica has seen its position of factual authority challenged by Wikipedia.

Within the enterprise, there’s a third critical constituency in addition to technology and individuals:  management.  But it’s far too simplistic to treat ‘management’ as a undifferentiated group that either wants to radically empower employees or suppress their views and keep them locked in the existing hierarchy.  Different managers, even those within the same company, can have very different views, and can embrace Enterprise 2.0 or try to ward it off.  

Consider the example of a change in corporate ownership.  One of the dominant trends in the worlds of venture capital and private equity at present is assuming a controlling interest in underperforming companies, whether public or private, then ‘fixing’ them via fairly forceful managerial intervention.  The assumption underlying these deals is that existing management is failing to maximize value, or perhaps even destroying it.  

In these situations, there are three safe bets.  First, that knowledge about the recently acquired company’s biggest problems and missed opportunities exists throughout the workforce —  someone knows where the bodies, and the gold, are buried.  Second, that some of the people who know these things want to tell the new bosses about them, whether to advance their careers, settle scores, keep afloat a company they care about, etc.  Third, that some others want very much to keep the new bosses in the dark, and to keep some kinds of knowledge from flowing freely.  

Given all this, one of the first things I’d do after I acquired such a company is widely deploy a suite of Enterprise 2.0 technologies, perhaps an option for pseudonymity.  I’d also communicate clearly that using the new tools would not put an employee’s job at risk; since I’m the new boss, this is a credible commitment.  In other words, I’d work pretty hard to use technology to shift power.

Tom is spot on to stress that organizations are still hierarchical places, and will continue to be.  For me, the interesting question posed by Enterprise 2.0 is how hierarchies will shape, and be shaped by, the new tools now available.  I’m not as sure as he is that power and capabilities are not going to be somewhat redistributed.  As Victor Hugo said, "One can resist the invasion of an army but one cannot resist the invasion of ideas."

These days, when I want to procrastinate yet still convince myself that I’m accomplishing something useful I have many options beyond the classic of reading email.  I peruse  my Wikipedia and Technorati watchlists.  I do Google blog searches on phrases like "Enterprise 2.0."  I read new posts from the blogs and websites I’m interested in.  I approve new comments and follow new trackbacks to my own blog.  I use Google scholar and HBS’s internal tools to find out if any new papers have been published with the keywords "IT" and "competition."  I check pre-enrollment  for my spring MBA course.  I check to see if any colleagues have added new materials to the various project wikis we’ve set up. 

None of these consist of finding new things to be interested in.  Instead, they’re all about staying on top of things I already know I’m interested in.  And they’re all related to my job; these procrastinations don’t include things like checking the AL East standings (not that we Bostonians are doing that a lot these days).  

I learn about some of the changes-to-things-I’m-interested-in via RSS feeds.  Others come to me via email.  For still others like my Wikipedia watchlist  I have to open up a Web page (Am I missing something?  Is there a way to get WP watchlist updates via RSS or email?).  And for some, I have to open a web page and type in a few terms.  

I was happily doing all this until a team from KnowNow visited my office earlier this week and made me realize how silly it was.  KnowNow concentrates on Signals, the final of the six Enterprise 2.0 technology components described in my Sloan Management Review article and summarized by the acronym SLATES (the others are Search, Links, Authoring, Tags, and Extensions).  Signals are alerts to a knowledge worker that something of interest in her online universe has occurred.

In the article I concentrated on RSS as the enabling technology for signals, but there are clearly others (and as Nick Carr pointed out recently RSS is far from a monolithic technology).  KnowNow’s value proposition, as I understood it, is that they are agnostic about how signals are generated and how they’re communicated to the end user.   Their insight (which escaped me as I was setting up my RSS feeds) is that these details are completely irrelevant to the knowledge worker, who just wants to know when something happened, and what it was.

The signal could have been generated by a blogger putting up a post, a competitor putting out a press release about landing a new customer, a share price rising above a certain level, an inventory level falling to zero, or an HR department that wanted to let people know about new hires.  Some of these signals are generated by humans, others by applications. Some are formatted for transmission by RSS, some by email, and some are not explicitly prepared for transmission at all.  And it bears repeating:  none of these details are important, or even relevant, to the end user.  She just wants to get these signals as quickly and conveniently as possible.

That’s getting harder and harder these days, for a few reasons.  First, the amount of online content continues to explode.  The number of ways to send a signal is also proliferating.  Finally, what is the trusted, robust, enterprise-approved, guaranteed-to-succeed way to transmit a signal to employees these days?

It’s not email.  The KnowNow team told me about a large client of theirs where the CEO had no way to confidently send an email to all employees; some people’s spam filters, he knew, would not let it through.  I laughed, and then realized that HBS’s weekly ‘new faculty research publications‘ email winds up in my junk folder, and I haven’t yet been able to train Thunderbird to treat it better.  

So I think KnowNow’s on to something.¹  They talk about a back-end architecture for (for lack of a better term) signals processing —  scanning, collecting, formatting, etc. — and something like a widget that aggregates all these signals and displays them on users’ screens.

As with most things Enterprise 2.0, my crystal ball is very cloudy when I ask it about the future of signals within behind the firewall, but I can discern two important issues.  The first is the user interface —  the design of the widget.  It’ll be very easy to drown in signals, and the race here might go to the team that figures out how to present users’ signals of interest so that interpreting them doesn’t feel like drinking from a firehose, or reading an endless list of headlines.  

The second is the balance between enterprise-selected and user-selected signals.  The CEO mentioned above doesn’t want his employees to have discretion over whether or not to receive his company-wide emails.  In other words, he wants some portion of the widget reserved for enterprise-selected signals —  ones that management wants to send with 0% chance of loss or distortion.  But users also want to be able to configure their widgets to receive the signals they’re interested in.  That kind of autonomy is fundamental to Enterprise 2.0, and will help ensure that the signal widget isn’t ignored or minimized by users.

Leave a comment and tell us what you think —  is your ability to receive signals impaired at present? How valuable would a good signaling infrastructure be within your organization?

¹I have no financial interest in KnowNow and have received no money, products, or services from the company.