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:
- Dave Thomas’s weblog PragDave and Andy Hunt’s /\ndy’s Weblog. Dave and Andy are the authors of The Pragmatic Programmer which is also worth looking at.
- Martin Fowler’s Bliki
- Tim Bray’s ongoing
- Peter Lindberg’s tesugen