I’m presenting today to the Technology Leaders Association meeting in Chicago on the topic of “Technology for Us.” I’ve uploaded my slides to Slideshare.
I’ve also tagged a number of links at delicious; both of sites we may check out and references to follow up materials. Those links can be found here.
[cross-posted at Fast Forward blog]
Recently, I sat through a presentation about a Sharepoint-based intranet project to improve processes within the HR group of a medium-sized organization. The process in question was one of collecting annual performance reviews throughout the organization. Using Sharepoint, the HR group and their consultants replaced Word documents, spreadsheets, and email with Infopath forms and programmatic workflows. The client was happy and the consultants had a nice demo they could show to their prospects. Nonetheless, I found myself dissatisfied.
For all the new technology deployed, this effort struck me as an example of what my old friend and mentor Benn Konsynski calls "speeding up the mess." This HR process is an instance of the micro-processes that comprise knowledge work activities in organizations.
Other examples might include:
One of the many lovely things about blogging is the way that people redirect your attention to things you
The phrase “technology for us” has been kicking around in my head for the past several months. At the FASTForward ’08 conference, I took a first pass at articulating my thinking in a video interview with Jerry Michalski. Consider this my next attempt. I expect there will be more.
Technology for Them
Information systems in organizations generally have been “technology for them.” Accounting systems, inventory control systems, ERP systems, reservations systems are all designed and imposed on their users.
Done properly, these systems yield efficiencies, predictable quality, and significant economic benefits. The design and implementation processes for these systems are industrial engineering at its best. Expert designers observe, redesign, and streamline processes to define and constrain what the target user population is allowed to do.
In these systems, users are simply one component in a mechanistic environment designed to constrain behaviors. User roles are limited to situations where technology is too expensive and a human user is more economical. Individual creativity and initiative are neither desirable or appropriate.
Technology for Me
The personal computer revolution brought “technology for me.” We saw innovation and scores of programs designed to improve the productivity and effectiveness of individual knowledge workers. Few of us would go back to a world without spreadsheets, word processors, or the other tools made possible and accessible via personal level information technology.
The first waves of innovation in the PC world focused largely on individual productivity. Attention to work process, if any, was a function of the idiosyncrasies of each user. Broadly speaking, innovation took one of two forms. Programmers and developers generalized from their own needs to develop unique tools solving their own problems. With luck, those solutions found enough kindred spirits to sustain a market. Early examples here would include the original Visicalc, ThinkTank, More, and dBase. More recent examples would include MindManager, SketchUp, Powerpoint, and the Brain.
The alternate development path was more corporate, with planned attempts to meet the application needs of perceived large markets of individual information and knowledge workers. Examples here would include the original Lotus 1-2-3, Microsoft Word, and Visio.
This development path emphasized industrial and mechanistic conceptions of work. Moreover, the logic of mass markets produced products targeted to the perceived lowest common denominator of user needs. At its worst, this path leads right back to technology for them and Microsoft Bob as a distorted model of users and use cases.
Us as Knowledge Worker
There are two dimensions of “technology for us” worth exploring. The first is “us” as knowledge workers; individuals charged with “thinking for a living” in Tom Davenport’s coinage and expected to exercise substantial initiative and autonomy in the design and execution of their work. The second dimension of “us” is the degree to which key work products and deliverables emerge from the collective and coordinated action of multiple knowledge workers. We’ll return to this second form of us in a bit.
There are both political and practical problems with applying technology effectively to the unique needs of knowledge workers. Previous organizational uses of technology have not had to deal with situations where the target audience was free to ignore you. Knowledge workers occupy positions of power and influence within the enterprise. They have the power and inclination to ignore, dismiss, and actively undermine ill-conceived and poorly executed efforts to modify their work practices. For that matter, they have to power to dismiss well-conceived and well-executed efforts on their behalf.
If you’re smart enough to avoid the trap of trying to dictate an approach to this user community and actively engage them in the design and implementation process, you run into the next constraint. Knowledge workers can’t articulate quality, effectiveness, or efficiency with anything resembling the precision that applies to manual or information work. The nature of knowledge work and its deliverables makes typical measurement approaches suspect (see Crafting Uniqueness in Knowledge Work and The Invisibility of Knowledge Work, for example). We have only recently begun to understand individual knowledge work practices in ways that let us apply technology with some likelihood of success. In many ways we are still working out the details of the vision of knowledge work support first articulated by Vannevar Bush in the mid-1940s in As We May Think.
Us as Groups of Knowledge Workers
Organizations exist to solve problems beyond the capacity of individuals to tackle. This is as true of knowledge work as it is for all other types of work. For all the power of technology to make individual knowledge workers more productive and effective, the greater opportunity lies in developing skill at using technology to support collective activity.
What we haven’t yet done well is knit together our knowledge of how to improve group oriented work practices and technological possibilities. Further, the more promising efforts have seen limited penetration into organizations. When dealing with collective knowledge work we compound the problem of knowledge worker autonomy with the problem that the knowledge work processes we wish to improve are vague, imprecise, and squishy in ways quite uncharacteristic of the work processes we are comfortable working with in industrial settings.
If we take the analysis and improvement tools we are comfortable with in industrial process settings and simply port them to knowledge work environments, one of two things happens. Either, we become hopelessly frustrated trying to force a dynamic and fluid process into the confines of our swimlanes. Or, we mistake the small fraction of the process we can force fit into our tools for the entire phenomenon; guaranteeing that our target users will ignore us and route around our efforts.
While there are people who have thought about the problems of applying technology to complex knowledge work processes and practices, their work has not achieved the widespread adoption it needs to be a meaningful factor in most organizations. Some good entry points into this work include:
The inventory of technology solutions promising to streamline, improve, or transform group activities continues to grow, although it often seems more like baroque and rococo variations on a handful of themes than like new insights or frameworks. Will the next implementation of threaded discussion make any major contribution to educating a group on when and how to make effective use of that technique? Or to understanding what situations make it a poor choice of tool?
What seems to be missing is a synthesis of Group Behavior 101 and a groupware pattern language. I’m not aware of anything that would fit that bill, although Stewart Mader’s recent Wikipatterns might represent a potential starting point. Can anyone point to some examples I’m unaware of? Is this something that we should be working to develop?
These are my notes from a talk that Larry Prusak gave at my invitation at the Kellogg School back when I was on the faculty there. (For posterity’s sake, here is a link to the original blog post, although that version is suffering from bitrot. The Magic Number 300: Knowledge and Community)
His reference to the “magic number 300” is what I now recognize as Dunbar’s Number, which most people seem to estimate at closer to 150. The point remains largely the same.
I persuaded Larry Prusak to swing through Evanston last week (February 2002) and talk about knowledge management to students here at Kellogg. Over the course of 90 minutes he shared his perspective on knowledge as part of organizational life.
On a side note, Larry has abandoned Powerpoint. He’s always favored storytelling anyway. It does make the audience have to work harder, but that’s a good thing.
Unit of Analysis
Larry started with an old research design question – what the right unit of analysis. His answer? The group. Not the individual, not the enterprise. While he argued that there are important ideas tied up in the terms “network” and “community of practice,” he’s also concerned that the terms are well down the devolutionary path toward buzzword. “Group” is a nice simple word and you then have to listen to the actual points he makes instead of tuning out.
His research reinforces others in setting 300 people as a “magic number” — about the limit on the number of people you can know by name. He added one tidbit I hadn’t thought of before; that the typical military working unit has also averaged about 300 through history (worth tracking down the evidence for that later).
Social Capital
Given In Good Company, it wasn’t surprising that Larry tied the issue of group size and knowledge to social capital. He sees knowledge largely in terms of trust and of the conditions where reciprocity works. His evidence says that incentives are useless in knowledge management settings. You have to look to the level where people share without explicit incentives.
As Larry put it, “people want to find each other and want to talk.” You can force this into an economic framework, but that 300 number hints that we’re dealing with something pre-economic. “Gift culture” is the technical term for what Larry has tagged as one of the driving forces of knowledge creation and uses in organizations. What’s interesting about that is that it creates a point of tangency with open source software development as a social phenomenon. Eric Raymond’s writings on The Hacker Milieu as Gift Culture is a good entry point. I’ve got an old essay on linking KM and Open Source ideas that I’ll dust off and post as a story.
Defining Knowledge
Here’s Larry’s densely packed definition of knowledge: “embodied, tacit, pattern recognition.” Whew!
Here we tie in directly to the community of practice literature and to the learning processes that take someone from novice to expert. The late Herb Simon estimated that it takes 10-12 years to become an expert in a field. Experts reveal themselves in their ability to see the patterns in a situation that are invisible to a novice. I had a partner who was an expert on call centers. Dave could walk into a call center and tell you in a matter of minutes where the problems were. If you grilled him for a day or so, you might be able to figure out about half of what went into his judgments. This was why expert systems never succeeded.
Promoting Community
If you believe that capturing knowledge is a vain quest, then you need to direct resources toward community. That’s certainly where Larry comes down. While I believe that community is the more important and more malleable element, I’m not quite so quick to dismiss investments in capturing and organizing knowledge.
The keys to encouraging community relate more to providing time an space than providing money. That’s actually trickier, because it’s easier to throw money at problems. Chapter 4 of In Good Company is the place to go for more details.
Knowledge and Learning
Community is a means to the end of learning how to put knowledge into practice. To IBM’s great disappointment, Larry isn’t keen on document management as a path to better knowledge and he’s pretty skeptical about the value of technology tools to nurture communities. I think he finds much of the money poured into formal knowledge management systems wasted. As he put it “asking about the ROI on knowledge management is like asking about the ROI on babies.”
While Larry is no Luddite, some of his technological skepticism is generational. He’s squarely in the middle of Negroponte’s digital homeless. His skepticism is a useful counterbalance to the usual utopian promises of technology advocates. But I take his input more as design constraints than a meaningful argument to avoid technology.
Larry closed with a really great question to use when poking around in an organization trying to get a sense of its attitudes toward knowledge and learning — “can you make a mistake around here?”
What’s the relationship between knowledge management practices and innovation? On first thought, you would think that effective knowledge management would contribute to more effective innovation as well. On the other hand, knowledge management has often been justified on the value of not routinely reinventing solutions to problems that an organization has already solved. This potentially puts knowledge management and innovation at odds with one another.
The sticking point lies in the measurement and reward systems put in place to encourage active use of the knowledge management system. Absent careful thought about the various ways in which the contents of a knowledge management system feed into business processes, the risk is a measurement system that actively inhibits rather than promotes innovation.