Jim McGee
Technology for us - the heart of Enterprise 2.0?
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:
- Doug Engelbart. Toward High-Performance Organizations: A Strategic Role for Groupware
- Alan Kay. The Real Computer Revolution Hasn’t Happened Yet
- Dave Snowden. Cognitive Edge (Snowden’s blog may be the simplest place to start here; the papers tend to be a bit academic)
- Jeff Conklin. Wicked Problems and Social Complexity (PDF). Cognexus Institute
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?
Tags: FASTForward08, Enterprise+2.0Cognitive surplus and organizational slack
Clay Shirky’s got a new talk and he’s taking it on the road. It’s stimulating a good bit of thoughtful discussion around the web. Here’s a video version of his talk:
There is embedded content here that you cannot see. Please open the post in a web browser to see this.
Shirky has also posted a transcript of the talk on his site, if you’d prefer to read instead of watch. The talk is a riff on one of the themes of his new book, Here Comes Everybody: The Power of Organizing Without Organizations. I’ll post a complete review of that shortly; it’s well worth you’re making time to read it.
One of the stories Shirky hangs his argument on is an interchange with a TV producer about the creation and growth of Wikipedia. Here’s how he tells it:
I started telling her about the Wikipedia article on Pluto. You may remember that Pluto got kicked out of the planet club a couple of years ago, so all of a sudden there was all of this activity on Wikipedia. The talk pages light up, people are editing the article like mad, and the whole community is in an ruckus–”How should we characterize this change in Pluto’s status?” And a little bit at a time they move the article–fighting offstage all the while–from, “Pluto is the ninth planet,” to “Pluto is an odd-shaped rock with an odd-shaped orbit at the edge of the solar system.”
So I tell her all this stuff, and I think, “Okay, we’re going to have a conversation about authority or social construction or whatever.” That wasn’t her question. She heard this story and she shook her head and said, “Where do people find the time?” That was her question. And I just kind of snapped. And I said, “No one who works in TV gets to ask that question. You know where the time comes from. It comes from the cognitive surplus you’ve been masking for 50 years.”
So how big is that surplus? So if you take Wikipedia as a kind of unit, all of Wikipedia, the whole project–every page, every edit, every talk page, every line of code, in every language that Wikipedia exists in–that represents something like the cumulation of 100 million hours of human thought. I worked this out with Martin Wattenberg at IBM; it’s a back-of-the-envelope calculation, but it’s the right order of magnitude, about 100 million hours of thought. And television watching? Two hundred billion hours, in the U.S. alone, every year. Put another way, now that we have a unit, that’s 2,000 Wikipedia projects a year spent watching television. Or put still another way, in the U.S., we spend 100 million hours every weekend, just watching the ads. This is a pretty big surplus. People asking, “Where do they find the time?” when they’re looking at things like Wikipedia don’t understand how tiny that entire project is, as a carve-out of this asset that’s finally being dragged into what Tim calls an architecture of participation. [Gin, Television, and Social Surplus]
The notion of “cognitive surplus” is a clever and useful way to frame the issue. Now, Shirky is primarily interested in the societal level impacts of new technologies. Big numbers help his argument tremendously, but they are a little bit like the arguments for why you might want to target your new consumer product at China (”if we only get one person in a hundred to drink our new sport drink, we’ll sell millions!”). Or the dotcom era arguments for capturing eyeballs. I don’t think that Shirky falls into this trap himself. Here, and in his book, he explicitly talks about how the design and architecture of systems such as Wikipedia leverage cognitive surplus in granular ways to exploit these large numbers.
My primary interests are inside organizations. How can we translate and adapt these insights into those environments? Organizational theorists, not being as clever or market oriented as Shirky, did not think up a notion as attractive as “cognitive surplus.” Instead, they talk about the notion of “organizational slack.” In hindsight, a very poor choice of words. For the last two decades, or more, organizations have been rooting out “slack” wherever they could find it. When the goal is efficiency, this is an appropriate strategy. However, it leaves no capacity for innovation and adaptation. Those few organizations that explicitly provide this capacity, such as Google’s 20% rule, are deemed notable and newsworthy.
The first order of business for business is to immediately appropriate Shirky’s term. Organizations that care about innovation and adaptive capacity should begin talking about “cognitive surplus.” Look for ways to measure it, if only crudely, and increase it.
The second task is to better understand and appreciate how various new technologies and tools let organizations derive benefit from smaller grains of cognitive surplus. Google’s 20% rule is a product of a time largely before blogs and wikis. Can an organization combine the tools with a one hour or 10 minute rule? Can we get value out of an hour a week or 10 minutes contributing to an internal wiki? Clearly, we will need to design some thoughtful support and encouragement processes around the tools in order to take advantage of a different scale of participation.
The third task is to monitor how well the large number phenomena outside the enterprise operate inside. We may discover critical mass issues; efforts below a certain scale are doomed to fail, while slightly larger efforts will need an extensive “life-support” system to survive. Other efforts may need support scaffolding but can become self-sustaining. Today, we have far more questions than answers. Shirky has provided us with some good new notions to start finding answers. I’d also recommend some of the following discussions that I’ve come across so far:
- The Importance of Pigheadedness - Suw Charman-Anderson
- Waking Up With a “Cognitive Surplus” - Will Richardson
- “Where do people find the time?” - Patrick Hayden
What is an Oreo?
Alan Matsumura and I had an excellent conversation earlier this month about the work he is starting up at SilverTrain. Part of the discussion centered on the unexpected problems that you run into when doing BI/information analytics work.
Suppose you work for Kraft. You’d like to know how many Oreos you sold last quarter. An innocent enough question and, seemingly, a simple one. That simply shows how little you’ve thought about the problems of data management.
Start with recipes. At the very least Kraft is likely to have a standard recipe and a kosher recipe (they do business in Israel). Are there other recipe variations; perhaps substituting high fructose corn syrup for sugar? Do we add up all the variations of recipe or do we keep track by recipe?
How about packaging variations? I’ve seen Oreos packaged in the classic three column package, in packages of six, and of two. I’ve seen them bundled as part of a Lunchables package. I’m sure other variations exist. Do we count the number of packages and multiply by the appropriate number of Oreos per package? Is there some system where we can count the number of Oreos we produced before they went into packages? If we can manage to count how many Oreos we made, how does that map to how many we will manage to sell?
That may get us through standard Oreos. How do we count the Oreos with orange-colored centers sold at Halloween in the US? Green-colored ones sold for St. Patrick’s Day? Double stuf Oreos? Double stuf Oreos with orange-colored centers? Mini-bite size snak paks? Or my personal favorite: chocolate fudge covered Oreos. I just checked the official Oreo website at Nabisco. They identify 46 different versions of the Oreo and don’t appear to count Oreos packaged within another product (the Lunchables question).
That covers most of the relevant business reasons that make counting Oreos tricky. There are likely additional, technical reasons that will make the problem harder, not easier. The various systems that track production, distribution, and sales have likely been implemented at different times and may have slight variations in how and when they count things. Those differences need to be identified and then reconciled. Someone will have to discover and reconcile the different codes and identifiers used to identify Oreos in each discrete system. And so on.
By the way, according to Wikipedia, over 490 billion Oreos have been sold since their debut in 1912. As for how many were sold last quarter, it depends.
David Maister on getting from strategy to execution
Strategy and the Fat Smoker; Doing What’s Obvious But Not Easy, Maister, David
David Maister has spent years advising professional service firms on the particular challenges of running their businesses. I first met David during my MBA days when I was a student in his course on the Management of Service Operations. I’ve come to trust his insights and perspectives about the professional world I occupy. More recently, I’ve come to see that his perspective is more generally relevant as more and more of us do work that is effectively professional, even if we are not inside actual professional services organizations. There is a substantial overlap between professional work and knowledge work, which makes Maister more relevant than ever.
Strategy and the Fat Smoker is David’s most recent effort to share his insights. In it, he turns his attention to the particular challenge of bridging from knowing what to do to actually managing to do it. In fact, David starts with the observation that “real strategy lies not in figuring out what to do, but in devising ways to ensure that, compared to others, we actually do more of what everybody knows they should do.”
Structurally, Maister works through his argument by working through what constitutes strategy in this particular perspective, the central importance of client relationships, and how those shape the kinds of management practices most likely to be effective.
For Maister, strategy is primarily a problem of organizational design and management, which is the soft stuff that always turns out to be hard. It is particularly hard, however, when the organization in question is populated with professionals/knowledge workers who must produce and deliver services to clients. You cannot succeed by designing systems and processes to compel behavior, because you have a workforce that can’t simultaneously be forced to comply with a system and exercise their independent and autonomous judgment. Maister explores this issue by focusing on two dimensions that characterize a professional; to what degree do they prefer to work solo vs. collaborate within a team and to what extent to they prefer immediate rewards vs. being willing to invest now in future payoffs. The point, of course, is not that one set of answers is better than another, but that trying to mix people with different answers in the same organizational environment is probably not a terribly good idea.
David also presents a provocative discussion of the importance of organizational purpose. While he acknowledges that shared purpose can be a very powerful tool within an organization, he argues that the power only comes when there are clear “consequences for non-compliance.” Until and unless you can translate generalities about purpose into clearly stated and observed rules of performance, then there’s no point to worrying about purpose. Put more positively, the test of strategy comes in working out and then operating within the day-to-day rules of performance that make sense for your strategy.
In one sense, Maister doesn’t break any extraordinary new ground. What he does do is to challenge you about how willing you are to drive grand ideas deep into how you choose to do your work on a day-to-day basis. And he offers lots of good, concrete advice on how to make that transition.