Tag Archives: executive

Jive Software Announces Management Team Changes

This entry was cross-posted from Meanders: The Dow Brook Blog

Jive Software has just announced that Christopher Morace will become SVP of Business Development. Morace will retain product marketing oversight and responsibility, but step aside from product management duties. He will be replaced as SVP Product Management by Patrick Lin, who is leaving VMware to join Jive.

These changes to the management team are important because they suggest two things:

1. Jive is still moving quickly toward an Initial Public Offering (IPO) and, perhaps, accelerating their pace toward that goal. By creating a new position (SVP of Business Development) and assigning a proven executive team member (Morace) to the post, Jive is signaling that it is making a serious investment in building partner and reseller channels.

Most enterprise software start-ups do not work to build out their channels until they’ve scaled revenue gained through direct sales to a point necessary to successfully make a public offering. By Jive’s own estimates, the direct sales amount necessary to trigger an IPO is $100 Million. Their creation of a new management team role focused on business development is a clear sign that Jive is nearing that IPO trigger revenue target.

2. The hiring of Patrick Lin reflects the increasing importance of cloud delivery to Jive (and all enterprise social software providers) moving forward. Lin, who had been at VMware for just over 6 years, has deep knowledge of infrastructure and application virtualization technologies and practices. His leading-edge experience will help Jive optimize its social business software offerings for private cloud deployment by customers. Lin’s  virtualization management expertise will also guide Jive in any attempt to build a version of the Jive Engagement Platform that can be hosted in a public cloud (Jive already offers and hosts a SaaS version of its platform.)

Lin is a great addition to the Jive team and not only for his virtualization experience. He has served in product management roles at other companies (VERITAS, Invio) prior to his stint at VMware. In addition, has held product marketing (Invio, Intuit) and business development (Katmango, WebTV) roles, which make him a well rounded executive who can contribute to Jive’s success on many terms.

Considered together, the management changes made by Jive today are a strong indicator that the Enterprise Social Software (ESS) market has reached a new level of maturity and that Jive is pushing it forward. The market continues to expand quickly and customer requirements continue to evolve. Other ESS providers should consider initiating or increasing  investments in channel development. They should also realize that cloud deployments of enterprise software will continue to increase and make appropriate changes to virtualize and optimize their offerings.

Today’s announcement makes me wonder if Jive will be ready for an IPO in the first half of 2011, rather than the later dates previously held as conventional wisdom. What do you think?

Advertisements

Enterprise 2.0 or Social Business: Who Cares?!

As you may have already observed, the debate about what label to attach to the renewed focus on people in the business world has been rekindled this week, in conjunction with the Enterprise 2.0 Conference. While I will address the label question here, I do not intend to get mired in the debate. Instead, I will focus on whether or not the” people matter” movement should be described with tool talk or addressed in a more holistic fashion.

First, the label. I do not care if you call this renewed focus on people and the connections between them in the business world “Enterprise 2.0” (E2.0), “Social Business”, or anything else. The value to be gained from connecting people within and between organizations is to be found in what’s accomplished as a result of doing so, not in what the notion is called. Sure, it is helpful for the movement to have a lingua franca with which to “sell” the vision to business leaders. However, a consensus label is not necessary. A clearly articulated, holistic approach and value proposition are required.

So forget the label. Instead, focus on the substance of what we (those who believe that people matter in business) are presenting to organizational leaders that are more concerned about traditional issues like process efficiency and financial performance.

Now, on to the real debate. In his latest blog post, Andrew McAfee continues to insist that the message needs to be tool-centric. He says that we should address executives in phrases such as,

“There are some important new (social) technologies available now, and they’ll help you address longstanding and vexing challenges you have”

The movement is not just about tools. In fact, the tool-centric focus to-date of E2.0 is a primary reason why the movement’s core message that people matter has not reached the C-suite, much less sway their thinking. To suggest to a senior executive that the only way to better their organization’s performance is through the application of technology is simply, well, simplistic. We need to discuss all of the levers that they can pull to change the way their organizations consider, enable, incent, and interact with customers, employees, and partners.

To succeed in transforming an organization, leaders must change and communicate what is valued and how people are rewarded for applying those values while attaining stated goals and objectives. We must show those leaders that modifying organizational values to include (or increase) the importance of people to the business can lead to tangible increases in revenue and decreases in operating cost. The benefits statement does not need to be presented as an ROI analysis; anecdotal evidence from efforts within the organization, or from other entities, should suffice. And, yes, technology should be presented as an enabler of both the change effort itself and the new value system guiding the organization.

And one more thing. This movement, however we choose to label and describe it, is NOT a revolution. Senior leaders fear and shun revolutions. So avoid using that word when selling the vision. We are not advocating the overthrow of existing enterprise organizational or IT systems. Instead, we seek to convincingly demonstrate that augmenting the existing ways of conducting and managing business with a complementary, people-centric approach can yield substantial benefits to those organizations who do so. Do not preach revolution; instead, suggest specific actions that leaders can take to better connect people in and outside of their organization and show them the kinds of results that doing so can produce.

You Are Your Organization’s Chief Collaboration Officer

I Want You!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.

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

  • intranet replacement/updgrade
  • self-service HR
  • application aggregation
  • document/content management
  • expertise location
  • knowledge sharing
  • executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.

Conclusions

ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.