Author Archive
by Jim McGee
November 20, 2008 at 9:37 am · Filed under
Enterprise 2.0, Social Media
The Obama campaign was innovative on a number of dimensions, particularly with the use of social media and the effective leverage of committed volunteers. There’s been some good reporting that captures the ground truth of what the campaign actually did and some early efforts to make sense out of these facts in a way that offers lessons for those of us interested in their relevance to broader organizational and enterprise needs.
Use of social media
Effective use of engaged volunteers
Lessons for organizational design and strategy
by Jim McGee
November 10, 2008 at 4:54 pm · Filed under
Innovation
How often do you run across organizations that claim they intend to be "fast followers" when it comes to some dimension of strategy and innovation? Maybe I’m simply cranky because it’s Monday, but is there any way to make sense of such an approach in operational terms? The image of "fast follower" is intended to evoke a NASCAR driver drafting behind the leader, carefully waiting for the right moment to streak past and across the finish line. It’s deeply rooted in a notion that strategic success is a function of execution.
Any fast following strategy assumes learning from the leaders as a necessary first step. If you actually believe that the strategy can work, you need to be operating with something along the lines of the following as a theory of learning over time:
In this model, watching a first mover and waiting allows you to start your learning at a higher level and sometime later pass the first mover as their learning process peaks and levels off or slows down. I have two problems with this model. First, it assumes that the lessons learned by our first mover are easily observable and quickly transferable. Second, it still denigrates learning as an ongoing requirement. In this model, learning only needs to happen long enough to figure out the new strategic game and we get back to execution as the only relevant differentiator. It encourages you to undervalue and under invest in learning as a strategic competence.
I suspect that strategic learning is much more likely to follow a logistics curve of some sort. Early learning is relatively slow, followed by a period a very rapid learning, and ultimately a leveling off. If you accept that model of learning, then a fast follower strategy becomes even more suspect. In that environment, first mover advantages are likely to be more pronounced, with something like the following representing that situation:
At this point, being early in my own learning process, I mostly have more questions, not answers. Among them, in no particular order, are:
- What’s the relative value of competitive secrecy vs. the internal organizational drag on learning imposed by attempts to preserve secrecy?
- What can you do to shorten the slow ramp stage of learning?
- Under what circumstances would fast following remain a viable strategy? Are those circumstances strategically interesting?
- How do shortening learning cycles alter this argument?
by Jim McGee
October 23, 2008 at 8:46 pm · Filed under
Book Review
The Innovator’s Guide to Growth: Putting Disruptive Innovation to Work, Anthony, Scott D. et.al.
The Innovator’s Guide to Growth is the newest installment in a series of books articulating and explicating Prof. Clay Christensen’s theory of disruptive innovation. This hands on guide packages some of the insights developed as an outgrowth of the consulting work of Innosight, LLC, the consulting firm founded by Christensen to pursue the practical insights from his research at the Harvard Business School. If innovation is part of your current or prospective job description, this needs to be on your shelf (after you’ve read it, of course).
Christensen’s theories of disruptive innovation appeared first with the publication of The Innovator’s Dilemma in 1997. During the worst excesses of the dotcom boom, every start up business plan including an obligatory head nod to Christensen and an assertion that their business model was truly disruptive. Who doesn’t want to be innovative; ideally disruptively so. Christensen and his colleagues have continued to develop his theories in The Innovator’s Solution: Creating and Sustaining Successful Growth, Seeing What’s Next: Using Theories of Innovation to Predict Industry Change, and now The Innovator’s Guide to Growth.
Christensen distinguishes two forms of innovation — sustaining and disruptive — not in terms of their technological features but in terms of their relationship to markets. The distinction in summarized in the following diagram reproduced from The Innovator’s Guide to Growth.
In essence, Christensen’s theory of disruptive innovation flows from recognizing that the pace of technology improvement is generally more rapid than the capacity of users in the market to take advantage of those improvements. This differential is what open possibilities for differing approaches to innovation.
In this market oriented theory of innovation, there are three paths available to organizations interested in articulating potentially disruptive strategies. The first is to identify and target "nonconsumers;" potential consumers for whom existing technologies fail to meet their particular needs. The second is to identify existing customers where existing technologies are more technology than they needs. The final is to investigate potential consumers in terms of what Christensen’s theory describes as "jobs to be done" as a path to defining new products and services to perform these jobs. I must confess that I still find this path the least well articulated aspect of this theory.
Throughout this book, the authors start by recapping the essentials of Christensen’s theoretical arguments and proceed to develop the next level of operational detail it takes to transform strategic insights into execution details. If you’re an organization seeking to develop its own disruptive strategy, the authors here have worked out many of the next level questions and identified the supporting analyses and design steps you would need to answer and complete. The authors are clearly competent and talented consultants who are willing to share how they manage and do their work. Their hope, of course, is that many of you will conclude that you need their help to do the work. What is nice here, is that they are confident enough in their abilities that they are quite thorough in what they share. This volume is not a teaser; it’s complete and coherent. You could pretty much take the book as a recipe and use it to develop your project plans. On the other hand, the plans by themselves won’t guarantee that you can assemble a team with the necessary qualifications to execute the plan successfully.
The other thing that this book does quite nicely is identify the kinds of organizational support structures and processes that you would want to put in place to institutionalize systematic disruptive innovation.
Christensen and his colleagues are continuing to build a rich, systematic, theory of disruptive innovation. With roots in academic research, they are freely sharing their insights and their methods. The Innovator’s Guide to Growth is a solid workbook that will let you develop your own skill at doing disruptive innovation. Of course, the plan by itself won’t eliminate the need to gain the experience for yourself. But it’s a lot better strategy than to have to work everything out from scratch on your own.
by Jim McGee
October 17, 2008 at 2:44 pm · Filed under
Enterprise 2.0, KM, Social Media
Venkat Rao of Xerox recently introduced an important argument about the underlying differences between social media and knowledge management approaches inside the Enterprise. Here’s the way I described them at delicious. Both are worth a look, a read, and some thought.
by Jim McGee
August 27, 2008 at 10:46 am · Filed under
Change, Enterprise 2.0
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:
- Customizing an existing sales presentation for a meeting with a new prospect
- Designing the agenda and preparing materials for an internal brainstorming meeting
- Putting together the briefing materials for a quarterly business review meeting
- Analyzing and making sense out of a competitor’s recent pricing announcement
These micro-processes are characterized by:
- A small number of steps
- Ad hoc design created by the knowledge workers responsible for the process
- Loose definitions of the beginning and end of the process
- Loose notions of control, sign-offs, and approvals
- Technology-enabled, if at all, by email and office suite tools.
None of these processes were ever explicitly designed; they’ve evolved over time. The cumulative pain and productivity drag imposed by these processes is accepted as a fact of organizational life. While various technologies are offered up as ways out of the swamp, we need an overall improvement strategy to provide the necessary direction.
The appropriate strategy is readily available. It is the same strategy originally deployed by Frederick Taylor in improving the productivity of manual labor in factory settings. The late Peter Drucker summarizes this strategy nicely:
Taylor’s principles sound deceptively simple. The first step in making the manual worker more productive is to look at the task and to analyze its constituent motions. The next step is to record each motion, the physical effort it takes, and the time it takes. Then motions that are not needed can be eliminated; and whenever we have looked at manual work, we have found that a great many of the traditionally most- hallowed procedures turn out to be waste and do not add anything. Then, each of the motions that remain as essential to obtaining the finished product is set up so as to be done the simplest way, the easiest way, the way that puts the least physical and mental strain on the operator, and the way that requires the least time. Next, these motions are put together again into a "job" that is in a logical sequence. Finally, the tools needed to do the motions are redesigned. Whenever we have looked at any job-no matter for how many thousands of years it has been performed-we have found that the traditional tools are wrong for the task.
[Peter Drucker. "Knowledge worker productivity: The biggest challenge." California Management Review. V41, #2. Winter 1999. pp. 79-94.]
While the strategy of “go, look, think, improve” is sound, there are some challenges in translating it successfully to knowledge work. First, the outputs of knowledge work are fluid and ill-defined. We have no widgets of constant quality to anchor process improvements against. I’ve argued elsewhere that one of the distinguishing factors of knowledge work deliverables is achieving the necessary uniqueness in the end result (Crafting Uniqueness in Knowledge Work). Applied uncritically, Taylor’s approach can lead us to emphasize superficial uniformities over essential uniqueness. Before we can even hope to improve a knowledge work process, we need to define deliverables in a way that allows us to judge them to be of sufficient quality.
Second, many of the steps in knowledge work processes are invisible. For physical tasks, what we could observe was more than sufficient to identify places for improvement. Not so with knowledge work. Is the person banging away answering email more or less productive than the one reading the latest journal article? Is the all-day project status meeting more or less productive than a well-maintained project wiki and issue tracking system? How would you go about comparing project management approaches to decide? The challenge is to find ways to make the invisible more visible, to distinguish essential activities from peripheral, and to develop robust insights into mental work processes. For that later challenge, I’m planning on revisiting books like John Medina’ Brain Rules: 12 Principles for Surviving and Thriving at Work, Home, and School and Dan Ariely’s Predictably Irrational: The Hidden Forces That Shape Our Decisions.
Third, we need to understand how to market knowledge work improvement to knowledge workers. In the world of Frederick Taylor we could treat workers as experimental subjects to be manipulated. Not so with the knowledge workers who drive today’s economy. These are individuals with the discretion and autonomy to ignore our advice on principle or on a whim. They can’t be compelled; they must be persuaded, sold, and possibly seduced into modifying their behaviors. At the very least, we’re going to need to carefully rethink the skills and perspectives we want to have in our deployment efforts.
by Jim McGee
August 6, 2008 at 10:42 am · Filed under
Enterprise 2.0, Enterprise Social Computing, YouTube
All the people whose opinions I trust have been recommending Michael Wesch’s most recent effort, “An anthropological introduction to YouTube.” It’s a presentation he delivered in June at he Library of Congress. It will take you an hour, but it is definitely time and attention well spent. Wesch and his students are developing deep insights into the human dimensions and impacts of today’s technology innovations.
An anthopological introduction to YouTube
One point that Wesch emphasizes is the importance of “participant observation” as a research strategy in this domain. To grasp what these new social media mean for organizations and culture you have to get involved. Wesch’s work is an excellent entry point, but even that won’t really make sense until you try it yourself.
by Jim McGee
May 9, 2008 at 10:55 am · Filed under
2.0 Design Thinking, Enterprise 2.0, FASTforward08
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?
by Jim McGee
May 2, 2008 at 10:08 am · Filed under
Enterprise 2.0
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’s a somewhat better quality video at blip.tv. (although I can’t seem to successfully embed that here)
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:
by Jim McGee
March 27, 2008 at 9:59 am · Filed under
2.0 Design Thinking
Ed Felten at Freedom to Tinker has some interesting points to add to Bruce Schneier’s piece on “Security Mindset” that I posted about yesterday. Felten focuses on the notion of “harmless failures.” It provides still more reason to approach all systems design problems with an eye firmly fixed on the social context in which your technology will operate.
The Security Mindset and “Harmless Failures”
…Not all “harmless failures” lead to big trouble, but it’s surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.
To see why, consider the donotreply.com email story that hit the press recently. When companies send out commercial email (e.g., an airline notifying a passenger of a flight delay) and they don’t want the recipient to reply to the email, they often put in a bogus From address like donotreply@donotreply.com. A clever guy registered the domain donotreply.com, thereby receiving all email addressed to donotreply.com. This included “bounce” replies to misaddressed emails, some of which contained copies of the original email, with information such as bank account statements, site information about military bases in Iraq, and so on. Misdirected ants might not be too dangerous, but misdirected email can cause no end of trouble.
The people who put donotreply.com email addresses into their outgoing email must have known that they didn’t control the donotreply.com domain, so they must have thought of any reply messages directed there as harmless failures. Having gotten that far, there are two ways to avoid trouble. The first way is to think carefully about the traffic that might go to donotreply.com, and realize that some of it is actually dangerous. The second way is to think, “This looks like a harmless failure, but we should avoid it anyway. No good can come of this.” The first way protects you if you’re clever; the second way always protects you.
Which illustrates yet another part of the security mindset: Don’t rely too much on your own cleverness, because somebody out there is surely more clever and more motivated than you are.
by Jim McGee
March 26, 2008 at 11:01 am · Filed under
2.0 Design Thinking
Bruce Schneier is high on my list of smart people to pay attention to. His blog, Schneier on Security, always provides useful insights into the interplay between technology and people. Yesterday, he offered an interesting observation about what he labels “the security mindset.”
Schneier on Security: The Security Mindset.
….
Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.
SmartWater is a liquid with a unique identifier linked to a particular owner. “The idea is for me to paint this stuff on my valuables as proof of ownership,” I wrote when I first learned about the idea. “I think a better idea would be for me to paint it on your valuables, and then call the police.”
Really, we can’t help it.
This kind of thinking is not natural for most people. It’s not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don’t have to exploit the vulnerabilities you find, but if you don’t see the world that way, you’ll never notice most security problems.
…
I’d push his observations a bit farther. When you are designing and building systems that incorporate people and technology, you had better think about both how to make things work and about how things might fail.
Human systems are interesting and effective because they are resilient. Good designers allow for the reality of human strengths and weaknesses and factor both into their designs. Too many poor or lazy designers ignore or gloss over failure modes. How many project plans have you seen, for example, that assume no one on the project team will ever be out sick? And then management complains when the project fails to meet its deadlines.
There’s actually quite a lot of good material on failure in human/technology systems and how to compensate for reality. I’d recommend the following as good starting points:
The Logic of Failure, Dorner, Dietrich 
Normal Accidents, Perrow, Charles 
Success through Failure: The Paradox of Design, Petroski, Henry
To Engineer Is Human: The Role of Failure in Successful Design, Petroski, Henry 
Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Schneier, Bruce
by Jim McGee
February 19, 2008 at 11:31 pm · Filed under
Barriers, Enterprise 2.0, FASTForward '08
The theme at this year’s FASTForward conference is the “user revolution.” Don Tapscott gave a nod to Time Magazine’s selection of “You” as the person of the year in 2006 as part of his keynote Monday evening. References to Facebook, Flickr, and Wikipedia have been rampant throughout the general sessions and in hallway conversations. The question that remains unasked and, thus, unanswered is “how are things different inside the enterprise.”
One obvious difference is scale. Applications and services on the net have the entire population of net users to draw from. The 1/9/90 heuristic works nicely on the scale of the net as a whole. Inside the enterprise, the rule suggests that implementation efforts need to consciously manage participation and activity to compensate for the smaller population.
The second important difference arises from the need to manage participation within the enterprise rather than capitalize solely on “natural” participants. This collides with the aspects of the enterprise that substitute artificial order for natural order. Large-scale enterprises explicitly design roles and responsibilities to address task requirements in a controlled fashion.
While organizational researchers and designers have been pointing out the limitations of control thinking for much of the last 20-30 years (if not more), the reality in enterprises is that control remains central to enterprise DNA. While insightful folks like Andrew McAfee identify the importance of emergence in the successful uptake of Enterprise 2.0 technologies, I think they tend to downplay the barriers created by the reliance on control. When McAfee talks about the importance of culture in successful Enterprise 2.0 efforts, he is fundamentally talking about enterprises that have managed to move past classical models of control. What makes this such a challenge is the extent to which these models are unarticulated or regarded as axiomatic.
by Jim McGee
February 13, 2008 at 10:57 am · Filed under
Web 2.0
Here’s a 14 minute video interview with danah boyd, who’s been working on a Ph.D. for the past several years at the Berkeley School of Information. She’s focused on understanding social networks and their interplay with youth culture. The video is an excellent introduction to her work. I’ve found her blog, Apophenia, a source of regular insight into the interplay between people and technology. I characterize her as an enthnographer of digital culture. Although her primary focus has been on youth culture, her insights are worth factoring into your thinking about Enterprise 2.0. If nothing else, she’ll help you understand your future work force.
Discover Magazine video of moi
Last fall, I did an interview for Discover Magazine about my research. I still think that I look strange in video, but I figured others might appreciate it.
by Jim McGee
January 11, 2008 at 11:11 am · Filed under
Enterprise 2.0
We invite you to weigh in on the conversation you’re hearing or just heard by posting reactions to this blog post. (For those who are catching this post between 11-12 EST register here and tune in to the discussion.)
by Jim McGee
December 12, 2007 at 11:06 pm · Filed under
Enterprise 2.0
There are a variety of articles and papers that I continue to draw insight from and find myself recommending to others on a regular basis. I decided it would be a useful exercise to assemble them into one set of pointers, add a little bit of commentary, and make it available.
I limited myself to materials that were easily available on the web, which eliminated some some more obscure, academic, materials that you probably wouldn’t want to read anyway. I ended up with a dozen items that fall into two categories. The first group represents useful thinking about individual knowledge workers; the second about design principles relevant at the organizational and strategic level.
Design space for individual knowledge work
- “As We May Think” - Vannevar Bush. Peter Drucker coined the term “knowledge worker” in 1959. Bush set the framework for a knowledge worker’s day in 1945.
- “Structured procrastination” - John Perry. A somewhat different, but nonetheless useful take on how to best leverage a multi-tasking, multi-demand world.
- “You and Your Research” - Richard Hamming. Underlying strategies for how to set and follow a strategy for tackling worthwhile and rewarding problems. Although focused on research, the advice is readily applicable to all kinds of knowledge work.
- “Augmenting Human Intellect: A Conceptual Framework” - Doug Engelbart. Engelbart set an agenda for the use of technology for knowledge work that drove much of the conceptual innovation in software for the last several decades.
- “Personal Dynamic Media” (PDF file) - Alan Kay and Adele Goldberg. Along with Engelbart’s paper, Kay and Goldberg’s imagines much of the personal computing revolution and how we might best make use of technology in doing knowledge work.
Strategic and Organizational Design Principles
- “The nature of the firm” (PDF file) - Coase. Coase ultimately won a Nobel prize in economics for this work, which examines the conditions that differentiate between activities best organized by markets vs. those best organized by organizations.
- Cluetrain manifesto - Searls, Weinberger, Locke, Levine. The first, and still best, thinking about the ways that the internet affects markets and marketing
- “End to end arguments in system design” (PDF file) - Saltzer, Reed, & Clark. These guys were key designers of the underlying protocols that drive the internet. This paper lays out the reasons why centralized command and control is a bad idea in networks; regardless of how appealing it tends to be to the powers-that-be.
- “Rise of the stupid network - Isenberg. From a former phone industry software engineer, this paper provides an interesting examination of the interaction between technology change and organizational/strategic inertia.
- The long tail”- Anderson . The article that led to the book. Both offer insight into the opportunities to design products and services that take advantage of how the net offers alternatives to mass markets.
- “Places to intervene in a system” - Meadows. The changes we need to make to take full advantage of the opportunities that technology presents us depend on thinking and operating at a systems level. This is the best short overview of the leverage points that can be found and used to make this level of change happen.
- “Wicked problems and social complexity” (PDF file) - Conklin. As a counterbalance to Meadows, Conklin enriches the discussion of systems change by laying out the notion of “wicked problems.” These are the kinds problems whose solutions arise from the interaction between competing interest groups and change the definition of the problem as they are implemented.
by Jim McGee
November 21, 2007 at 10:49 am · Filed under
Enterprise 2.0
The conversation about technology and organizations has been enriched with a new blog, Difference Engine, by my long-time friend and colleague, Abbie Lundberg. Of course, as Editor in Chief at CIO Magazine, we’ve been benefiting from her perspective and insight for years. Now, we’ll get it a bit less filtered and a bit more personal. I’m looking forward to it. Here’s a quick sample:
As the debate over the CIO role rages on, we wonder which is the most critical skill set: business, technology or, as some argue, the ability to detect bullshit?
The debate about the best background for CIOs isn’t new. It’s been going on since the mid ‘90s, when Johnson & Johnson first appointed a CIO from “the business,” without hands-on IT experience. The argument goes something like this: Technology is becoming an increasingly integral part of business; ergo, CIOs have to be business strategists. So far so good. But then some people continue the argument to say that because business knowledge and ability is so important, technology knowledge isn’t. False!
…
So what do you think? Can you be a truly great CIO without a pretty deep understanding of technology? Does the merging of business and technology make technology knowledge more or less valuable to the individual leading strategic IT?
The Most Critical Attribute of a CIO | Advice and Opinion.
by Jim McGee
October 16, 2007 at 11:33 am · Filed under
Enterprise 2.0
Andrew McAfee’s Sloan Management article defining Enterprise 2.0 is available for download, so I took the opportunity to reread it, after a recent chat over coffee with Jordan Frank of Traction Software.
Enterprise 2.0 is Now Free
The article, at least. MIT Sloan Management Review, with support from IBM, is making a set of ‘classic’ (thanks!) articles freely available to all comers. So the full text of my original SMR article “Enterprise 2.0: The Dawn of Emergent Collaboration” can be downloaded here.
I don’t know if this is a temporary or permanent arrangement, so I’d suggest acting quickly.
One of McAfee’s central arguments is on the importance of emergence in successful Enterprise 2.0 initiatives. Here’s the way he puts it:
Second, the technologists of Enterprise 2.0 are trying hard not to impose on users any preconceived notions about how work should proceed or how output should be categorized or structured. Instead, they’re building tools that let these aspects of knowledge work emerge.
This is a profound shift. Most current platforms, such as knowledge management systems, information portals, intranets and workflow applications, are highly structured from the start, and users have little opportunity to influence this structure. Wiki inventor Cunningham highlights an important shortcoming of this approach: “For questions like ‘What’s going on in the project?’ we could design a database. But whatever fields we put in the database would turn out to be what’s not important about what’s going on in the project. What’s important about the project is the stuff you don’t anticipate.” [p.25]
In an accounting or ERP system, the system’s designers specify all aspects of workflow, database design, and information structure in advance. Users are expected to select from among pre-defined choices and enter only such data as the designers have provided for. In designing a system for emergence, the designers leave a number of these decisions open; waiting for users to fill in the blanks. So, for example, instead of locking down a taxonomy for categorizing documents, the designers might provide a tagging system to allow a folksonomy to emerge from the idiosyncratic choices of each user.
The attraction of emergence is twofold. One is the realization that conventionally structured approaches have generally failed when tackling knowledge intensive problems. Knowledge work and knowledge workers don’t mesh well with the structuring techniques appropriate to industrial work.
The second is the perceived success of emergent approaches behind current Web 2.0 success stories on the Internet. It’s easy to see the power of emergence in such examples as flickr, facebook, and technorati.
Transplanting those experiences inside the boundaries of the organization is no simple task. What works at the scale of the public internet may not generate sufficient momentum within the confines of a single organization. Moreover, Internet success stories ignore or gloss over the failures and also-rans. Failure in the market is tolerated in ways that don’t translate well inside organizations.
You want the energy and creative outcomes that can come from a successful emergent approach, but you can’t simply rely on unaided market forces to fuel the process. “Unaided” is the key notion. Emergent successes in the market benefit from scale and viral strategies, but they don’t happen by accident. For starters, there is a marketing strategy and plan that exists in parallel with a technology implementation plan.
Enterprise 2.0 efforts within organizations also need a marketing plan to accompany their implementation plans. Like any marketing plan, this plan must identify and characterize its target market of potential users. In particular, the plan needs to identify those potential users who are most likely to benefit from the new capabilities and whose successful use of the technology will be interpreted as an endorsement to be emulated.
Is a marketing plan, by itself, sufficient to allow the other aspects of an Enterprise 2.0 implementation to emerge from use? Appropriate scaffolding and careful seeding of content will prove more useful. A complete taxonomy, for example, may overwhelm a small set of potential early adopters. On the other hand, an empty tagging system will prove too much of a blank slate for users more accustomed to the structures of conventional systems. Providing a sample of suggested tags or categories coupled with some live content can point users in the right direction.
Supporters and early adopters will also benefit from coaching and mentoring on how to use selected technologies to accomplish their goals. This coaching would focus on working out strategies for how to use the technology to accomplish specific business and organizational goals. This requires a different kind of engagement between the implementation team and the target user group. In particular, it entails introducing the user population to key design questions and issues that would typically have been dealt with by the implementation team.
In some respects, “emergence” is a fancy organizational development word for “messy.” The more our systems must deal with the complexities of the real world, the messier they must be to accommodate that messiness. Large scale organizations in general, and IT organizations in particular are not generally comfortable with messiness. Calling it emergence helps. But the fundamental need is to acknowledge that it is more useful to learn as we go and build our systems accordingly, than it is to force fit these systems into structures that cannot contain them.
by Jim McGee
August 15, 2007 at 10:55 am · Filed under
Enterprise 2.0
Greg Lloyd at Traction Software also picks up on the same JP Rangaswami post that I did yesterday. He offers several additional examples of the value of making knowledge work visible as a simple tool for supporting on the job learning. Here’s one of his many useful insights. Go read the rest.
Learn by watching - Then do
Learn by watching - Then do
Blog446: August 14, 2007 7:22:00 PM EST, Posted by Greg Lloyd
…
Each project’s serial file was nothing fancy. Usually it was a few file drawers with incoming and outgoing correspondence, briefing slides, q&a memos, contract actions and meeting notes, all top bound in chronological order - full contracts, formal specs and other deliverables were filed separately. In pre-email days, the project serial file was a pretty accurate snapshot of our interactions with the outside world interleaved with internal notes and memos. We all kept our own date stamped lab notebooks for private jottings.
A day or so of close reading and the chance to ask a few pointed questions to the original project engineer (”You said WHAT to Captain K??”) usually got us up to speed on the pulse of each project - not just the formal status and deliverables. We learned to use the project file to refresh our memory on details before and important meeting or decision - or just to reflect and review the bidding. We learned to use each other’s project files to keep track of dependencies and learn how to handle problems. …
…
I know that an electronic form of serial file can replace the old paper trail, since that’s what I use every day. The TeamPage blog + wiki tool lets everyone look over my shoulder - and vice versa - as we tear off in different directions and do our work as individuals or teams.
I rarely need to read any one project in real time, but I know that I can come up to speed quickly, search across all projects, and dive in if I need to. If someone asks for help or sees an opportunity, they can post it if it’s not urgent; add a tag to anything that needs quick action; or IM a permalink if they need me to look at something now. What I can do, all of Traction’s employees can do - only the “Board of Directors” project is private. Board pages or posts - including monthly financials - are cross-tagged to make them visible to all hands when the dust settles.
There are days when I wonder whether one of the fundamental impediments to the take up of blogging and wikis within organizations is, in fact, their utter simplicity.
by Jim McGee
August 14, 2007 at 12:11 pm · Filed under
Enterprise 2.0
One of the recent additions to my feed subscriptions is Confused of Calcutta by JP Rangaswami. Recently, he’s been thinking about Facebook and its potential role in Enterprise settings. Today’s installment has an interesting riff on the nature of knowledge management. It dovetails nicely with some of the things I’ve had to say about visibility and knowledge work.
Facebook and the Enterprise: Part 5: Knowledge Management
…
Knowledge management is not really about the content, it is about creating an environment where learning takes place. Maybe we spend too much time trying to create an environment where teaching takes place, rather than focus on the learning.
Since people want to learn by watching others, what we need to do is to improve the toolsets and the environment that allows people to watch others. It could be as simple as: What does my boss do? Whom does she talk to? What are her surfing habits like? Whom does she treat as high priority in terms of communications received? What applications does she use? Which ones does she not use? When she has a particular Ghost to deal with, which particular Ghostbuster does she call?
…
