[Cross posted at FASTForward Blog]
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.
Thanks for another thought-provoking post on observable work! I wholeheartedly agree with your selection of software developers as a class of knowledge workers worthy of systematic study of their work practices. I would like to nominate another group from which I believe we could mine valuable work practices and patterns – management consultants.
Top-tier management consultants are often asked to recommend solutions for important business challenges that have been sensed and felt, but not fully defined. The output of these engagements are frequently innovative in that they establish new management practices, products and services, and, occasionally, entire industries.
Of course, both software developers’ and management consultants’ daily work must be observable in order for analysts to derive high level patterns of effectiveness. Until their work is chronicled in detail, it will be difficult to spot decisions and actions that make an individual developer or consultant more effective than his peers. And it will be impossible to systematically analyze an entire class of knowledge workers without individual-level data.
Your writing about software developers also made me think of another, much older class of knowledge workers that overcame the challenges or vaguely defined tasks and outputs – composers of classical music. These craftsmen often learned by studying the output of their predecessors and contemporaries, then applying the concepts they learned to extend compositional forms and tonal systems. Experience tells me that the best developers and consultants do the same.
Finally, to extend the classical music example, I would point to the trail of observable work that many composers left in their notebooks of compositional sketches. These notebooks have enabled musicologists to analyze specific composers’ work processes over the course of their careers and learn practices that other composers might emulate. I have not seen an analysis of observable work artifacts across classical composers as a class, but I imagine the results of such a study would lead to a number of good, common compositional practices, if not a high level composition process shared by many composers.
Larry,
Excellent additional ideas. I particularly like the musician notion; I think you can mine both the classical and jazz traditions for some practices worth understanding more deeply
I do have some follow up posts in the works that draw on my own years as a consultant. I think they do have something to offer in their practices around deliverables and working papers. Hope to get those out in the next couple of days.