One of the better parts of my talk at the
Bay Area Futurist Salon was finally meeting Eric Eugene Kim of
BlueOxen. He posted some
well grounded reflections, but raised some issues, so I'll continue the conversation here.
Eric questioned my original definition of social software: Software that adapts to its environment, rather than requiring its environment to adapt to it.
...I asked him to clarify the latter statement, and he explained that most collaborative software tries to enforce too much structure. These tools force users to figure out how to fit the data into the tool, whereas the tools should fit the data. In this vein, Ross spoke highly of Wikis and blogs, and also of human filtering (such as Google's technique of measuring backlinks) as a way of organizing information.
I strongly agree with Ross's philosophy, although I don't like how he worded it in his slide. His statement is equivalent to the first part of
DougEngelbart's philosophy of coevolution of tools and processes; however, it leaves out the second part, which is equally important.
Doug says that tools ought to augment human processes. However, as we learn more about the tool, we also must evolve the processes to adapt to the tool. An example that Doug often cites is the bicycle. Riding a bike is not intuitive, but it offers significant performance advantages over a tricycle. (To illustrate this point, Doug likes to show
this picture.) "User-friendly" tools can be useful, but they should not be the end-goal...
We actually share the same philosophy, far be it from me to disagree with Doug, so let me explain. A good tool is meaningless without social agreement on how to use it. Sometimes this agreement is gained up front. Sometimes the very nature of the tool fosters consensus. Without process and practice the
value of IT is negative.
Tools for Practice
But there is the problem, adapting processes has even more latency than adapting tools. Gaining agreement is often done by imposing agreement, which hurts the prospect of new agreement that embraces change. Processes are designed by efficiency experts with a given set of information about the team, task, tools and environment. The problem is information in our turbulent word becomes out of date the second its created. People find themselves with a process that doesn't work because of new environmental conditions.
The good news is people want to get their work done. When a process fails them, they turn to their informal network, to
business practice. They IM their friend Sally who works in another department, but has the information they need. Or they consult their
Workspace to find who has been blogging about the issue in the middle of project communications.
When formal networks fail, informal networks support. This phase transition is at the intersection of social software and social networking, the opportunity for social software to support business process as well as practice.
Tools that work the way people do -- rather than how they are supposed to -- is counter-intuitive. Lo and behold, they
suprisingly work. From selling and servicing social software, I can tell you that one of the first issues raised is how giving up
control and structure (as in data) could result in inefficiencies in reporting and intelligence. But software without pre-designed constraints is suprisingly adaptable for
reporting. And the intelligence you gain from all those groups forming, intertwingling and linking openly is
emergent. Suddenly you are making decisions based on what your organization knows and feels is important.
I am absolutely convinced that achieving significantly greater levels of productivity and discovery in knowledge work will not come the cycles of process innovation. Tools must evolve to support business practice.
Disruptive Technologies Emerge
After the Salon, over pizza and beer, I was talking with some folks about how these tools are being adopted from the bottom-up and the Innovator's Delimma. A wicked smart guy from SAP was arguing that large companies had learned their lessons and watch for new innovations so they can embrace them. Some other wicked smart guys took issue, saying not all big company employees are as wicked smart as him and making a disruption a priority at the executive level simply happens too late. I suggested that perhaps with the right social software, enable wicked smart employees to vote their attention with links, such disruptive issues could rise to the top in a large organization.
Adapting Software to Software
During my talk I provided my rant about how email is dying. The above has probably exhausted you with rants, so I'll let Eric sum it up:
One of his main arguments against e-mail as a collaborative tool was that it encourages discursive discourse, and that it's hard to make any sense of the sum product. I agree entirely with this argument, but would use it as an argument for how to use e-mail effectively rather than against e-mail entirely.
Yes. That's why Socialtext works with email (creating blog posts and wiki pages from email; email alerts, etc.) to foster effective use, channeling activity to a shared many-to-many space so email can return to one-to-one and one-to-few.
Which brings me to back to that
definition from a year ago. Software is part of the environment of software. IT ecosystems must be
loosely coupled to foster
scope and span over scale and speed. Such is the role of discovery and emerging standards like RSS and Atom, but also adapting to the sedimentary layers and ingrained habits of systems and
users/developers. Much work remains.
The point of this post isn't this definition of social software,
others are better and the discussion has been done. Its that there are some great little companies, that aren't competing, building things and helping people use them -- to solve big problems that underlie the competitive advantage of enterprises.
1. Zbigniew Lukasiak on December 2, 2003 6:31 AM writes...
The advantage and disadvantage of email is that it is 'push' technology - i.e. it is the sender who chooses the audience. Since it is the sender who knows the message, when he knows the audience as well, this is the most effective method of information dissemination. But when the sender does not know the audience enough it might be the case that it's better to rely on the audience opinion of what messages they should receive - this is the 'pull' method. I guess what is needed is something that would nicely integrate those two methodologies. That's why I think about it in terms of routing.
---------
"Eric questioned my original definition of social software: Software that adapts to its environment, rather than requiring its environment to adapt to it."
The problem with taking that as definition of social software is that it applies to all good software and I don't see why all good software should be called social.
Permalink to Comment