George Por began thinking about organizations and knowledge management long before most of us. It's good to see him sticking a toe into the blogging waters. There is particularly thought provoking diagram in his post here that is worth a look at and is worth spending some time thinking about. He's trying to get at how individual and organizational knowledge might interact to their mutual advantage. That leads to the question of how you might design things to make this interaction more effective.
Ray Ozzie on ZDNet : Surrounded by new opportunities
Even though our current use of PCs, productivity tools, e-mail and the Web seems quite sophisticated, we’ve only just begun to understand how to apply them and effectively realize their benefits. The next 10 years will find us moving decidedly from an era of personal productivity to one of joint productivity and social software. That will involve a move from tightly coupled systems to more loosely coupled interconnections. It will be an era of highly interdependent systems and relationships, with technology continuing to reshape the nature of organizations, economy, society and personal lives.
Ray Ozzie is busy thinking about the kinds of problems we’ll want computers to help with five to ten years from now. “Groove”, or something like it, may well be part of that answer. Certainly, the focus on collaboration and social software will be a major element of what’s next. That’s certainly what I expect someone like Ozzie to be thinking about.
At the same time, I think it’s an overstatement to claim that many of us are realizing the personal productivity promise of today’s technology. While I might not go as far as Alan Kay’s claim that the computer revolution hasn’t happened yet, I do think that both individual knowledge workers and organizations could be doing a lot more to take advantage of the tools we have.
In the mid-1980s, the Harvard Business School was one of the first MBA programs to require incoming students to buy PCs. One of the things I got to participate in as a doctoral student at the time was to help deliver the training to incoming MBAs. We spent three days teaching them the basics of the IBM PC and how to use Lotus 123.
How much training does the average organization offer new hires about the technology environment? An hour? Thirty minutes? Some of that is a testament to the overall improvements in usability and in general knowledge of technology. But I can’t think of anyplace that invests any time in how to use the tools effectively. One interesting item (by way of Sebastien Paquet) is a white paper by Tommaso Toffoli at Boston University titled “A Knowledge Home: Personal knowledge structuring in a computer world.” (pdf version)
The fundamental challenge, and opportunity, is that we’ve been content to focus on increasing the power and flexibility of our technology tools while assuming that knowledge workers will figure out how to take advantage fo that power. As knowledge workers it’s our responsibility to do more of that figuring out. We need to stop counting on the marketing promises of technology vendors and start learning how to use the tools we’ve already got.
I've talked before about Peter Drucker's recent thinking about how to improve the productivity of knowledge work. Productivity improvement is driven by a process of observing how work gets done and rethinking, redesigning, and tweaking the process so that fewer inputs and less effort go into producing the same quantity of output.
Essential to that improvement is the ability to define outputs and inputs precisely and to observe the transformation process carefully. Ideally you treat a task as a white box that you open up and play with. A fallback, and less effective, approach, when the process is hard to observe, is possible if you can still observe the outputs. You treat the process as a black box and constrain inputs or tighten cycle time standards. As long as you can observe the outputs and measure them with some accuracy, you can get some degree of productivity improvement simply out of being demanding.
As weak a management strategy as this may be, it can work tolerably as long as you can agree on how to measure the outputs. Unfortunately, it fails utterly as a management strategy when the outputs are difficult to characterize – i.e. for most of knowledge work. The most typical alternative strategy doesn't help. That is to shift focus from measuring outputs to measuring inputs. If you can't observe the process to improve it, and you can't figure out how to assess the outputs, you measure and manage the inputs.
Conceptually, if you can't measure the outputs you can't measure productivity. This leads to such common management nonsense as rewarding people on how many hours of unpaid overtime they put it or what time they show up in the morning and leave at night. This is marginally defensible if you convince yourself that everyone is producting widgets of roughly equal quality. It seems pretty suspect when you apply it to knowledge work.
This issue becomes more pertinent as the percentage of people in organizations who are knowledge workers grows. When only a handful of your workforce are knowledge workers, you don't truly care about their productivity. To the extent that you do, you can make qualitative judgments about whether the outputs produced are acceptable.
There is an old tale, probably apochryphal, of Tom Watson at IBM. Showing a fellow CEO around the office, they came across a staffer with his shoes off and feet up on the desk doing nothing. Watson's guest was outraged and asked why Watson didn't fire the slacker on the spot (although I wonder what term he used in place slacker). Watson's answer? “The last idea he had saved IBM $50 million; I'm waiting for the next one.”
As enlightened a management response as that may be, it isn't one that scales very well. You need a more systematic approach when substantial numbers of your organization are expected to produce and deliver money saving or money making ideas. Part of this will require us to begin looking at knowledge work as an improvable process.
The managerial job in this process is in the last step “Evaluate and Assess.” But it's not done by standardizing the work products/deliverables. By definition the outputs of knowledge work are unique. That's what makes them knowledge work. If they can be standardized, then we're talking about factory work, and we already know how to improve that.
One route to a solution is to look at how professional services firms have tackled the problem. I'm not talking about their generally disappointing first generation efforts at knowledge management. Instead I'm talking about something so ingrained in consulting firms that we've lost sight of what an innovation it was — the deliverable.
I've begun to entertain the hypothesis that the deliverable is one of the lasting contributions of the consulting profession. Not the bound powerpoint presentation gathering dust on the shelf. But the concept of turning a knowledge work process into some kind of visible result that can be inspected. Once you have something you can inspect, you have something you can begin to manage.
The mistake that gets made is to try to immediately force this into an industrial model. Yes, we can now inspect the result, but we still know very little about its quality. We listen to stale management maxims like “if you can't measure it, you can't manage it” and immediately start counting things because we can, not because it makes any sense. This is a good time to bear in mind Einstein's observation that “not everything that can be counted counts, and not everything that counts can be counted.”
There's plenty of mileage to be gained from some careful observation before we get wrapped up in statistics. The first distinction about knowledge work deliverables as opposed to widgets is that the quality of deliverables is always negotiated and constructed. If the client isn't happy with the 100-page powerpoint presentation, it isn't done. If the first three pages answer the question, it is and the remaining 97 are irrelevant.
One of the unfortunate side effects of the various productivity tools made available to us over the past 20 years is that it has become easy to produce what used to be useful indicators of quality (professional type, color diagrams, fancy bindings) without necessarily producing the actual quality. One option is to put your trust in reputation. Certainly, some consultants have raised that to an art form. A better, but more difficult, option is to spend some actual time reviewing the content. If you do take that tack, you'll find that you want to do that reviewing, evaluating, and negotiating of quality along the way. Otherwise you increase the risk of wasting a lot of expensive time and effort producing the wrong thing.
The challenge here is not simply the change this entails in management style, but also the change it entails in the knowledge worker. If I am producing a deliverable whose quality must be negotiated with the client, I have to take the quite real risk of sharing my thinking before it is complete.
These can be hard habits to break. We're accustomed to providing and evaluating the “right answer.” Putting an incomplete and still evolving hypothesis out there is risky. Trying to help someone shape that hypothesis into a better one without doing the work yourself is equally hard and frustrating. It's so much easier to shove the process into a binary one – done/not done.
Weblogs are one useful tool in making this negotiation of quality easier. The format makes it easier to develop ideas in what feel like more manageable chunks.
Commercial programming is clearly a craft. Unfortunately, the failure of our profession to recognize this has allowed two profound problems to grow. First, programmers almost never work to a plan. All craftsmen exercise their skill within a context well defined by detailed, written descriptions of the desired ultimate form. These plans are typically devised and drawn by an architect, a role rare in the software world. Architectural plans are necessary to ensure that the work of multiple craftsmen dovetails together, and that it meets the buyer's expectations. Most contemporary programmers work only from a list of features and a deadline.
Second, programmers are almost never supervised. Craft is by nature detail-focused and deeply involving. Good craftsmen regularly work in a state of flow, so they must depend on others to make sure their efforts merge with those of other craftsmen. The supervisors aren't there to keep craftsman from dodging work, but to ensure that the big picture is tended to. A well-crafted building, for example, is more than an assemblage of sturdy walls; the walls must connect properly. The craftsmen can do this, but they rely on someone else to coordinate their work.
Excellent food for thought from Alan Cooper. While he is focused on programmers, I think his points are more broadly applicable to a variety of knowledge work settings. He helps identify some of the critical dimensions along which knowledge work as craft differs from industrial work and how those differences have important implications for management. Thanks to Roland for the pointer.
Nice point about how this thinking in public is a set of parallel threads that intersect and separate. You get the freedom to reflect on what you're reading in other blogs, but you also get to engage in this loosely coupled interaction.
I wonder if part of what I'm finding valuable in this addition to the broader set of tools for thinking is this degree of “loose coupling?” You're not wrapped up in the middle of an argument, but you also don't have a real opportunity to wander off into the poppies and contemplate your navel. I think this is particularly so if you add in the aggregator/news reader side of this interaction. I'm able to track this evolving exercise in collective reflection without having to go from place to place to follow it. At the same time, all of my reflections are collected in this one spot (and shared via my news feed).
Got an interesting email from one of my readers, Jack Vinson. I'm reposting it with his permission.
I have to mention a concern that will arise as blogging gets higher on the corporate radar screen.
In today's blog you summarise that weblogs enable people to “think out loud” in a convenient way. This is something that corporate lawyers will wince to read. And prosecuting attorneys will drool. The problem is the way the US court systems have developed: A prosecuting attorney can dig through any and all relavent documents, looking for damning content. And this content is frequently devoid of context. “Look what that manager wrote in the marginalia!” Or “Look what 'evil' comments I found in the original version of this document” (from documents that have used the Track Revisions tool in MS Word). Never mind that the larger context has nothing sinister happening.
I could easily imagine that weblogs could be host to all sorts of “thinking out loud” discussions that would be ripe for the picking.
Of course, companies have to deal with these kinds of things all the time. They must get business done, while at the same time protecting themselves as much as possible. Most will encourage their people to “write smart” when committing anything to a potentially permanent record.
First off, it's clear we need to encourage Jack to join the ranks of bloggers. And I suspect that he's right about what some of the early reactions are likely to be from corporate counsel. How do we work through this objection?
For most companies the focus will remain on doing business and doing whatever best contributes to getting the job done. I remember a conversation a few years back with an attorney who had done some work with Cisco. Cisco managers basically said “we're using email to run our business, we're making commitments and binding agreements with it, and it's your job to figure out how to make that work, so deal with it.” While there may be some initial hemming and hawing, the concerns Jack raises won't be show stoppers.
I think there are two reasons to believe that internal weblogs will actually prove to be a better solution than email and newsgroups for this category of concerns. First, weblogs directly address the out of context problem created by email and newsgroup and exploited in discovery proceedings. Weblogs keep the context visible both in terms of the chronological and archive structures of the weblog format and in terms of the practice of linking across weblogs. Second, is the point that Jack raises at the end. The public nature of weblogs does encourage more attention to “writing smart” than email and newsgroup formats. It helps keep you focused on the notion that you are writing for the record. I sometimes wonder what would have happened at Enron if they had done more of their thinking “in public.” If an extensive weblog culture had been in place, could they have done wha they did? I don't know what the answer to that thought experiment might be. But if you had a choice between joining an organization with an active weblog environment or one that discouraged them, which would you choose?
Lilia, Sebastian, and Denham are picking up on and adding to my attempt to figure out where blogging fits in the world of knowledge work. Thinking in public was the way I chose to label a talk I'm giving later this week at Seabury Western courtesy of a gracious invitation from AKMA. It's the next stage in a idea I started working out a while back of “knowledge management with a small k.”
Weblogs are the latest in a long line of tools being applied in the realm of what has been loosely labeled knowledge management. I say “loosely” because so many different tools and techniques have been thrown under the knowledge management umbrella that I'm not sure there's any room left for the knowledge workers this is all supposed to help.
I've owned the knowledge management problem in one medium sized consulting firm and I've tried to communicate some of what I've learned in one MBA level course at Kellogg. I've been online since 1980 when I took an online seminar at NJIT run by Starr Roxanne Hiltz and Murray Turoff after devouring The Network Nation. I've used Lotus Notes, threaded discussions, email, IM, web pages, various collaboration tools and group decision support systems, and now weblogs with varying, and generally less than satisfying, degrees of success.
Denham suggests “thinking together” as preferable to “thinking in public,” and suggests the following interpretation:
Thinking in public is all about taking a stand, being open to alternative views and engaging in thought exchange. Here is where I think I differ from bloggers – the value of thinking in public is not about personal risk taking, publishing or pushing (your) ideas, it is about being receptive to the thoughts of others – that listening & dialog thing again.
I think he takes my notion a step farther than I was intending. I agree with Denham that the goal is to be receptive to the thoughts of others and that “thinking together” can indeed lead to better results than thinking alone (as does drinking together instead of drinking alone).
My problem is this. Most of the technology tools for supporting thinking together (e.g. discussion forums, threaded discussion, wikis) depend on skills and norms that I've found to be rare in practice and challenging to promote. My intuitions tell me that there are important differences with weblogs that address at least some of these issues.
[As an aside, I use the word “intuitions” quite deliberately. Gary Klein in his excellent book, Sources of Power: How People Make Decisions, shows that intuitions are a form of pre-packaged knowledge in the form of situational awareness. They are your experience base telling you something worth listening too. Klein focuses on how these intuitions guide actions, but it's also worth thinking about how these intuitions might be unpacked into a deeper, more explicit, understanding of a problem.]
One of the primary reasons that thinking together is hard is that it requires both that we think in public and that we think collaboratively. I suspect that thinking together fails at least as often because we don't know how to think in public as it does because we don't know how to do it collaboratively. Further I think that order matters. You need to learn how to think in public first. Then you can work on developing skills to think collaboratively.
Thinking in public is a precursor skill to thinking collaboratively that's been ignored. We want to get to the fun stuff (ooh, brainstorming!) and skip over the hard part.
Weblogs make the hard part easier. They make it possible and permissible to go public with an idea while you're still working it out. Their structure of time-ordered, generally short, posts feels less intimidating than having to produce a finished, completely worked out, properly structured report. Their organized, permanent, structure of archived posts give you something to go back to and to build on. Pulling it all together under the umbrella of an individually identified place makes it visible and sharable with others without forcing it on anyone. Finally, syndicating the results via RSS makes it available to those who are interested in a way that enables dialog without demanding dialog.
Reminder. Paul McCann asked me to remind him (and other Chicago-area bloggers) when the upcoming presentations by Jim McGee and David Weinberger were scheduled, and this morning I got a message from Eric Sinclair renewing the plea for that reminder. So here we go: Jim will come to Seabury on Thursday, April 10, to talk about sharing knowledge via blogs (the title of his presentation will be, Thinking in public Can you do that? Is it safe? Is it wise? Weblogs in organizations. Hell be in the Seabury Lounge, I think, and the presentation will start at 7:30. David Weinberger… [AKMAs Random Thoughts]
I'm flattered that AKMA was kind enough to sandwich me between David Weinberger and Ben and Mena Trott who presented last month. Hanging out in such company has to be a good thing.
I'll be sharing some thoughts, observations, and questions about how weblogs are beginning to be used as one more tool to help make knowledge work more effective inside organizations. The perspective I've been poking at for some time now is what happens when you begin to revisit the idea of knowledge management from the point of view of making individual knowledge workers more effective.
Think of it as knowledge management with a small k. The wave of solutions offered under the rubric of knowledge management prior to weblogs was largely driven by vendors with a centralized, top-down, organization centric view of the problem. At best they were attempting to solve the problem of knowledge management (whatever that might be) from the perspective of the organization, not the perspective of the knowledge workers doing the knowledge work. A good portion of the resistance to these knowledge management efforts is sensible resistance to extra work that has no demonstrable payoff for me as a knowledge worker.
I started experimenting with weblogs and precursors to weblogs several years ago and began to publish a public weblog about 18 months ago. I've found the notion of weblog as backup brain to be a powerful metaphor for finding the value of weblogs to the work of an individual knowledge worker within an organization.
One of the central things that occurs with this strategy is that you have to start learning how to think in public. That certainly can feel like a risky thing to do. In some organizational settings it might well be risky. But I'm increasingly convinced that developing that skill will be an important aspect of what organizations must learn to do to survive and thrive in today's world. If you're going to be near Evanston next Thursday night, do drop in. If you're lucky AKMA's wife will provide molasses cookies again. Then it won't matter whether I have anything useful to say or not.
Bookmark this site. It has some utterly wonderful examples of both good and bad graphs. It helps a lot when doing your own grahs. [A Man with a Ph.D. – Richard Gayle's Weblog]
Think of it as a clip book of infographics examples
Sue Shellenbarger:People who multitask are less efficient than those who focus on one project at a time, says a study published in the Journal of Experimental Psychology. The time lost switching among tasks increases with the complexity of the tasks, according to the research by [David Meyer, psychology professor at the University of Michigan] and others.(Via Frank Patrick.)
Sure it does, but does that mean you really have a choice? The research is intriguing. What I’d like to see next is some advice about making good choices about what and when to multitask and when and how to go after flow. The research only seems to go after the first part of the problem, which is to establish how much and what kind of degradation you might expect. The interesting part of the problem is how to get better at including multitasking appropriately in your repetoire of work strategies. Cause I sure don’t expect to get back to a world where I have the unfettered freedom to always single thread.