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.