Category: Knowledge work

Eric Raymond on cognitive stress and knowledge work

A Taxonomy of Cognitive Stress: I have. A Taxonomy of Cognitive Stress: I have been thinking about UI design lately. With some help from my friend Rob Landley, I’ve come up with a classification schema for the levels at which users are willing to invest effort to build competence. The base assumption is that for any … [Armed and Dangerous]

Somehow, I missed this when it first appeared in May from Eric Raymond. I find his RSS feed erratic at best. It shows up at a good time, however, as I’m thinking through the implications of shifting focus to knowledge workers instead of knowledge management. Raymond is focused on user interfaces, but I think his perspective can be generalized to the challenges of doing and coaching knowledge work.

From managing knowledge to coaching knowledge workers

I’m continuing to work out the implications of shifting attention from knowledge management to knowledge work. It may not sound like a big difference, but I believe it will prove to be a crucial shift in perspective.

One important view of organizational design is the long standing notion that certain parts of the organization serve as buffers between a volatile external environment and a stable and standardized set of internal processes. The goal is to isolate variation and map it into standardized inputs to standardized products and services.

In an industrial world this is a very sensible organizational design strategy. In a knowledge economy, however, the goal becomes one of providing unique responses to unique inputs. Moreover, more and more of the organization finds itself coming into contact with the external environment. You can’t buffer it and you don’t really want to buffer it.

At the same time, our language and our metaphors keep pushing us back into that industrial, standardized, mindset.

As a consultant, my role is to help clients understand their unique problems and frame a suitably customized response. Yet the industrial mindset, and perhaps human nature to some degree, encourages us to sort problems into the bins we have learned to be comfortable with. To the client, their problem is unique. To the consultant it looks a lot like the last fifteen they’ve dealt with. This is why a client turns to consultants in the first place, but there’s an important shift in attitude that separates the best consultants from the rest. It’s a shift from shoving a problem into a particular standardized box to drawing on a deeper experience base to focus on the unique aspects of the problem at hand.

As an aside, my two favorite resources for helping develop this shift if focus are Peter Block’s Flawless Consulting: A Guide to Getting Your Expertise Used (Second Edition) and Gerry Weinberg’s Secrets of Consulting : A Guide to Giving and Getting Advice Successfully.

This shift in perspective is relevant to understanding why so many knowledge management efforts have failed and why focusing on managing knowledge work is likely to be more fruitful.

The fatal flaw in thinking in terms of knowledge management is in adopting the perspective of the organization as the relevant beneficiary. Discussions of knowledge management start from the premise that the organization is not realizing full value from the knowledge of its employees. While likely true, this fails to address the much more important question from a knowledge worker’s perspective of “what’s in it for me?”. It attempts to squeeze the knowledge management problem into an industrial framework eliminating that which makes the deliverables of knowledge work most valuable–their uniqueness, their variability. This industrial, standardizing, perspective provokes suspicion and both overt and covert resistance. It also starts a cycle of controls, incentives, rewards, and punishments to elicit what once were natural behaviors.

Suppose, instead, that we turn our attention from the problems of the organization to the problems of the individual knowledge worker. What happens? What problems do we set out to solve and where might this lead us?

Our goal is to make it easier for a knowledge worker to create and share unique results. Instead of specifying a standard output to be created and the standardized steps to create that output, we need to start with more modest goals. I’ve written about this before (see Is knowledge work improvable?, Sharing knowledge with yourself, and Knowledge work as craft). In general terms, I advocate attacking friction, noise, and other barriers to doing good knowledge work.

This approach also leads you to a strategy of coaching knowledge workers toward improving their ability to perform, instead of training them to a set standard of performance. In this respect, knowledge workers are more like world class athletes than either assembly line workers or artists. There are building block skills and techniques that can be developed and the external perspective of a coach can help improve both. But it’s the individual knowledge worker who deploys the skills and techniques to create a unique result.

Software development – a model for knowledge work as craft

I’ve been working out the notion of knowledge work as craft for a while now. Knowledge management approaches fail to the extent that they try to shoehorn knowledge work into an industrial framework. If I buy a thousand Thinkpads for my organization, I want and expect everyone of them to function identically. If I distribute them to a thousand consultants, their clients will expect each presentation, analysis, and report to creatively reflect the unique needs and characteristics of each client. If I’m a smart manager, I’ll focus on making it possible for that uniqueness to appear. I certainly shouldn’t expect the management practices designed to eliminate variability to be very much help when variability is what I actually want.

Last week I had a chance to catch up with Greg Lloyd, founder of Traction Software, which is an enterprise level weblogging environment. Traction is rooted in the work of Doug Engelbart and the early hypertext/hypermedia research of Andy van Dam at Brown. One of the topics we talked about was where to find helpful models for understanding knowledge work and how it differs from production work.

Software development is arguably one of the oldest “modern” knowledge work fields and holds many lessons for all of us doing knowledge work. Better still, for my purposes, software development has worked through the blind alley of trying to force knowledge work into a factory model and come out the other end as 21st century craft.

The goal here is to focus on the principles and practices that software developers have developed to guide and manage their work, not on the substance of the work itself. Think of what software craftsmen take for granted that the rest of us knowledge workers lack or have to cobble together for ourselves–version control, issue tracking, forking. These are just a few of the techniques for making the work of software development more visible and, therefore, more manageable. Other concepts that come to mind include iterative development, granularity, prototyping, and modular design.

Lots of details to work out here, but this feels like a productive line of thought. Some of the sources I’ve been monitoring and can recommend:

Extreme mobility and knowledge work effectiveness

Extreme Mobility: a rant that I had to write after reading Tim, Dave, and this all in one day. [Ray Ozzie’s Weblog]

Just getting around to reading this post of Ozzie’s from last week (one of the advantages of news aggregators). Full of lots of Ozzie’s usual excellent insights.

I believe we’re currently in a transition period for personal computing: from a tethered, desk-bound, personal productivity view, to one of highly mobile interpersonal productivity and collaboration, communications, coordination. We’re focused right now on devices and networks because we’re coming at the problem bottom-up: preoccupied by gizmos and technologies’ capabilities rather than focusing on how our lives and businesses and economies and societies will be fundamentally altered.

I’ve been living in this mobile world arguably since the early 90s. My primary computer since 1993 has been a laptop of one variety or another. I’ve lived the the scenarios Ozzie describes including the joys and aggravations of Lotus Notes when it was the only environment to deal with keeping a mobile workforce in sync.

Most organizations still operate on the notion that the corporate network is a fortress to be protected. This makes my life difficult from two perspectives. First, getting into my own network is more difficult than I would like from my selfish, time-pressed, user perspective. Second, when I am with clients, my effectiveness is compromised by the hurdles I have to negotiate to get access to material on their networks. Email becomes the lowest common denominator for coordinating work and the impacts on knowledge work effectiveness are invisible to the organization. Extra hours that I work to cope with these limits don’t show up anywhere in the reporting systems.

One aspect of this transition to extreme mobility is that I control the tools of my craft. I do have to reach an understanding with the folks in IT support so that they trust I won’t do anything stupid and will keep them in the loop. But I can experiment with new tools and practices. The challenge is to bring the useful lessons back into the organization. Ozzie sums it up well:

Regardless, one thing seems certain: with the notable exception of a small number of truly visionary CIO’s such as the one mentioned above – exceptional individuals who are willing to move their enterprises forward by taking risks – discovery and innovation in mobility and interpersonal productivity & communications – in “relationship superconductivity” – is being driven primarily from “the edge”: from small businesses, organizations and individuals who are experimenting with new communications technologies and software. Innovation now works its way into the enterprise; it no longer migrates outward. The technology leaders of the past – enterprise IT – are now focused (for very good economic reason!!) on cost reduction and efficiency, on “fast solutions”, and on a very tough regulatory environment, through strict controls. Liability, and the sheer mass and difficulty of managing broad ICT deployments encourages conservatism, and this won’t be changing anytime soon.

 

If the only tool you have is a hammer…

A Day In My Life, By Bill Gates. (SOURCE:Scobleizer Radio Weblog)-PREDICTION: Within 10 years, the centre of most knowledge workers (including Bill Gates) will be a blog type application. NOT email. <quote> I’d say that of my time sitting in my office, that is, time outside of meetings, which is a couple of hours, two-thirds of that is sitting in E-mail. E-mail is really my primary application, because that’s where I’m getting notifications of new things, that’s where I’m stirring up trouble by sending mail out to lots of different groups. So it’s a fundamental application. And I think that’s probably true for most knowledge workers, that the E-mail is the one they sit in the most. Inside those E-mails they get spreadsheets, they get Word documents, they get PowerPoints, so they navigate out to those things, but the center is E-mail. </quote> [Roland Tanglao’s Weblog]

Roland catches the real point of this interview with Gates. The interview provides some interesting raw data on the day-to-day work practices of our economy’s quintessential knowledge worker. Email is the tool he has for communications so it is the tool that he uses. It is worth seeing how Gates thinks through how to get leverage from the tools that he has available. We all need to exercise that kind of thought about how to use our knowledge tools — blogs and aggregators included.

Don’t define knowledge, improve knowledge work instead

KMPro with Mark Clare. Mark Clare argues that KM needs to step back and define knowledge before plunging forward with the “next wave” of knowledge management approaches or applications. [Knowledge Jolt with Jack]

I disagree.

I think that most efforts to define knowledge get hopelessly bogged down. The reason this happens is that the discussion is locked in an assumption that there needs to be a centrally managed agreement (at a minimum) about the definition.

I take a different approach. Focus instead on knowledge workers and knowledge work. Work on eliminating friction and hassles in their ability to do whatever it is they think matters. Attack the problems that are preventing knowledge workers from being as effective as they would like to be.

There’s an old story that I’ve heard described as a Russion proverb. It says that if each one of us takes care of sweeping the sidewalk in front of our own home, we won’t need streetsweepers. It’s worth thinking about how that might apply to the world of knowledge work, both on the level of being an individual knowledge worker yourself and on the level of helping make the other knowledge workers that surround you more effective.

Improving the interaction between individual and organizational intelligence

Collective intellect augments individual. Scott Leslie wrote in his EdTechPost blog: “Don't you just love when, in the process of thinking about an issue,… [Blog of Collective Intelligence]

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.

Knowledge workers and productivity tools

Surrounded by new opportunities.

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.

[Jeroen Bekkers’ Groove Weblog]

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.

knowledge work improvement – black box, white box, and deliverables

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 producing 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 apocryphal, 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.

Knowledge work as a process
 

Basic knowledge work 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.

Alan Cooper on knowledge work as craft

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.

[Visual Studio Magazine – The Software Architect – The Craft of Programming]

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.