I’ve finally gotten around to the following TED video that’s been queued up in my "to read/watch" stack. In it, Sugata Mitra describes his "Hole in the Wall" experiments that placed internet connected PCs into New Delhi slums and watched what happened. It’s worth 20 minutes of your time.

(Video Link)

Mitra’s conclusion is that you can get a lot of learning for very little investment, particularly in the trappings of formal education that we tend to take for granted. People are wired to learn and appear to do so best in small groups of like-minded learners. They need access to resources and encouragement. They don’t particularly need someone more expert to guide them; their natural curiosity works as well or better. Mitra’s view is that education is best treated as a self-organizing system.

Digging into how learning works versus how we naively think it works is important in the world we find ourselves in. Individually and organizationally, we are faced with ongoing challenges to learn. Neither we nor our organizations can afford the necessary learning time if it has to be in the form of conventional settings. Following the threads worked for the kids in Mitra’s experiments. We need to follow a similar path. We also need to experiment with integrating those learning paths into the demands of day-to-day work.

I’ve been thinking a lot about hard problems that need multiple people collaborating to solve. There’s no shortage of them to choose from.

This TED video from Jane McGonigal makes a persuasive case that I need to invest some more time looking at the world of online gaming for insight. Watch the video  and see if you don’t come to a similar conclusion.

]]> http://www.fastforwardblog.com/2010/11/16/collaboration-games-and-the-real-world/feed/ 0 http://www.fastforwardblog.com/2010/09/20/finding-knowledge-work-practices-worth-emulating-and-adapting/ http://www.fastforwardblog.com/2010/09/20/finding-knowledge-work-practices-worth-emulating-and-adapting/#comments Mon, 20 Sep 2010 13:30:35 +0000 Jim McGee http://www.fastforwardblog.com/2010/09/20/finding-knowledge-work-practices-worth-emulating-and-adapting/

How might we best go about improving knowledge work, both practices and outputs, in today’s complex organizational environment? Are there paths other than simple trial and error that might lead to systematic gains?

Frederick Taylor and his followers built their careers on finding the one best way to carry out a particular physical task. Later proponents of this way of thinking transferred their approach to defining the one best way to carry out information processing tasks. John Reed of Citibank launched his career by applying factory management principles to automating check handling. Reengineering essentially rebooted these approaches for a richer technology environment, but held to the premise that outputs were a given, tasks could be well-defined, and processes could be optimized.

Peter Drucker, in his typical way, pointed out that the key to understanding and improving knowledge work (PDF) was that there was no defined task to be optimized. Knowledge workers start by defining the task at hand and an output of suitable quality. This is not an approach which lends itself to conventional improvement or optimization approaches.

Two useful approaches come to mind. One would be to identify and shadow individual knowledge workers deemed to be particularly effective. Observing, understanding, and emulating their personal practices would be time well spent. A second approach would be to identify a class of knowledge workers who have been dealing with the problems of knowledge work in the modern enterprise long enough to have developed practices and approaches that might be broadly adaptable to knowledge work activities in general.

Both of these approaches are well worth undertaking. Today, I’d like to take a look at this second approach. A recent blog post by Eric Raymond prompts looking at a group I’ve often thought of as the leading edge of modern knowledge work– software developers. Over the last half-century, this group has been inventing and developing the technological infrastructure that shapes our modern enterprises. As such, they have been the first to encounter and address the challenges of knowledge work. Certainly any group responsible for the Internet and the invention of open-source software will have lessons for the rest of us as we try to bring forth our own examples of knowledge work products.

Raymond, among many other things, is the author of the excellent The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. He also maintains the always interesting and provocative blog Armed and Dangerous. In a recent post, "the social utility of hacker humor", Raymond dives into the number of the behavioral norms that he believes characterize hackers and software developers. The entire blog post is well worth your time, but let me call your attention to the following excerpt:

…every once in a while something erupts out of them that is a game changer on a civilization-wide level. Two of the big ones were the Internet and open-source software. These two movements were intimately intertwined with hacker culture, both produced by it and productive of it. The origins of our tribe go back a bit further than either technology, but we have since re-invented ourselves as the people who make that stuff work.

And I don’t mean “make it work” in a narrow technical sense, either. As long as there are people who laugh at INTERCAL and RFC1149 and the Unix koans of Master Foo, and recognize themselves in the Jargon File, those same people will care passionately that computing technology is an instrument of liberation rather than control. They won’t be able to help themselves, because they will have absorbed inextricably with the jokes some values that are no joke at all. High standards of craftsmanship; a subversive sense of humor; a belief in the power of creative choice and voluntary cooperation; a spirit of individualism and playfulness; and not least, a skepticism about the pretensions of credentialism, bureaucracy and authority that is both healthy and bone-deep.

[Raymond, Eric S. Armed and Dangerous. "The social utility of hacker humor"]

Substitute "knowledge worker" for "hacker" and I believe we will find parallels worth exploring.

This is still in the working hypothesis stage. I can think of a number of practices that might prove worth emulating and some useful entry points into learning more.

Practices worth investigating

Serious software developers have adopted a number of practices as they’ve struggled with the challenge of designing, developing, and evolving products that are pure thought stuff. To the extent that knowledge work is also a process of developing outputs that are themselves largely thought stuff, these practices ought to have analogues. Here’s a preliminary list, in no particular order.

• Version control/source code control. Final outputs and products grow through a process of successive refinement.  "Track changes" in MS Word seems inadequate to the task as do informal conventions on controlling successive iterations of final output documents.
• Issue Tracking/Bug Tracking. With multiple cooks and multiple tasters, the review processes of getting from a possible finished product to a definitive finished product revolves around identifying and systematically addressing both feedback and proposed responses from a multitude of sources. Software developers have invested in tools and processes to support that inevitable process; why not translate that process to the equivalent process of vetting a final report?
• Agile Development Practices. The software world has long struggled with managing the process of getting from germ of an idea to finished product in a finite amount of time. They’ve tried and generally abandoned a variety of approaches (like the waterfall model) that pretend to turn a fundamentally iterative and evolutionary process into a faux-linear process. Their processes now accept this iterative reality at the same time that other knowledge work fields like the law are discovering old ideas of project management that have been abandoned because they don’t and can’t work on knowledge process outputs. Can’t we shorten the learning curve given that we know how it played out before?
• D.R.Y. – Don’t Repeat Yourself is a heuristic that software designers and developers have employed to excellent effect in multiple settings. It rarely applies directly to final delivered systems; rather it’s a process of seeking and finding common subsystems and repetitive activity sequences that can be carved out and solved in a general way that can be applied across future efforts. What pieces of our knowledge work efforts are we repeating to no useful purpose?
• Modules not Monoliths. You eat elephants one bite at a time and you solve big, complicated, problems by breaking them into more manageable pieces. The software development world has followed this logic to a fare-thee-well. A typical webpage is built by assembling pieces from multiple sources on the fly. Meanwhile, the typical consulting report is still a single giant Word or PowerPoint file that overwhelms the typical email system when mailed to a client.

Some sources of ideas

Here’s a quick list to some further reading that looks promising:

• The Design of Design: Essays from a Computer Scientist, Brooks, Frederick P., Jr.
• The Mythical Man-Month : Essays on Software Engineering, Brooks, Frederick P., Jr.
• F.P., Jr. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering," Computer, pp. 10-19, April, 1987. This is a chapter in the 25th Anniversary Edition of The Mythical Man-Month but a little searching will find copies of the original article by itself.
• Open Sources: Voices from the Open Source Revolution (O’Reilly Open Source), Dibona, Chris
• Producing Open Source Software: How to Run a Successful Free Software Project, Fogel, Karl
• The Pragmatic Programmer: From Journeyman to Master, Hunt, Andrew
• Ship it! A Practical Guide to Successful Software Projects, Richardson, Jared
• Coders at Work, Seibel, Peter
• The Psychology of Computer Programming : Silver Anniversary Edition, Weinberg, Gerald M.
• Manifesto for Agile Software Development

Where do we go from here?

Some next questions on my mind worth exploring:

1. What can we do to pursue this path more systematically?
2. What other practices are worth investigating?
3. How best do we translate practices from the development world to the broader world of knowledge work?

My post on the visibility of knowledge work generated some some excellent comments and excellent blog posts around the web. For my own benefit I wanted to gather up what I’ve come across so far and put it in one place.

Recap

Greg Lloyd, CEO at Traction Software, kicked things off. pulled together some key threads of the conversation and gave us a better label – “observable work.” His initial summary:

I believe that principles of open, observable work – like open book financial reporting to employees – is a simple and powerful principle that people at every level of an organization can become comfortable using. In my opinion, wider adoption of observable work principles can succeed with support and encouragement from true leaders at every level of an organization – as Peter Drucker defines that role: “A manager’s task is to make the strengths of people effective and their weakness irrelevant–and that applies fully as much to the manager’s boss as it applies to the manager’s subordinates.” Enterprise 2.0 and Observable Work

Greg also pointed to an excellent post by John Tropea at Library Clips:

why do I have close to total awareness of people in my personal life that requires low effort, but yet in the workplace I don’t have this ambient awareness!

In fact it may be more crucial to have micro-blogging/activity stream networks in the workplace as we share and work on the same/similar/related goals and tasks within our teams, across teams, workgroups, and enterprise wide…so the more we are aware, the more we can be on the same page, and have better coordination, cooperation and collaboration…surface opportunities (emergence), have the best people on the right tasks, and generally have the ability to be more responsive and adaptive.� Ambient awareness is the new normal, c’mon already!

Mary Abraham raised a cautionary voice:

I found myself saying “TMI” when I first read a terrific set of posts by Jim McGee, John Tropea and Jack Vinson regarding the benefits of information transparency among knowledge workers and the importance of making knowledge work more visible. Granted, I was “catastrophizing” as I imagined a workplace where every thought was expressed in writing before it could be edited for appropriateness or sense. I imagined my daily e-mail deluge multiplied many times over once I moved from messages directed at me to a stream messages directed to the entire firm.� I imagined a tsunami of triviality swamping me daily as I struggled to be productive. I imagined having to hide myself in a technology free cave in order to get any work done. TMI

There is excellent commentary attached to each of these posts.

Other related posts and observations that have found there way into my filters include:

• Observable Work: The Taming of the Flow
• Invisible work – spray paint needed

Foundations

Like Greg Lloyd, I would highly recommend becoming more familiar with Doug Engelbart and his body of work. Greg provide an excellent starting point with his post on Traction Roots – Doug Engelbart.

It’s also well worth taking a look at Dave Winer’s work and thinking in this arena. The following two links are good entry points to his efforts:

• Narrate Your Work
• Before There Was Twitter, There Was Dave Winer’s Instant Outliner

Paths Forward

I’m greatly encouraged by the discussion and debate we’ve already triggered. Greg suggested #owork as a useful twitter tag to follow these discussions. Here are some questions and ideas that i think are worth pursuing. Please feel free to join in the discussion and the effort as it unfolds;

• What can you do to make your own work more readily observable?
• How might making your work observable be immediately beneficial to you, even if no one else bothered to pay attention?
• Who else benefits if your work is more observable?
• How do you benefit from others making their work more observable?
• What risks and challenges do you need to manage as you make your work more observable?

Cognitive Surplus: Creativity and Generosity in a Connected Age, Shirky, Clay

Anyone who can use lolcats to make a relevant and provocative intellectual point is worth paying attention to. Clay Shirky pulls it off in his latest book. Here’s his point:

Let’s nominate the process of making a lolcat as the stupidest possible creative act…. The stupidest possible creative act is still a creative act. [p.18]

Cognitive Surplus is a follow on to Shirky’s previous book, Here Comes Everybody: The Power of Organizing Without Organizations. In it, he explores the following thesis:

Imagine treating the free time of the world’s educated citizenry as an aggregate, a kind of cognitive surplus. How big would the surplus be? To figure it out, we need a unit of measurement, so let’s start with Wikipedia. Suppose we consider the total amount of time people have spent on it as a kind of unit – every edit made to every article, and every argument about those edits, for every language that Wikipedia exists it. That would represent something like one hundred million hours of human thought….One hundred million hours of cumulative thought is obviously a lot. How much is it, though compared to the amount of time we spend watching television?

Americans watch roughly two hundred billion hours of TV every year. That represents about two thousand Wikipedias’ projects’ worth of free time annually….One thing that makes the current age remarkable is that we can now treat free time as a general social asset that can be harnessed for large, communally created projects, rather than as a set of of individual minutes to be whiled away one person at a time. [pp.9-10]

Shirky takes this notion and uses it as a lever to pry beneath the surface of lolcats, the Apache project, PatientsLikeMe.com, and other examples to look for something beyond the obvious. What makes it work is Shirky’s willingness to stay in the questions long enough to see and articulate deeper linkages and possible root causes.

One of the things that makes this work is that Shirky understands technology well enough to distinguish between accidental and essential features of the technology (to borrow a notion from Fred Brooks). Where this ultimately leads him is away from technology to look deeper into human behavior and motivation.

Like everyone else who’s been paying attention, Shirky turns to the wealth of insights coming out of the broad area of behavioral economics to understand why so much of the what is apparently surprising about today’s technology environment rests in our crappy assumptions about human behavior. As he argues in a chapter titled "Opportunity" when we find new technology leading to uses that are "surprising," the surprise is located in an assumption about behavior and motivation rooted in an accident of history not a fundamental attribute of the human animal. For example, he neatly skewers both the RIAA’s and the techno-utopians analyses of Napster and concludes:

The rise of music sharing isn’t a social calamity involving general lawlessness; nor is it the dawn of a new age of human kindness. It’s just new opportunities linked to old motives via the right incentives. When you get that right, you can change the way people interact with one another in fairly fundamental ways, and you can shape people’s behavior around things as simple as sharing music and as complex as civic engagement. [p.126]

For those of you who prefer your arguments condensed for more rapid consumption, Shirky provides one in the following TED talk

(Clay Shirky at TED)

Shirky has his detractors. There are those who dismiss him as just another techno-utopian who imagines a world at odds with the practical realities of the day. At the level of a 20 minute keynote speech, that’s not an unwarranted takeaway. When you give his arguments a deeper reading, I think you’ll more likely to conclude they are worth your investment in wrapping your head around them.

Related articles by Zemanta

Debates over whether the Internet is making us smart or stupid are entertaining in the bar and can serve as a pleasant background noise for ruminating during a keynote address in a dimly lit hotel ballroom. When I get back to work on Monday (or more likely on Sunday night) I return to the reality of working in a fundamentally digital environment. My files are digital, my tools are digital, and most of my interactions are digital.

As a knowledge worker, much of what I get paid for happens inside my own head. Before the advent of a more or less ubiquitous digital environment, however, that head work used to generate a variety of markers and visible manifestations. That visibility was important in several ways that weren’t evident until they disappeared:

• Seeing work in progress in front of me made it possible to gauge my progress and make connections between disparate elements of my work.
• Different physical representations helped to quickly establish how baked a particular idea was.
• Physically shared work spaces supported rich social interactions that enriched the final deliverables and contributed to the learning of multiple individuals connected to the effort.

For all the productivity gains that accrue to the digitization of knowledge work, one unintended consequence has been to make the execution of knowledge work essentially invisible, making it harder to manage and improve such work. The benefits of visibility are now something that we need to seek mindfully instead of getting them for free from the work environment.

Knowledge work is better understood as craft work; its products are valuable because they are creative and original. Delivering identical consulting reports to different clients is grounds for a lawsuit, not an example of good knowledge management practice.

From a craft perspective, examining and understanding what constitutes a quality client report, for example, is an important part of the apprenticeship that transforms a recently minted MBA into a seasoned advisor. The visibility or invisibility of knowledge work products can make this process more or less difficult.

Before PowerPoint, crafted presentations began with a pad of paper and a pencil. You knew by looking at a roughed-out set of slides that it was a draft; erasures, cross outs, and arrows made that more obvious. You then took your draft to the graphics department, where you were yelled at for how little lead time you provided. A commercial artist tackled your incomprehensible draft spending several days hand-lettering text and building your graphs and charts.

From there you started an iterative process, correcting and amending your presentation. Copies were circulated and marked up by your manager and hers. Eventually, the client got to see it and you hoped you’d gotten things right.

Work was visible throughout this old-style process. Moreover, that visibility was a side effect of the work’s physicality. Junior members of the team could see how the process unfolded and the product evolved. You could see how editors and commenters reacted to different parts of the product. Knowledge sharing was a free and valuable side effect of processes that were naturally visible.

With e-mail, word processors, spreadsheets, and presentation tools, maintaining visibility of your knowledge work (at both the individual and workgroup level) requires mindful effort. An office full of papers and books provided clues about the knowledge work process; a laptop offers few such clues. A file directory listing is pretty thin in terms of useful knowledge sharing content. In an analog process, it’s easy to discern the history and flow of work. When an executive takes a set of paper slides and rearranges them on a conference room floor, a hidden and compelling story line may be revealed. You can see, and learn from, this fresh point of experience. That’s lost when the same process occurs at a laptop keyboard at 35,000 feet. The gain in personal productivity occurs at the expense of organizational learning.

In the digital process, who creates and what they contribute risks becoming more an exercise in political posturing and interpretation than simple observation. The abstracts in a document management system reveal little about what work is exemplary, new, or innovative, and obscures emerging patterns.

Invisibility is an accidental and little-recognized characteristic of digital knowledge work. Seeing the problem is the first step to a solution. While better technology tools will play an important role, the next steps are changes in attitude and behavior at the individual and work group level. For example, organizing your own digital files into project-related directories might help, but not if you continue to name files "FinalPresentationNN.doc" where NN is some number between 1 and 15 representing a crude effort at version control. Embed more information in the file name where you know it will be visible even as you e-mail it around the organization. Use more informative subject lines on your email. Those file names and subject lines should provide the best clues possible as to what will be found inside.

Systems developers have learned that time invested in naming standards and conventions pays off. Teams crafting knowledge-work products should make the same investments. Better yet, spend time with good development teams and look for ways to adapt their practices to more general-knowledge work.

New disciplines take time to become habits. Fortunately, they also eventually become "the way we do work here." As the disciplines take root, taking a more aggressive look at technology tools becomes appropriate. Many of the office suite tools offer some form of internal revision tracking or auditing tools. What’s missing is any systematic way to integrate these tools into a disciplined practice. The capabilities are there but they are irrelevant if they aren’t used intelligently. A version control system doesn’t do anything until you incorporate it into the routine practice of creating a new document.

The right starting point is to simply make the flow of work more visible. I suspect that this is one of the underlying attractions of social networking and micro-blogging. They promise to restore some visibility to digital team work that we lost in the first generation of tools.

If visibility is, indeed, important to effective knowledge work what else would you recommend as ways to manage and increase the visibility of the intermediate and end products of knowledge work and the people-to-people interactions that take place in cerating those products?

Thought leadership risks becoming an empty marketing phrase just as it becomes essential to long term success. In an idea economy more and more firms understand the importance of getting credit for being on the leading edge, but getting credit is best preceded by actually being there. Organizations that depend on generating and exploiting ideas need to become more systematic about integrating thought leadership into their operating principles and practices not just their marketing.

Value of thought leadership

How many of today’s successful organizations are built on top of better ideas? Some, like FedEx or Southwest Airlines, were built on top of a powerful core idea. Others, like Amazon or Apple, were built on a powerful core plus ongoing extension and elaboration of that core with new ideas. Still others, like the best professional services firms, depend on a steady stream of new ideas.

If you’re fortunate enough to come up with a FedEx or Southwest quality idea, ongoing thought leadership isn’t much of an issue and you can focus your organizational energies on execution. On the other hand, if you’re in an organization or industry where the half-life of ideas is continuing to shrink, then you need a more explicit strategy than waiting for the next flash of entrepreneurial genius.

There have been many attempts to make thought leadership more manageable. These range from the full fledged research labs of large organizations (e.g.,  Xerox PARC, Microsoft Research, IBM Research, Bell Labs) to various research centers in professional services firms (e.g., Deloitte Center for the Edge, McKinsey Global Institute, Accenture Global Research).

Most of these examples separate research from practice and model themselves along academic lines. While they often produce excellent work and contribute to the overall market reputation of their parent organizations, they have been less successful at leveraging the experience of their parents or at feeding their insights back into their organizations. These examples also stamp thought leadership as a luxury available only to the largest and most successful organizations.

Where we went off track

While we can recognize the value of thought leadership as a component of innovation and of attracting new customers, we’ve had less success in transforming thought leadership into something systematic and manageable. While the end products of thought leadership are attractive, they shed limited light on what practices contribute to those end products.

Thought leadership presents a situation where working backwards isn’t helpful. Seeing the marketing and reputational value of a published article, senior executives will call their Chief Marketing Officers and order an article for the next issue of the Harvard Business Review. Wise CMOs, recognizing that this request has not come from someone named Gates, or Buffet, or Welch, will negotiate a more plausible timeline, identify some plausible topics, and search for potential authors within the organization.

With a great deal of luck and effort, this approach might yield an article in a year or so. Successful or not, marketing has now come to own the thought leadership problem. If the focus remains on the end products, which is likely, marketing will pursue opportunities to create materials that can easily be used as marketing and sales collateral. Perhaps they will enlist help from customer service or training groups to leverage their materials as input to the process as well.

This is a classic confusion of form over substance. At an extreme, we see such nonsense as Gartner Group trumpeting TLM (thought leadership marketing) as the next frontier for IT services marketing. Somewhat more sensibly, we see a variety of marketing and PR consultants pushing thought leadership as a key marketing strategy. Some good recent examples include:

• Leadership guru Ken Blanchard talks about his views on thought leadership
• Thought leadership is still dead; long live idea marketing

Getting back on track

Whatever the marketing value of thought leadership, it is secondary to the operational value of increasing the effectiveness of how an organization learns from and disseminates practice. When you recast thought leadership as a core operating principle instead of ancillary marketing program, several implication follow. First, it changes what you recognize as relevant data. Second, it changes the kinds of support you provide to your front line practitioners. Finally, it shapes the practices you promote among your workforce.

Where you see data

A survey of current customers or prospects often passes for data in faux thought leadership attempts. Or, a few thin paragraphs passing as a case study. The insights that fuel real thought leadership flow from the interaction of rich data and penetrating questions. Those are typically found at the edges of current practice.

Organizations will find their richest data in the histories and traces of those projects that challenge their capabilities and are placed in the hands of their most adept staff. It’s often difficult to know in advance which projects will fall into this category. More often, it’s easier to predict that certain efforts will likely be routine.

How you support the field

The best time to collect this rich field data is as it’s being generated. The greater the delay between action and reflection, the more that real insight is displaced by revisionist history. Organizationally, you can provide systems and tools that make it simpler to capture and catalog working papers and work products as they are created. Second, organizations can set aside the time and create expectations that professionals will reflect on their work as they perform it.

What practices make a difference

Despite the fervent wishes of bureaucrats, the kind of reflection and learning from practice that fuel meaningful thought leadership won’t map into standard operating procedures or fixed processes. It is much more fruitful to think in terms of practices to encourage. At the team level, for example, After Action Reviews are a simple practice to amplify learning among the team.

Individual practices can range from debriefing a meeting over a beer to maintaining a journal of questions and reflections. The journal could be as simple as a Moleskine notebook or as extensive as a private blog.

Payoff to knowledge workers and their organizations

Treating thought leadership as a marketing responsibility does create organizational value, but at a significant cost in terms of effort and disruption within the organization. Marketing staff need the full support and participation of those line contributors generating the experience on which thought leadership must be based but if they drive thought leadership efforts from their immediate needs they risk alienating those on whom they most depend with requests for substantial incremental work.

On the other hand, treating thought leadership as an operating principle better aligns the demands on those core contributors. Now, rich, high quality input to thought leadership efforts are relevant components of ongoing work. Moreover, this approach enhances individual and organizational learning as a primary goal; thought leadership becomes a valuable side effect of doing work, instead of being an onerous additional requirement.

Professionals grow and develop through reflective practice. They build and test mini-theories of how their actions lead to outcomes. In a simpler world, that reflection was built on the slow accretion of experience. In today’s world, it is more effective to build on a foundation of explicit reflection.

Seizing the White Space: Business Model Innovation for Growth and Renewal, Johnson, Mark W.

What is a "business model" and can you create a new one in a systematic and disciplined way? That’s the question that Mark Johnson, chairman of the consulting firm Innosight, sets for himself in Seizing the White Space.

The term entered the popular business lexicon during the dotcom boom in the late 1990s. There wasn’t any particular definition behind the term at the outset. Effectively, it was shorthand for the answer to question zero about any business – "How are we planning to make money?" Before the dotcom boom, nine times out of ten, the answer was "we’ll copy what Company X is doing and execute better than they do." During the boom, the answer seemed to be "we have absolutely no idea, but it’s going to be great." Now we recognize that both of those answers are weak and that we need some theory to design answers that are likely to be successful.

Over the last decade and a half, there’s been a steady stream of excellent thought and research focuses on building that theory. One of the major tributaries in that stream has been the work of Clay Christensen on disruptive innovation. Christensen and his colleagues, including Johnson, have been engaged in a multi-year action research program working out the details and practical implications of the theory of disruptive innovation. Seizing the White Space is the latest installment in this effort and is best understood if you’ve already invested in understanding what has come before.

Johnson starts with a definition of white space as

the range of potential activities not defined or addressed by the company’s current business model, that is, the opportunities outside its core and beyond its adjacencies that require a different business model to exploit

p.7

Why do organizations need to worry about white space? Even with success at exploiting their current business model and serving existing customers, organizations reach a point where they can’t meet their growth goals. Many an ill-considered acquisition has been pursued to plug this growth gap. Haphazard efforts at innovations to create new products or services or enter new markets get their share of the action.

Johnson combines an examination of white space and business models in an effort to bring some more order and discipline to the challenge of filling those growth gaps. One implication of this approach is that the primary audience for his advice is existing organizations with existing successful business models. He is less interested in how disruptive innovation processes apply in start up situations.

Johnson’s model of business models is deceptively simple. He illustrates it with the following diagram:

Johnson expands the next level of detail for each of these elements. Most of that is straightforward. More importantly, this model places its emphasis on the importance of balancing each of these elements against the others.

In the middle third of the book, Johnson takes a deeper look at white space, dividing it into white space within, beyond, and between which correspond to transforming existing markets, creating new markets, and dealing with industry discontinuity. It’s a bit clever for my tastes, but it does provide Johnson with the opportunity to examine a series of illuminating cases including Dow Corning’s Xiameter, Hilti’s tool management and leasing program, Hindustan Unilever’s Shakti Initiative, and Better Place’s attempt to reconceptualize electric vehicles. While the organization of the stories is a bit too clever, it does serve a useful purpose. It takes a potentially skeptical reader from the familiar to the unfamiliar as they wrap their heads around Johnson’s ideas.

With a basic model and a collection of concrete examples in hand, the last third of the book lays out an approach to making business model innovation a repeatable process. This process starts from what has evolved into a core element of Christensen’s theories – the notion of "jobs to be done." This is an update on Ted Levitt’s old marketing saw that a customer isn’t in the store to buy a drill but to make a hole. The problem is that most established marketers forget Levitt’s point shortly after they leave business school and get wrapped up instead in pushing the products and services that already exist. "Jobs to be done" is an effort to persuade organizations to go back to the necessary open-ended research about customer behavior and needs that leads to deep insight about potential new products and services.

With insight into potential jobs to be done, Johnson’s four-box model provides the structure to design a business model to accomplish the job to be done. In his exposition, he works his way through each of the four boxes, offering up suggestions and examples at each point. With a potentially viable design in hand, he shifts to considerations of implementation and, here, emphasizes that the early stages of implementation need to focus on testing, tuning, and revising the assumptions built into the prospective business model.

Johnson clearly understands that creating a new business model is a design effort not an execution effort. Seizing the White Space puts shape and structure underneath this design process. All books represent compromises. The compromise that Johnson has made is to make this design process appear more linear and structured than it can ever be in practice. He knows that it isn’t in his emphasis on the need to balance the elements of a business model and  to learn during the early stages of implementation. There’s a reason that the arrows in his four-box model flow both ways. I’m not sure every reader will pick up on that nuance.

He also clearly points out the role of learning from failures as well as successes during implementation. But the demands of fitting the story into a finite space again undercut this central lesson. The models here will go a long way toward making business model design more manageable, but they can’t make it neat and orderly.

This review is part of a "blogger book tour" that Renee Hopkins, editor of Strategy and Innovation and Innoblog, arranged.

Previous stops on the tour:

• Andrea Meyer – Business Model Innovation: Seizing the White Space
• Jeffrey Phillips – Book Review: Seizing the White Space

Upcoming stops

• Braden Kelley, Blogging Innovation
• Friday, May 7:  James Todhunter, Innovating to Win
• Friday, May 14:  Dan Keldsen, Information Architected

If you’re interested in digging deeper into the work of Clay Christensen and his posse, here are some previous posts where I’ve pulled together some reviews and pointers. I hope you find them helpful.

• A reader’s guide to Clay Christensen and disruptive innovation
• Innovating innovation: An Interview with Scott Anthony of Innosight
• Constraints and innovation – is there a silver lining?
• A workbook on doing disruptive innovation effectively

Blind Spot: A Leader’s Guide To IT-Enabled Business Transformation, Feld, Charlie

In the 1980s a handful of organizations established that the right combination of strategic and technology insights and execution could lead to results worth the attention of CEOs and Boards of Directors. One of those successes was a major transformation in the sales and distribution systems of Frito-Lay during their rise to prominence as a national player in the snack business. Frito’s CIO, Charlie Feld, was at the helm of this effort and was one of the individuals who defined the modern CIO role in the process. After Frito, Feld created a specialty consulting firm that spearheaded similar transformation in a variety of other firms and industries. Blind Spot captures Feld’s reflections on the challenges of using IT as a transformational tool and how to manage them.

The heart of Feld’s argument is this:

Most senior leaders have learned enough about the workings of their businesses to feel comfortable engaging in a new-product dialogue or a complex financial debate or a major litigation. But few have adequate background to understand and lead wide-scale changes that are technology enabled….To most executives, IT is a blind spot–a discipline that is confusing and hard to understand.

My belief is that information technology should not be viewed as a complex functional area. It is an integrating discipline that enables other functions to operate as a seamless, well-run business. Instead of some mysterious black box, IT can be less complex and easier to understand than marketing, operations, finance, sales, and other traditional operating disciplines. This is because it is fundamentally all about the way a business should operate, manifested in information access, workflows, networks, and business rules. And instead of a blind spot, information technology can and should be a highly visible and well-understood part of every business leader’s knowledge base,

(Feld, Blind Spot, p. xvii-xviii)

To tackle that problem, Feld shares a framework he has developed in the course of his efforts to drive IT transformation at Frito-Lay and elsewhere. Like any good framework, it’s simple enough to sketch on a whiteboard or on the back of a placemat, yet it can anchor and center an extended conversation about change. Contrast Feld’s framework with the Byzantine complexity of many systems development methodologies.

The "Journey" that Feld describes is straightforward. The most interesting aspect is his emphasis on time-boxing the phases in order to establish and maintain momentum.  At the same time, he recognizes the importance of taking enough time at the outset, in the Strategy and Turn phases, to get the overall direction and plan directionally correct. His experience calls for these first two phases to take about 90-days each. Subsequent phases are designed to deliver visible results every 6 to 9 months.

The second dimension of Feld’s framework, what he labels as "4 Planks for Change," is where things get much more interesting. This is where Feld devotes the bulk of his attention and he uses his experiences from Frito-Lay, Burlington Northern Santa Fe, Delta Airlines, Home Depot, and Southwest Air to illustrate his approach. These planks address four core questions about a proposed business transformation effort:

• Why do anything at all?
• What will we do?
• How will we do it?
• Who will lead and manage the change?

The value of these questions is that they are well suited to the debate and discussion that you want to be having in the C-suites and Board meetings about business transformation. They also help redirect the technically enamored from bright shiny objects to business value.

When I try to wrap my head around frameworks or approaches, I always look for is the "perform magic" step. Somewhere among the boxes and flows, there will be one spot where the essential design decision gets made or the case gets cracked or the strategy reveals itself. In Feld’s framework, i believe this essential creative step occurs in working out the What of the transformation Strategy.

Frito-Lay, for example, to maintain its growth, needed to give its route drivers local flexibility over product mix while maintaining close central control over manufacturing and quality. Their solution was to equip drivers with early hand-held point-of-sale terminals that let the drivers manage the diverse range of Frito-Lay products and accurately report sales activities back to corporate on a daily basis. In the case of Burlington Northern Santa Fe, the challenge was to synchronize  the electronic picture of where all of its rolling stock was with the physical reality in near real time. In these, and other, cases Feld deftly sketches the essential strategic What.

There is a common thread in Feld’s strategic analyses. The strategic choice in large organizations is whether to focus on operational efficiencies or customer intimacy. More often than not, this leads to efforts that bounce back and forth between bouts of centralization and decentralization. The strategic promise of IT is to change the answer in these debates from "either/or" to "both" by making a hybrid business feasible. Here’s how Feld describes it:

It is not about centralization versus decentralization–both have their virtues and liabilities. It is about common versus unique processes, standard versus disjointed information, and leveraged versus fragmented IT platforms and networks. If you are common, standard, and leveraged in your systems, data, and processes, you can continuously flex between centralized and decentralized where it is appropriate, like Wal-Mart. However, if those things are unique, disjointed, and fragmented, you are locked into those structures and change is expensive and slow, like Home Depot’s was….It may seem counterintuitive, but the more standardized your systems and processes are, the more flexible you can be.

(Feld, Blind Spot, pps. 144-45)

Feld’s third question is "How will we do it?" Because his primary audience is business leaders, he rightly keeps his focus at an executive level emphasizing the importance of sound architecture, concrete deliverables, and effective program management. These tend to be topics that cause most executives’ eyes to glaze over. In general, Feld makes the case for the relevance of this question as a co-equal part of the transformation process. He avoids the temptation to get caught up in either technical or process minutia. This may annoy some readers, but is the right decision for his target audience.

Feld closes with a look at the critical importance of leadership and management. He strongly favors an IT organization built to reflect stable, core, business processes rather than attempting to mirror more dynamic organizational structures. he sketches a basic IT organization that calls for 50-100 competent leaders. Successful business transformations like those he’s been describing call for a corresponding leadership cadre from the business side of the organization. This is a richer, more pragmatic, view of the leadership demands of this kind of technology enabled transformation than you will find elsewhere.

Blind Spot is a useful synthesis. It’s rooted in the ground truth of its case studies as told by someone who was there, start to finish. From that ground truth, Feld constructs a framework that can shape and guide comparable efforts without forcing them into too narrow a path. It’s most useful for those readers who can bring their own experience base to the task of understanding the framework and making it their own. Given the ongoing role of IT as a potential strategic tool, this is a set of ideas that belong in your toolkit.

The Checklist Manifesto: How to Get Things Right, Gawande, Atul

The idea of a simple checklist to raise the quality of a routine practice seems innocuous enough. It also seems to rankle those with lots of education and experience as an unnecessary intrusion on their autonomy.

The canonical example is the story of the effort at Johns Hopkins Hospital to reduce central line infections in critical care settings. A central line is a catheter inserted into someone’s jugular vein in order to deliver medications. It’s a routine step for many patients in a critical care unit. It’s also a primary source of infection for patients in hospitals. While inserting a central line is straightforward for someone with the proper training, medical professionals will skip steps in the hustle and bustle. Peter Pronovost, a critical care specialist at Hopkins, developed a five-point checklist of the steps necessary to avoid central-line infections.

There’s absolutely nothing on the list that practitioners aren’t already trained to do and absolutely nothing controversial about the steps called for. Many of those professionals considered it an insult to have the obvious pointed out to them in written form. Yet when this checklist was deployed at Hopkins, central line infections dropped from 11% of patients to zero. Comparable results have been routinely achieved elsewhere.

Gawande reported these results first in an article in The New Yorker. In this book he expands on that story to look at

• the origins of the modern checklist in WWII aviation
• multiple examples of checklists deployed in other health care settings
• the challenges inherent in developing checklists that work well in complicated environments
• the difficulties in gaining meaningful acceptance of checklists among highly autonomous professionals

We live in an increasingly complicated and faster-paced world. But our memories are limited and fallible. The right piece of paper in the right place can compensate for those limitations and increase our capacity to deal with that world. The first balancing act is to design a checklist that increases our capacity to handle a situation significantly more than it increases the load on our limited memories. Pronovost’s checklist only touched on the five items most critical to preventing infections. It made no attempt to spell out every possible step in the process.

A checklist shouldn’t be confused with a procedure manual. Avoiding that confusion is an essential element in making organizational acceptance of checklists possible. Checklists are intended to improve and systematize the performance of those who are already proficient. In themselves, they are poor tools for developing proficiency in those still learning their craft.

This confusion between checklist and procedure is at the root of most resistance to efforts to deploy checklists in suitable settings.  Unfortunately, Gawande contributes to this confusion himself when he conflates checklists with project plans. Both are useful documents  but they serve different purposes and are constructed differently. I’d suggest that you skip the chapter on "The End of the Master Builder" on first reading. It makes the core argument clearer.

Even when properly designed and targeted as relevant aids for the proficient, there is still a change management and leadership challenge to address in deploying a checklist to support more effective practice. While Gawande offers a number of excellent stories and examples of implementing checklists in various settings, he isn’t looking for or tuned into the relevant details of organizational change.  This book provides excellent insight into why checklists work and what to think about when constructing them. Expect to look elsewhere for comparable advice on managing the associated change. Expect to need to do so as well.

As compelling as the rational evidence for checklists may be, orchestrating their adoption into the work practices of professionals presents a large hurdle. The hurdle, of course, is emotional. A checklist can be viewed as diminishing one’s expertise rather than as reinforcing it. Reversing that perception for both the expert and the rest of the organization is the key.