Cisco Presents Collaboration Technology as Sufficiently Advanced

I worked at Cisco for more than a decade in two stints between 1990 and 2003–taking time off from 1995-98 to work with a number of web startups–so I was intrigued to see John Chamber’s picture on the cover of the December issue of Fast Company. In the feature article by Ellen McGrit titled “Revolution in San Jose” Chambers deploys his personal sales skills and his marketing team in a well coordinated approach to “shape the battlefield” for new (or at least acquired and integrated) collaboration technologies from Cisco.

We have been early enthusiasts of web based collaboration technologies and have worked diligently to leverage them not only within our business but in our engagement model with partners and customers.  But their benefits can be oversold and they require considerable change in your internal processes and methods to take advantage of.

Just as the steam engine, the telegraph, electricity, and the telephone took decades to go from invention to full business impact, I keep George Meredith‘s guidance in mind when it comes to the perseverance needed to discover new technology applications and deploy them in production: “The future not being born, my friend, we will abstain from baptizing it.”

I was surprised to read “Cisco as an Emerging Enterprise 2.0 Case Example” by Jim McGee, an astute observer of knowledge management and collaboration technologies, that the Fast Company article as “…a well-documented case study that is an existence proof to other skeptical executives that the combination of Enterprise 2.0 technologies and the right organizational principles and practices can succeed.” A number of activities are described in the article but only three proof points are offered. The first is cited by McGee in his recap:

“The boards and councils have been able to innovate with tremendous speed. Fifteen minutes and one week to get a [business] plan that used to take six months!”

But I would be very cautious that this was anything more than hyperbole. It’s also only an intermediate result: how much revenue has the innovation actually delivered. The second and third proof points are offered by Ron Ricci:

“Across the company, Ricci says, fiscal 2008 saw “a tenfold increase in new projects.” And he points out that operating expenses have been trimmed from about 38% at the height of the tech boom to between 35% and 36% today: “We’re shaving 2% to 3% of profit off of every dollar of revenue we get in.”

But this offers scant proof of a new level of competitiveness: it’s always easy to start new projects, the real challenge is to get them to complete on time with the features that deliver new revenue. Offering as a cost reduction benchmark a comparison between the organization at the height of the bubble and today is unintentionally misleading at best: anyone who doesn’t have better expense control in place compared to a time of hypergrowth probably didn’t survive the dotcom collapse. Cisco’s market cap is perhaps one fifth of what it was then–and still about 25% below where it was five years ago. This sentence in the article goes to the heart of my misgivings:

“Taken to its ambitious conclusion, Chambers wants customers to remake their companies in Cisco’s image, a prospect possible only because of their dependence on Cisco technology.”

One of the hallmarks of a real test case would be some false steps and clear lessons learned. Most new technologies don’t work in the beginning and require a long period of experimentation and process re-design. This story is just too wonderful. And I say this as an everyday user of Office 2.0 technologies. Merlin Mann has some related thoughts in “Real Advice Hurts”

Turns out that, as with a lot of injuries, the entirely sensible impulse to protect and baby a wounded area was the opposite of what Anne actually needed in order to fix the problem. So, by enduring the excruciating pain of chewing gum for just a few minutes, the muscles in her throat suddenly unclenched, and Anne’s pain went away forever.

The advice Anne wanted wasn’t the advice she needed. And, like we all eventually learn, the best advice you’ll get in life hurts like hell at the time. Because it has to.

A startup, lacking Cisco’s brand power, must tell real success stories that address the key changes that an organization must make to be able not only to use but to leverage a new technology fully.

On a side note I am not sure why they let Ellen McGirt take off with a “socialism” angle on their emerging management structure. Tom Malone presciently described how computer networks would lower the cost of coordination to the point that command-and-control management models would give way to cultivate-and-coordinate models in a 1991 article in Scientific American “Computers, Networks, and the Corporation” (1995 reprint here with graphics). There is a nice short interview with Malone by Peter Schwartz entitled “Re-Organization Man” in the July 1998 Wired that opens with these three exchanges that succinctly encapsulate the impact on collaboration technologies on organization structure and management:

Wired: You advocate for business leaders to “cultivate and coordinate.” How so?

Malone: The classic management phrase is “command and control.” If we believe that top-down, centralized management will become less and less desirable and less and less common, the question becomes, What could take its place? The notion of cultivation provides perspective from which we can legitimately think it’s fine if we’re not in control.

Wired: The other part comes from your idea of coordination science?

Malone: Right – part of which comes from the work of economists like Ronald Coase and Oliver Williamson. Compare two generic ways of coordinating any business transaction. One is to have hierarchical authority, a boss, who tells each person what to do so that two activities fit together. The alternative is to coordinate the same two activities as separate players in a marketplace. While with market-based coordination you are able to take advantage of economies of scale, you may have to do more negotiation. You almost certainly have to have more contracts or formal billing mechanisms. Markets allow you to have lower production costs, but generally result in higher coordination costs.

Wired: Yet your studies also suggest that infotech reduces coordination costs.

Malone: Exactly. In general, information technology reduces the costs of coordination, so what makes markets undesirable in some situations becomes less important.

Needless to say this is not socialism, it’s capitalism. Wired and Scientific American are not obscure publications, why Cisco didn’t credit Malone (or look back further and credit Doug Engelbart and J. C. R. Licklider) in addition to Gary Hamel is odd. The title of this post is a riff on Arthur C. Clarke‘s Third Law of Prediction: “Any sufficiently advanced technology is indistinguishable from magic.

Update December 17: Jim McGee and I have had some useful exchanges on his FastForward blog and he has left a question that I need to give some thought to:

What’s the most useful balance between tracking what Cisco is doing as both a large scale organization and a technology vendor with an interest in promoting Enterprise 2.0 as well as taking advantage of it? Perhaps the next question is how can we get Cisco to tell us more about what’s worked and what hasn’t worked in their early adopter efforts.

I welcome your advice and observations either here or on the original thread.

Update December 18: Michael Sampson‘s latest blog post “PTG Implements SharePoint Server to Improve Project Collaboration for PWC Sales” contains the following succinct advice:

The key takeaway though: if you want an independent opinion on which technology platform to use to support business needs, don’t ask a vendor-aligned partner for advice. That’s generally true of any vendor and its partners, so this isn’t a Microsoft-specific comment.