Marc Orchant picked up on my labeling one of his recommended tools as a “frictioner reducer.” I thought it might be worth taking a few minutes to be a bit more explicit about how I use that term in reference to knowledge work.
Unlike physical processes or information factory processes, knowledge work processes aren't readily susceptible to conventional reengineering/industrial engineering approaches. You can't impose industrial structure and control on these processes without destroying the fluidity and adaptability that characterizes them as knowledge work processes.
That raises the question of what can you do to make those processes more effective and possibly more efficient. I have a series of concepts I use as heuristics to make a knowledge work process better. I find them helpful for my own thinking. I'd be curious to hear whether others find these helpful as well as what else they find useful when attacking knowledge work.
This all grows from my notion that knowledge work is better thought of as craft work rather than factory work and that there is more traction in seeking to improve knowledge work than in grand schemes for knowledge management.
I look at four things when I look at a knowledge work process; friction, visibility, indirection, and granularity. Today, I want to focus on friction; we'll come back to the others in later posts.
In conventional process design work, you look for bottlenecks; places where work backs up. Break the bottleneck and move on to the next one. I think of friction as the things that create bottlenecks or slow knowledge work down. It's a bit more subtle than just focusing on obvious bottlenecks.
Let's start with some examples of some friction reducers I currently take advantage of in my own work.
My preference for using RSS aggregators can be viewed as one example of attacking friction in knowledge work. New items show up in my aggregator soon after they are posted. If there are no new items, nothing shows up. I don't waste time going to sites that have nothing new to see. And for sites that do have new information, I don't have to go through the effort to surf to the site until and unless I want to. Consequently, I can monitor an order of magnitude more material than I can by trying to manage and visit sites via a blogroll.
I've been a long time proponent of ActiveWords because of its ability to attack knowledge work friction in so many ways. Not having to remember a web address or not having to type out words and phrases I use frequently smooths my day. Moreover, I am better off using ActiveWords as a single application than I am in using the various shortcut tools embedded in specific applications. Email signatures are a simple example. I use Outlook for my work related email and Eudora for my personal email (a point of friction I tolerate for other reasons). Instead of defining signatures in each application, I have a set of shortcuts defined in ActiveWords. I can adapt the tools on my PC to my needs, instead of adapting myself to the tools.
Software isn't the only way to attack friction in knowledge work (as often as not software solutions add friction). Good ideas by themselves can help. David Allen's Getting Things Done approach is full of ideas that attack friction. One of his ideas I like best is the notion of to do lists that are organized around the context of where they can be used. Instead of a master to do list that you need to review in depth to find useful next steps, Allen convinced me to segregate the lists by where I could use them; such as a call list I can use anytime I have a few minutes free vs. a list of things I can't do unless I'm at my comptuer. Trade a bit of extra set up time for much less friction in action.
Thinking in terms of friction can be helpful because it lets you identify opportunities for improvement without having to redesign or replace entire processes. I don't need to rethink my entire information scanning process to get benefit out of using RSS and news aggregators.
I'm not sure I have any deep rules to identify friction. It's more a function of tuning in to points of irritation and asking whether there are tools or some simple process steps I might take to reduce or eliminate the friction. It helps to be at least aware enough of what is going on to see ways that you are repeating yourself and to scan the kinds of tools and techniques that others use and promote.
Although the examples I've used all operate for individual knowledge workers, the same mindset applies for groups and teams. Here, organizations are adept at creating all sorts of friction to be attacked. Finding frictions that can be attacked and reduced is easier, although the barriers to reducing friction are much more likely to be institutional than computational.
