Opinion: Tech innovation should proceed from need, not hold fast to the past.When I saw the news of Ciscos
forthcoming TelePresence virtual meeting system, my first thought was,
"Now theres a really well-paved cow path." For anyone building
enterprise applications, Ciscos innovation is a cautionary example of the
temptation to approximate the familiar, as closely as technology enables --
instead of starting afresh with a business need, and meeting it in the best
way that new technology permits.
If that "cow path" phrase is new to you, it refers to the layout of
streets in a city like Boston, with its quaint intersections at almost every
imaginable angle. The layout of those streets, as you know if youve ever
driven there, clearly wasnt designed to make traffic flow smoothly -- or
based, for that matter, on any other high-level thinking of what would make
an effective system. It was, or so the legend goes, created by taking the
established paths from the citys agrarian past, and making incremental
improvements to handle successive generations of transportation
technology.
The result is a mess. It wouldnt matter if those were electric cars or
even anti-gravity monorails running through that mess, it would still be a
mess. Thats why systems need to be designed to achieve the best possible
match between business problems and new capabilities, rather than using
new capabilities to imitate old solutions.
You can see the results of "cow path" thinking in many aspects of many
organizations. The notion, for example, that an effective management span
is at most eight people under one manager dates back to when we were
hunting (or fighting) in forests, and a team of more than eight people
couldnt hear one leaders instructions. As the late Peter
Drucker well noted, though, an orchestra conductor leads a group of
several dozen, and that works because theres a broader
allocation of specialized knowledge and personal responsibility.
If face-to-face meetings were considered the high point of
organizational productivity, Id endorse the idea of throwing bandwidth
and hardware at the task of migrating that process to cyberspace. I have to
admit that "virtual table" meeting environments make for appealing scenes
in telecom providers TV commercials of how well live tomorrow: virtual
Thanksgiving dinner, anyone?
Even so, I dont for a moment miss the bad old days before I became a
full-time telecommuter -- coming up on 18 years ago -- when I had to attend
real meetings all the time. If you ask yourself, "What are the
functions of a meeting?" -- and come up with a list like "Sharing
information, establishing priorities, agreeing on responsibilities, and
assigning actions to be taken" -- then wouldnt you agree that current
technology offers much better ways to do most of these things than sitting
around a table, real or virtual?
If you think of your goal as helping a development team write better
code more quickly, youll come up with something like the collaboration tools in Suns Java Studio Enterprise. If
you think of your goal as improving your process of new product definition
and established product line management, youll come up with something
like Sopheons
Accolade and its Accelerator
packages.
If you think of your goal as making it possible for dispersed teams to
"have better meetings," youll come up with something like Ciscos solution.
Great technology, no question. Productive application? Thats for you to
decide.
Tell me where youve seen cows wandering at peter_coffee@ziffdavis.com
a>
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.