Author: Larry Hawes (Page 1 of 3)

There have been a couple of interesting blog posts about organizational collaboration leadership penned recently by respected, influential thinkers. Last week, Morten Hansen and Scott Tapp published Who Should Be Your Chief Collaboration Officer? on the Harvard Business Review site. Yesterday, Dion Hinchcliffe posted Who should be in charge of Enterprise 2.0? on Enterprise Irregulars.

It is logical that the question of the proper seat of ownership for enterprise collaboration efforts is being raised frequently at this moment. Many organizations are starting the process of rationalizing numerous, small collaboration projects supported by enterprise social software. Those social pilots not only need to be reconciled with each other, but with legacy collaboration efforts as well. That effort requires leadership and accountability.

Both of the posts cited above – as well as the comments made on them – add valuable ideas to the debate about who should be responsible for stimulating and guiding collaboration efforts within organizations. However, both discussions miss a critical conclusion, which I will make below. First, allow me to share my thoughts on the leadership models suggested in the posts and comments.

While it is critical to have collaboration leadership articulated and demonstrated at the senior executive level, the responsibility for enterprise collaboration cannot rest on one person, especially one who is already extremely busy and most likely does not have the nurturing and coaching skills needed for the job. Besides, any function that is so widely distributed as collaboration cannot be owned by one individual; organizations proved that long ago when they unsuccessfully appointed Chief Knowledge Officers.

Governance of enterprise collaboration can (and should) be provided by a Collaboration Board. That body can offer and prescribe tools, and establish and communicate policy, as well as good practices. However, they cannot compel others in the organization to collaborate more or better. Yes, Human Resources can measure and reward collaboration efforts of individuals, but they can only dangle the carrot; I have never seen an organization punish an employee for not collaborating when they are meeting other goals and objectives that are given higher value by the organization.

There is only one person (or many, depending on your perspective) for the job of actively collaborating – YOU! Ultimately, each individual in the organization is responsible for collaboration. He can be encouraged and incented to collaborate, but the will to work with others must come from the individual.

Collaboration in the enterprise is similar in this regard to knowledge management, where the notion of Personal Knowledge Management (PKM) has been gaining acceptance. PKM advocates believe that having each member of the organization capture, share, and reuse knowledge, in ways that benefit them personally, is far more effective than corporate mandated knowledge management efforts, which generally produce benefits for the enterprise, but not the individuals of which it is comprised.

So it is with collaboration. If an individual does not see any direct benefit from working with others, they will not do so. Conversely, if every employee is empowered to collaborate and rewarded in ways that make their job easier, they will.

The Enterprise 2.0 movement has correctly emphasized the emergent nature of collaboration. Individuals must be given collaboration tools and guidance by the organization, but then must be trusted to work together to meet personal goals that roll-up into measures of organizational success. The only individual that can “own” collaboration is each of us.

LinkedIn today announced Signal, a new feature (currently in beta) that lets members see an activity stream that combines LinkedIn status updates and Twitter posts from other members who have opted-in to the feature. LinkedIn has licensed the Twitter firehose to incorporate all of its members’ tweets into the site, not just tweets with the #in hashtag embedded, as is current practice.

While it is hard to imagine anyone other than corporate and independent talent recruiters will make LinkedIn their primary Twitter client, Signal does have an element that is worthy of emulation by other social networks and enterprise social software providers that incorporate an activity stream (and which of those does not these days!) That feature is role-specific filters.

I wrote previously in this post about the importance of providing filters with which individuals can narrow their activity stream. I also noted that the key is to understand which filters are needed by which roles in an organization. LinkedIn apparently gets this, judging by the screenshot pictured below.

Notice the left-hand column, labeled “Filter by”. LinkedIn has most likely researched a sample of its members to determine which filters would be most useful to them. Given that recruiters are the most frequent users of LinkedIn, the set of filters displayed in the screenshot makes sense. They allow recruiters to see tweets and LinkedIn status updates pertaining to LinkedIn members in specific industries, companies, and geographic regions. Additionally, the Signal stream can be filtered by strength of connection in the LinkedIn network and by post date.

The activity stream of every enterprise social software suite (ESS) should offer such role-based filters, instead of the generic ones they currently employ. Typical ESS filtering parameters include individuals, groups or communities, and workspaces. Some vendors offer the ability to filter by status as a collaborator on an object, such as a specific document or sales opportunity. A few ESS providers allow individuals to create custom filters for their activity stream. While all of these filters are helpful, they do not go far enough in helping individuals narrow the activity stream to view updates needed in a specific work context.

The next logical step will be to create standard sets of role-based filters that can be further customized by the individuals using them. Just as LinkedIn has created a filter set that is useful to recruiters, ESS providers and deploying organizations must work together to create valuable filter sets for employees performing specific jobs and tasks. Doing so will result in increased productivity from, and effectiveness of, any organization’s greatest asset – it’s people.

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

“Can stand alone micro-blogging solutions survive when platform plays introduce the feature?”

I immediately replied:

“Yes, if they innovate faster”

Greg shot back:

“is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?”

And, later, he asked a complementary question:

“is there a risk of Microblogging becoming “too complicated”?”

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is “yes”, because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are  intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

What do you think?

The use of microblogging and activity streams is maturing in the enterprise. This was demonstrated by recent announcements of enhancements to those components in two well-regarded enterprise social software suites.

On February 18th, NewsGator announced a point release to its flagship Enterprise 2.0 offering, Social Sites 3.1. According to NewsGator, this release introduces the ability for individuals using Social Sites to direct specific microblogging posts and status updates to individuals, groups, and communities. Previously, all such messages were distributed to all followers of the individual poster and to the general activity stream of the organization. Social Sites 3.1 also introduced the ability for individuals to filter their activity streams using “standard and custom filters”.

Yesterday (March 3rd), Socialtext announced a major new version of its enterprise social software suite, Socialtext 4.0. Both the microblogging component of Socialtext’s suite and its stand-along microblogging appliance now allow individuals to broadcast short messages to one or more groups (as well as to the entire organization and self-selected followers.) Socialtext 4.0 also let individuals filter their incoming activity stream to see posts from groups to which they belong (in addition to filtering the flow with the people and event filters that were present in earlier versions of the offering.)

The incorporation of these filters for outbound and incoming micro-messages are an important addition to the offerings of NewsGator and Socialtext, but they are long overdue. Socialcast has offered similar functionality for nearly two years and Yammer has included these capabilities for some time as well (and extended them to community members outside of an organization’s firewall, as announced on February 25th.) Of course, both Socialcast and Yammer will need to rapidly add additional filters and features to stay one step ahead of NewsGator and Socialtext, but that represents normal market dynamics and is not the real issue. The important question is this:

What other filters do individuals within organizations need to better direct microblogging posts and status updates to others, and to mine their activity streams?

I can easily imagine use cases for location, time/date, and job title/role filters. What other filters would be useful to you in either targeting the dissemination of a micro-message or winnowing a rushing activity stream?

One other important question that arises as the number of potential micro-messaging filters increases is what should be the default setting for views of outgoing and incoming messages? Should short bits of information be sent to everyone and activity streams show all organizational activity by default, so as to increase ambient awareness? Perhaps a job title/role filter should be the default, in order to maximize the focus and productivity of individuals?

There is no single answer other than “it depends”, because each organization is different. What matters is that the decision is taken (and not overlooked) with specific corporate objectives in mind and that individuals are given the means to easily and intuitively change the default target of their social communications and the pre-set lens through which they view those of others.

In a Regulatory Notice released earlier today, the Financial Industry Regulatory Authority (FINRA) opined that brokerage firms and their registered representatives must retain records of all communications related to the broker-dealer’s business that are made through public blogs and social media sites, such as Facebook, LinkedIn, and Twitter.

“Every firm that intends to communicate, or permit its associated persons to communicate, through social media sites must first ensure that it can retain records of those communications as required by Rules 17a-3 and 17a-4 under the Securities Exchange Act of 1934 and NASD Rule 3110. SEC and FINRA rules require that for record retention purposes, the content of the communication is determinative and a broker-dealer must retain those electronic communications that relate to its “business as such.”

Brokerage firms will now be required to archive and make discoverable business-specific content produced by their employees. They will also have to establish and maintain procedures that ensure a supervisor has either approved an interactive electronic communication before it is posted, or that a “risk-based” method of post-communication review exists and is exercised.

“While prior principal approval is not required under Rule 2210 for interactive electronic forums, firms must supervise these interactive electronic communications under NASD Rule 3010 in a manner reasonably designed to ensure that they do not violate the content requirements of FINRA’s communications rules.

Firms may adopt supervisory procedures similar to those outlined for electronic correspondence in Regulatory Notice 07-59 (FINRA Guidance Regarding Review and Supervision of Electronic Communications). As set forth in that Notice, firms may employ risk-based principles to determine the extent to which the review of incoming, outgoing and internal electronic communications is necessary for the proper supervision of their business. “

In addition, FINRA’s guidance states that all organizations under its purview must establish and communicate social media usage guidelines for their employees, and that those individuals must also receive employer-provided training on those guidelines.

“Firms must adopt policies and procedures reasonably designed to ensure that their associated persons who participate in social media sites for business purposes are appropriately supervised, have the necessary training and background to engage in such activities, and do not present undue risks to investors. Firms must have a general policy prohibiting any associated person from engaging in business communications in a social media site that is not subject to the firm’s supervision. Firms also must require that only those associated persons who have received appropriate training on the firm’s policies and procedures regarding interactive electronic communications may engage in such communications.”

FINRA’s guidance marks the beginning of a new era for financial services companies and their use of external social media. However, the Financial Services sector is not the only one that will be subject to regulation of communications made via blogs and other types of social software. An IBM Senior Product Manager related last week at Lotusphere that IBM customers in the Healthcare and Utilities industries were also beginning to ask about the management of user-generated and social content.

If your organization is currently required to comply with regulations pertaining to the use of email and instant messaging for business communication, expect to see similar requirements placed on your management of external blog and social media site posts in the near future. At some point, it is likely that these regulations will also be applied to internal communications conducted via enterprise social software.

Is your organization ready for this new era? Gilbane Group’s seasoned advisors can help you prepare to manage user-generated and social content. Contact us today to learn how.

Talk about a trip down memory lane…  Another excellent blog post yesterday by my friend and fellow Babson College alum, Sameer Patel, snapped me back a few years and gave me that spine tingling sense of deja vu.

Sameer wrote about how the market for Enterprise 2.0 software may evolve much the same way the enterprise portal software market did nearly a decade ago. I remember the consolidation of the portal market very well, having actively shaped and tracked it daily as an analyst and consultant. I would be thrilled if the E2.0 software market followed a similar, but somewhat different direction that the portal market took. Allow me to explain.

When the portal market consolidated in 2002-2003, some cash-starved vendors simply went out of business. However, many others were acquired for their technology, which was then integrated into other enterprise software offerings. Portal code became the UI layer of many enterprise software applications and was also used as a data and information aggregation and personalization method in those applications.

I believe that much of the functionality we see in Enterprise 2.0 software today will eventually be integrated into other enterprise applications. In fact, I would not be surprised to see that beginning to happen in 2010, as the effects of the recession continue to gnaw at the business climate, making it more difficult for many vendors of stand-alone E2.0 software tools and applications to survive, much less grow.

I hope that the difference between the historical integration of portal technology and the coming integration of E2.0 functionality is one of method. Portal functionality was embedded directly into the code of existing enterprise applications. Enterprise 2.0 functionality should be integrated into other applications as services. Service-based functionality offers the advantage of writing once and using many times.  For example, creating service-based enterprise micro-messaging functionality (e.g. Yammer, Socialcast, Socialtext Signals, etc.) would allow it to be integrated into multiple, existing enterprise applications, rather than being confined to an Enterprise 2.0 software application or suite.

The primary goals of writing and deploying social software functionality as services are: 1) to allow enterprise software users to interact with one another without leaving the context in which they are already working, and 2) to preserve the organization’s investment in existing enterprise applications. The first is important from a user productivity and satisfaction standpoint, the second because of its financial benefit.

When the Enterprise 2.0 software market does consolidate, the remaining vendors will be there because they were able to create and sell:

• a platform that could be extended by developers creating custom solutions for large organizations,
• a suite that provided a robust, fixed set of functionality that met the common needs of many customers, or
• a single piece or multiple types of service-based functionality that could be integrated into either other enterprise application vendors’ offerings or deploying organizations’ existing applications and new mashups

What do you think? Will history repeat itself or will the list of Enterprise 2.0 software vendors that survived the impending, inevitable market consolidation consist primarily of those that embraced the service-based functionality model?