Blinding me with information

I've had Brown and Duguid's The Social Life of Information on my reading list for a long time.  I finally picked up a copy at the library, and I was happily surprised that it holds up well after ten+ years.  Sure there are some dated examples, but the overall idea still makes sense.

I think the main reason it holds up is that it is not a book about knowledge management or innovation or technology or many of the other topics covered in the essays.  It is a book about design and how we tend to forget that there are many more factors than what the designers focus upon.  

The main point of the discussion is around the claims of evangelists for information systems, though the authors touch on other areas of extreme claims too.  The authors discuss the futurists and information evangelists who believe that we are just around the corner from a the end of <take your pick>, all because of of demassification, decentralization, denationalization, despacialization, disintermediation, and disaggregation (the 6-D's): elements that information availability and technologies will enable.  In the minds of the authors, all these discussions assume that the way people operate with respect to information has to do with only the information.  And, by the way, futurists have been predicting the end of <take your pick> for a long time.

But there is a social life that revolves around the information that is much harder to capture and codify...  We look to verbal and physical queues for validity of what someone is saying.  Our business processes have much more than just the inputs and outputs.  The interesting things we do aren't repeatable.  Location matters in many aspects of business and socialization.

In short, design that focuses strictly on one aspect of how things are done (the information; the process; the technology; the knowledge) will fail.  People do things for a reason, and these reasons must be understood.  In fact, the bigger the proposed change, the deeper the understanding of the entire system must be.  In this light, the famous failure of Xerox to pick up on the early PC innovations of Xerox PARC can be better understood: the scientists were proposing changes so vast in areas far away from the core business of Xerox, that there was very little chance for the ideas to be taken up by the engineers who would be responsible for implementing them.  There was no common framework for the scientists and engineers.  On the other hand, there were others in Palo Alto who could see the value: Apple.  And it still took them years to take the ideas to market.  The authors talk about many other examples where this tunnel vision, while producing interesting results, ended up not working as expected because all the social aspects of the work were downplayed or ignored. 

In fact, in the essay on reengineering (business process reengineering: BPR), the authors describe how all the social life around business process is downplayed and often treated as waste.  Businesses were re-engineered to remove much of the social lubricant that helped business flow.  The essay on knowledge management was hopeful that KM would be a shift away from the intense focus on information and account for the human aspects of knowledge: that knowledge requires a knower.  They have a great phrasing: information can easily be written down and transferred.  But it is much harder to detach (and transfer) knowledge from the know-er and the context in which that knowledge resides.  Look at best practices as an example.  This then tied to a discussion of process vs. practice and then to networks of practice and the narrower, communities of practice.  While these topics are very familiar to people who have been following KM, I enjoyed how they were put together.  I had to wonder, though, after reading the KM essay: what happened?  Why did KM miss on the promise that it seemed to offer in the late 1990's?  Some of the answer is right in the book: the focus on KM shifted from the how and who and into the stuff to be discussed.  The result?  Boasting about how many Lotus Notes databases that the company had running.

One of the topics in the book has to do with how technology was going to presumably remove the need for people to be co-located in order to get work done.  This assumes that the work people do is merely the exchange of information and could be done over computer networks or teleconferences.  But it's been shown again and again, that there is a non-information component to people working in offices together: the socialization that is needed to help people do their work and learn about the networks they've fit themselves into.  But then I look at what has changed in the last ten years and wonder if some of the problems of the way people work together in this way have been overcome.  I wonder if things like broadband and social software has helped some people overcome some of the missing connections they have when they work side by side. 

As I read the discussion around design, I was struck with a connection to Theory of Constraints.  There were several places in the early chapters that rang a familiar bell.  New software implementations, no matter how well-intentioned the design, can succeed without clear understanding of the situation into which the software is being implemented.   These are often called the Necessary and Sufficient Questions on Information Technology that come out of Goldratt's Necessary but not Sufficient:

1. What is the power of the software?  (That's usually easy to answer.)
2. What is the problem that this software is fixing?  How, exactly, will the software resolve the problem?
3. What are the (old) ways of doing business that are in place to deal with the problem?
4. What new ways of doing business must be created, now that the software is being implemented?
5. Understanding these old and new rules, does the software need to be changed?
6. How can we make the change to take advantage

It is that 2nd question that starts taking you away from "this stuff is going to change the world" claims of the evangelists and back down to the reality.  What is the problem that this software (or any change) is going to resolve?  And the next question gets you to thinking about how this cool thing will fit into the business or organization - into the way people are doing things now.  And this seems to be Brown and Duguid's basic suggestion: do interesting things, dive into the details.  But then when you come back up to the surface, take off the blinders and look around to understand how people would really take advantage of what has been developed.

[Photo: "Horse Blinkers" by Alex E. Proimos]