Struggling to Improve Knowledge Work Practices–From Idea to Finished Product

I closed a recent blog post with the following observation

I struggle with advice about how to work at the level of ideas that haven’t found a home yet. This distinction of making a note promises to be a path into making more sense, more systematically, of that middle space and time before I know what the destination might be. (From Taking Notes to Making Notes)

It’s the sort of idea  the often surfaces as I work on a piece of writing that I’m developing into a prospective blog post. I’m now viewing it as an example of what I’m trying to sort out as I learn how to “make” notes. 

Right now I don’t know whether the struggles I am wrestling with are a function of fighting against the years of doing things a different way, a marker of individual flaws in the way my brain works, or some challenge inherent in the process. I study the advice and recommendations of others whose thinking feels compelling. And then I fight with it as I try to apply the advice as I understand it. 

My habits and practices are the accretion of years of doing what works for me. Most of that experience hasn’t been examined or explored in any systematic way. I encounter, read about, and seek out advice and suggestions from all sorts of sources. Some of it is intriguing enough to try out and experiment with. I run the experiments based on whatever partial understanding I’ve managed to take away from the advice. Some stuff sticks in some distorted version filtered through my assessments of those experiments. 

Let me try an example to make this more concrete. Many years ago, I came across Peter Elbow’s work. I don’t recall whether I stumbled across Writing Without Teachers or Writing With Power first. Doesn’t really matter. I had a new technique to play with–“freewriting.” Get stuff out of your head and onto paper (or a screen) where you can see it. Don’t strive for the perfect sentence or turn of phrase in your head. 

But there were elements of Elbow’s recommended practice that didn’t work for me. Elbow assumes you are doing freewriting by hand. Word processors were not household items when he formulated his process. He advises writers to push on at all costs; keep making marks on paper, don’t stop to review, write nonsense if you find yourself getting stuck. Elbow’s goal is to help you find a state of flow, to suppress your inner critic. 

Elbow never saw my handwriting. Achieving flow doesn’t help if you can’t decipher what you wrote a few hours earlier. Sometime before the arrival of word processing, I got the advice to learn to create at the keyboard. I wrote drafts of consulting reports at a typewriter well before I had access to word processing. My poor handwriting was the impetus, but the more important benefit for me was that I can type faster than I can write. Which meant it was easier to capture thoughts before I lost them.

At a typewriter, going backwards doesn’t make sense so you’re not faced with the opportunity to correct on the fly. With a word processor, you can go back as easily as forward, so now you have a choice about whether to do so. More often than not, I will correct typos if I see them in the moment. I don’t hold to a hard and fast rule; rather I do whatever feels least disruptive to my flow. So, now I’ve violated another “rule” in the method I am trying to adopt.

I also discovered Anne Lamott’s Bird by Bird and she granted me permission to write shitty first drafts. They had been shitty anyway, but now I had someone explain that that was okay and merely a step along the path. 

That path is well worn but not paved. There’s a discernible evolution from 

  • random notes to 
  • something that feels like an idea worth exploring to 
  • the emergence of a potential outline or roadmap to 
  • snippets of a draft to 
  • something that might qualify as a shitty first draft to 
  • rounds of editing and polishing to
  • finished product

This is a rough snapshot of the process that has worked for me through decades of writing. Laying it out like this makes it look more systematic than it actually is and I don’t feel that it looks all that systematic. 

What surfaces for me here is how much of my practice is driven from a deliverable of some sort; there’s a consulting report, a speech, a class session, a column, a blog post looming somewhere in the distance. I am working toward an endpoint, however dimly perceived.

Until I can see an endpoint, I struggle with what to do next. Once I do see an endpoint, or have one imposed by external forces, I start shaping material to fit that endpoint. Generally, I think that is a good thing, but it does mean I have to be willing to scrap things that won’t fit. That becomes easier with practice.

As you learn to care about your craft, you are always on the prowl for potential improvements. For the past 22+ months that has led to a focus on how notes might play a more central role. Most recently, that has been working to understand the distinction between note-taking and note-making, which was the trigger for this post. 

Having that distinction is only a baby step; the challenge is to work out what it means to incorporate the distinction into day-to-day practice. There’s new terminology, of course; ephemeral notes, permanent notes, atomic notes, evergreen notes. Still only another baby step; working out how to create these artifacts has been a bigger, still unfinished, step. These new artifacts don’t obviously map to what I produce in my current workflows.

The challenge that I am attacking now is that it’s hard to find worked examples of these techniques. You can find advice and recommendations on what various proponents and experts believe works for them. But these ideas are new enough that there aren’t well established practices to emulate. You’re left with trying to reverse engineer and interpolate practices from what you can observe. 

Most recently that has had me following the work of Andy Matuschak. He’s a software developer in this space who has been sharing what he describes as his working notes. He’s also attempting to offer a window into his practices. His observations on Evergreen note\-writing as fundamental unit of knowledge work and on Executable strategy for writing have both proven valuable as I work to improve my own knowledge work practice. 

Two asides here. One, I’d be thrilled if more of my finished products were as well thought out as his working notes. I’m telling myself that this is one key reason to investigate his work. Two, Matuschak is experimenting with Patreon as a means of supporting his research. I judge it an excellent return for a modest investment. 

There are also several online communities working these vineyards. Fellow travelers can make a difference. I’ve been monitoring;

If getting better at knowledge work is one of your objectives, look for your own companions and watering holes.

From Taking Notes to Making Notes

I’ve recently been spending time in the online community at Ness Labs, launched by Anne-Laure Le Cunff. She’s been writing about topics that sync up with my interests in knowledge work effectiveness and has collected a really interesting collection of fellow travelers. Recently, she piloted a short online course called “Collector to Creator.” Way above the average online course both in terms of content and community. You should keep an eye out for future iterations. 

This was part of my ongoing efforts to reexamine and retool my knowledge work practices. Much of that has focused on what happens between a germ of an idea and a worthy finished product. And rethinking the role of notes has been both a central focus and a central struggle as I work at designing and then grooving in new habits and practices. Some wayposts in that journey include:

During one of the sessions Anne-Laure introduced a one-letter distinction that has opened up a new line of thinking and development. She differentiated “note-making” from “note-taking.”

The most obvious aspect is a shift from a passive to an active perspective. I hadn’t actually thought much about the passive nature of “taking” until I had “making” as a contrast.With it, I can see how much of my note-taking habits and practices were intellectually passive; I was taking notes to capture someone else’s words or thoughts. This was certainly the case in most of the settings where I was in a student role. 

Now that I have the distinction, I can revisit and reinterpret some of my practices. I never acquired the habit of working with index cards, so I never got the sense of ideas as discrete chunks of text to be manipulated. I did use hand-drawn mindmaps (that being the only option at the time) to work out structural connections and relationships. But my focus was generally on the big picture of whatever deliverable I was working on. Even when I was immersed in the literature of a field, I tended to think of ideas as being embedded in and tightly integrated with the journal articles and books I was reading. I thought of ideas from others as something to be transferred (taken) more than as something to be transformed (made). That’s to the extent that I thought about this level of thinking explicitly at all. 

The transformation, connecting, and reconnecting of ideas into a new deliverable was something that took place either in my head or in the multiple iterations of creating a specific deliverable. I struggle with advice about how to work at the level of ideas that haven’t found a home yet. This distinction of making a note promises to be a path into making more sense, more systematically, of that middle space and time before I know what the destination might be. 

This one-letter distinction may not be a full 80-IQ point change in perspective, but it’s clearly worth enough to be a keeper.

If you do knowledge work, you need to become a ‘pracademic’

Loyola’s Quinlan School has just launched a new Next Generation MBA. Project Management is a required course in the curriculum and I was asked to take the lead in designing that course. We’re now halfway through the first iteration of the course. I had an opportunity this past weekend to speak at PMI Chicagoland’s Career Development Conference and opted to use the course design and rollout effort to reflect on what larger, emerging, lessons I saw.

During the course design process, I learned a new label to describe me. It turns out that I am a “pracademic”; someone who brings a practitioner’s perspective to an academic environment. While it turns out that the label isn’t terribly new, I just stumbled across it.

I assert that if you are a knowledge worker, you need to become a pracademic as well.

What is a pracademic?

A quick glance at Google’s ngram viewer suggests that the term, “Pracademic” traces back to the mid-1970s and saw a significant uptick in the early 2000s. There’s a seminal 2009 academic paper on the term by Paul Posner, “The Pracademic: An Agenda for Re‐Engaging Practitioners and Academics that’s a good entry point.

The primary focus seems to have been on the notion of bringing relevant practitioner experience back into the academic environment. Like all good portmanteaus, however, pracademic elicits a constellation of reactions.

Among those is the more general notion of blending practical and theoretical knowledge. An admirable and long sought goal but one that, probably unsurprisingly, is more difficult to put into practice than it is to describe in theory.

It’s hard enough to be competent on either side of the divide. Working both sides effectively is harder still. With the continuing and accelerating explosion of knowledge, the need to do precisely that has become simultaneously more challenging and more necessary. This is a topic that has drawn my attention before:

Living in exponential times means this explosion has always been underway. It’s important to accept that this is an explosion that doesn’t end; there is no point at which the curve is likely to level off. Waiting for things to settle down is a fool’s errand.

If you opt for the role of a pracademic it is a matter of accepting that this is a path you will be walking for as long as you wish or are able. Whatever credentials or experience you might collect, there is no marker for being done.

Why does this matter for knowledge work?

Knowledge work is perhaps the purest expression of this notion. Your capacity to deliver effective results is a function of how well you can assess the practical situations you face and then apply the most pertinent and relevant aspects of your cumulative knowledge base.

While the origins of the term pracademic are anchored in carrying practitioner knowledge back into the academy, knowledge work in the environment we’ve been talking about works the other direction. What does it mean to take theory back into practice?

Knowledge work demands leveraging theory. As a knowledge worker, you are rarely granted the luxury of time off to fully study and integrate the latest and greatest developments in your field of expertise. At the same time, if you don’t continue to add to your expertise, your ability to contribute and make a difference diminishes.

How does this change the shape of practice?

The late Donald Schön of MIT addressed this line of thought with his notion of “reflective practice“. Fundamental to the notion of reflective practice is building and testing a robust theory of action.

My particular interests are in action that occurs in organizational environments; action that calls for coordinating the efforts of multiple actors. Practice takes place within those social and organizational environments. Applying theory within this practice environment benefits from understanding key aspects of how thinking connects to action there.

There is a persistent mythology about organizations that rationality should prevail and that anything other than rational decision making represents some level of pathology. This is an area where academic research and theory is especially illuminating.

There are two aspects of thinking relevant to navigating this environment. The first relates to a distinction between oral and literate thinking. This distinction was mapped out by Walter Ong, a Jesuit historian and philosopher. Ong examined the impact of the invention of writing on culture and institutions. At root, his argument is that literacy enables us to get thinking outside of our heads and that this transition is an essential, prerequisite, step in enabling the rise of rational thought.

While complex rational thought is rooted in literate modes of thinking, organizations are environments that predate literacy. They blend oral and literate modes of thought. Most particularly, organizational power dynamics are rooted in oral modes of thought. Arguments do not carry the day simply by being the most logical and rational. This is puzzling and confusing to those who’ve made the effort to become adept at literate thought.

One rule of literate thought, fortunately, is that you do not simply accept someone else’s word, you go and see for yourself. This leads to the second aspect of accepting the assumption that organizations behave rationally; the discoveries of those who went and looked. There is a growing evidence base about the limits of rationality in organizations.

Herb Simon advanced organizational understanding significantly when he pointed out that our desire for rationality was bounded by innate limitations in our ability. “Bounded rationality” meant that however much we might strive to make rational decisions, there were always limits of time and capacity. Real decision makers in real organizations “satisfice;” they settle for “good enough” answers.

Simon’s observation that theoretical rationality was bounded sparked a stream of research starting with Amos Tversky and Daniel Kahneman that gradually articulated the extent of the various failure modes of rational thought and established the field of behavioral economics. Kahneman’s 2011 book, Thinking, Fast and Slow, provides an excellent entry point into this realm.

Where do you start?

Suppose I’ve made a good enough case. You’d like to begin operating in a more intentional “pracademic” mode. What do you do next? Based on my own travels along this path I can suggest a 2-part reading list and some new practices to adopt.

The reading list contains some core theory and introductions to a starter set of practices.

Core Theory Readings

Starter Practices

There are three foundational practices that should be part of your repertoire.

The first is one you likely already possess; a systematic reading habit. Actually, any reading addiction is a good starting point (cereal boxes were my gateway drug). Over time, you’ll likely find it worthwhile to put some support systems around your habits. There’s a reason your professors wanted you to produce bibliographies to accompany your work. Unfortunately, they sometimes forget to explain the why behind the what. Why and how to keep track of what you read is a subject of its own. We’ll save that for another day. For now, if you don’t have a tool to manage this practice, I suggest you take a look at Zotero | Your personal research assistant.

Reading is the fuel for your own thinking. The second core practice you want to invest in here is better note-taking. That’s covered excellently in Sönke Ahrens How to Take Smart Notes in the core reading list. I’ve got a review of his book here – Unexpected Aha Moments – Review – How to Take Smart Notes. I would also suggest taking a look at Getting Outside Your Head.

Over time your note-taking will evolve into note-making as you become more practiced in using your reading to engage in asynchronous conversations with writers. You’re going to want to start engaging in conversations with yourself, which is the third core practice. There are multiple approaches to developing a journaling habit. While journaling is often associated with doing emotional reflection and work, it’s also a tool for doing intellectual reflection and work.

What comes next?

You are now on a lifelong learning path. Perhaps you were already on it and now have some new tools to work with. You will discover that you’re walking this path with others on similar journeys. Strike up a conversation and share your discoveries.

The futile quest for the one true tool

One Ring to rule them all, One ring to find them;
One ring to bring them all and in the darkness bind them.

J.R.R. Tolkien _The Lord of the Rings_

I discovered Tolkien’s Lord of the Rings back in high school and read it multiple times before I graduated. I’ve reread it from time to time since then. It’s a good marker of my basic nerd-cred.

The quote has been on my mind lately as I try to make sense out of what feels to me to be an odd trend in adopting personal software applications. The most recent example that I’ve encountered is the application Amplenote, which pitches itself as an “attempt to unify four apps that smart people scatter their ideas across.”

I don’t know enough to either endorse or critique this particular application. What I am trying to understand is this neverending quest for the “one true tool.” I sort of understand the appeal from a marketing perspective. It’s the argument for Swiss Army knives and Leatherman tools.

I have several of each, but they don’t constitute my entire toolkit. What leaps to mind first when I come across these pitches is Dan Akroyd pitching the Bass-O-Matic

What I don’t get is why you would want to subscribe to this line of thought as an aspiring knowledge worker. At the early stages of a knowledge work career, it is possible to think of yourself as an expert in a particular tool or technique. It’s possible to label yourself as an Excel jockey, or an SEO expert, or an options trader.

The presumptive default path forward is to move from individual contributor to management. Rather than do knowledge work, you manage others doing knowledge work.

I think there’s another path that hasn’t received enough attention. That’s the path from knowledge work apprentice to journeyman to master of the craft. Two excellent entry points to thinking about that path are:

These are less about the particulars of acquiring specific technology skills and knowledge (although that is a worthy goal in its own right) than they are about a particular mindset or orientation. Instead, they offer insight about how to pursue a parallel strategy of solving problems and building your capacity to solve bigger problems.

Idea Management as an Abundance Problem

The best way to have a good idea is to have lots of ideas

 Linus Pauling

I suppose it’s fitting that I have struggled with this blog post far more than most. It began with a desire to improve the rhythm and cadence of completing and published writing deliverables. Having just passed nineteen years writing this blog, you would think I was beyond fits of teenage angst. Maybe the onset of blogging adulthood is more daunting than I realized. 

I’ve always liked the Pauling quote. Having lots of ideas has never been a particular problem for me, so I’ve trusted that some reasonable portion of them would be good enough to share. For a long time, I attributed my occasional struggles to focus on a particular train of thought on my ADD. Bright shiny objects always promise a dopamine hit, but I’ve felt like I’ve been able to keep it enough under control. 

It occurs to me, however, that my ADD simply serves as an early introduction into a world that we all now live in. We all swim in an overwhelming abundance of ideas. Our training and practice focuses on turning individual ideas into a desired deliverable, whether that is a blog post, a client presentation, or a spreadsheet analysis for our boss. 

While there’s much to be learned about that idea to deliverable evolution, there’s another layer of knowledge work practice that we must tackle. That thread of idea to deliverable is one element of a collection of threads and you have to manage the collection as something distinct from any one thread. 

Simply splitting the problem into two layers is a step forward for me. I have a reasonable handle on the first layer; I know how to take an idea,  develop it, extend it, and polish it into a deliverable. As a creative task, however, that process is rarely linear. Ideas are not widgets, you can’t simply plow ahead from idea to deliverable. You often need to set things aside and let them cook. 

Which is where the second layer comes into play. What do you pick up when you set the first idea aside? Presumably another idea that you set aside earlier or a new idea trying to seduce you. You now have a management problem as well as a creation problem. 

The management problem is about selecting ideas, monitoring progress, switching, sequencing, timing, and cadence. This is operating at a different level of abstraction from the creation process. 

At small scales, you can likely manage organically. There aren’t so many threads that you can’t keep most or all of the management issues in your head. With time and the accumulation of a body of work, it’s worthwhile to externalize the management problem and not try to rely on the limits of memory. At the same time, the management process must be subordinate to the creative process. 

Over the past eighteen months or so, I’ve been gradually retooling my baseline creative practices around a more disciplined note-centered practice. Like any retooling, this has led to a temporary drop in output. As committed to improvement as I may be, there’s still muscle memory to be overcome. Even bad habits are still habits that require extra energy to break down and replace. Some markers of this journey that have risen to things worth sharing include:

Early on, what management of the process I did was on the proverbial back of an envelope. Keep a list of ideas as they came to me and pick something off the list when I sat down to write the next piece. Look back at the last few blog posts and write a follow up piece. Do this for any length of time, however, and the envelope gets pretty full

My next thought was to take the list off the back of the envelope and formalize it. I dug into the approaches of other writers who’ve gone through this evolution. Among the appealing approaches I ran into were:

These approaches, however, don’t scale well. As your body of work grows, you risk spending more time maintaining the management control system than you do creating new work. That misses the point entirely. 

Some Zettelkasten advocates claim that the necessary tools and structure emerge as you gain more experience and grow your collection of notes:

This hasn’t played out for me. Setting aside the hypothesis that this simply reflects my personal limitations, what’s missing? 

This comes back to the distinction between creating and managing. Most of the discussion and advice I’ve been able to review is focused almost exclusively on creation. It either ignores managing the process as a whole or presumes that what needs to be managed is trivial relative to making creation work more smoothly and reliably. 

To manage the overall process you need to get above the details of individual work in process (WIP) items. You want to collect just enough data about each item to not have to read the entire piece while you are trying to manage a collection of multiple WIP items. And you need to track the status of each piece of WIP relative to its transition from WIP to final deliverable. Is this item a new idea? A draft? In need of editing? Ready to publish? Published? There’s a life cycle to be defined. This is the metadata you need to make informed decisions about the overall process. Do you have enough WIP to feed your deliverable goals? How does the mix of materials look?

This is a classic data management problem that would seem to call for a simple spreadsheet as DBMS solution. Or a multi-column outline of some sort. Both of those approaches failed relative to the goal of keeping the management system subordinate to the creative system. As I continue the transition to a note-centric creation system, the challenge is to embed the pertinent metadata in the individual notes and create some method of querying the metadata to generate the schedules and lists that will help me manage the creative process. Now that I’ve got a handle on the basic requirements for managing my WIP, the next step is to discover or create the reporting tool. 

McGee’s Musings turns 19 today

McGee’s Musings turns 19 today. I started this outpost on the Web nineteen years ago while I was on the faculty of the Kellogg School. It was a way to share ideas with my students. It also grew out of my abiding interest in doing knowledge work effectively.

Recently, there’s been a resurgence of interest in how to best apply technology to knowledge work. Some of this is about developing software tools. More interesting to me has been a set of new ideas about how to use tools. Notes, for example, have taken on new roles and new importance. What does it mean for a note to be “atomic” or evergreen?” Why is that a useful distinction?

What is a Zettelkasten? Should I care? How about a “digital garden?”

One of the key concepts I’ve been working out for myself has been the idea of making knowledge work observable. This spot has been one element of that ongoing effort.

I’m beginning to work on how to improve this experiment both for myself and those who’ve been following along. There are two key questions I need to address. The first is where to draw the line between what gets shared and what isn’t yet fully baked. When in the creation process does it help to reveal the current state of progress to make still more progress? That’s largely an emotional decision about how exposed I want to feel.

The second question is what other elements should be part of the design of this place? What would make this site more useful for you? What’s missing? I’ve got some ideas. I’m researching others. What would you recommend?

Identifying Knowledge Work Practices

I’m continuing the quest to understand and improve my work practices. Several terms/ideas have been holding my attention and I’d like to work out how they might fit together;

After some iteration, I put them together in the following diagram;

Let’s start with signals and noise. Noise is a problem in pretty much any communications environment. Social media of late is an environment with a lot more noise than signal, for example. Claude Shannon pretty much invented the field of information theory in his work at Bell Labs in the 1940s. There might have been a point when I understood the math back in my youth. Today, I’m content to settle for a metaphorical approach and think about my work as uncovering or creating signal out of noise.

I’ve been running up against the limits of deliverable and working backwards. Over-focusing on deliverables limits your thinking when you are early in the process and don’t yet have clear notions of deliverables. I’ve found the notions of sensemaking and solving for pattern effective ways to counterbalance that focus.

Another notion I am playing with is a distinction between Intake and Pre-Intake. I appreciate the warnings of some in the Zettelkasten crowd about the “collector’s fallacy,” but not enough to stop my picking up shiny things. I value my magpie tendencies and I’m reluctant to trade faux-productivity for creativity.

As I thought through this broad flow from initial inputs to deliverables, it occurred to me that it was worth thinking of process/practice management as a layer distinct from the working layer I typically operate within. One hypothesis I’m exploring is that there is a useful distinction to be made between process and practice. “Process” feels a bit too rigid for most knowledge work; practice seems to better capture an appropriate degree of flexibility and adaptability.

Regardless of how the process/practice distinction evolves, separating the managing layer from the doing layer is helping. It allows me to investigate activities and practices that may be missing from my current repertoire. As a first approximation, I’ve identified several practice management elements to investigate:

Some of the pieces exist–reference management, archive management–and could stand improvement. What is most evident to me is that I don’t have effective practices for managing WIP and reading. Now, I’ve got some shape on what to work on next.

Building A Bespoke Knowledge Work Environment with Off-the-Rack Tools

Photo by cottonbro from Pexels

I’m still slogging through the mess I spoke about last time. I just checked and I’ve written over 10,000 words since then; none of which yet rise to the threshold of being worth sharing. Some will before too long, I hope.

One of the thoughts that leaked out of my fingertips during that time is the seed of an idea that provoked this post.

As a knowledge worker, one permanent task on your to do list is to build a bespoke knowledge work environment using the off-the-rack tools  available.

I am in the midst of unpacking that idea for myself and decided it would be useful to share that process. I won’t expose all of the mess; the daily journal entries where snippets of this post first surfaced, the list of previous posts that I searched out and reread, the bullet point outline I am working from right now. But I will try to reflect the essentials.

I’ve organized this around the following four questions:

1. Why do you/I need a bespoke environment?

2. Why are most of us constrained to leverage off-the-rack tools?

3. Why is this perspective useful?

4. Where should you/I start?

Why do you/I need a bespoke environment?

Off-the-rack is a concept that didn’t exist before the industrial revolution. All products and services were bespoke. If you needed a new shirt, you made it yourself or had someone make it just for you. The industrial revolution and the industrial era were built on a different promise; accept some level of standardized product in exchange for a huge leap in average quality and a proliferation of choices. This has been such a successful strategy, that it’s easy to forget that it is based on a tradeoff.

Knowledge work and the products of knowledge work return us to a bespoke world. Value in knowledge work is correlated with uniqueness. I’ve written about this before (Balancing Uniqueness and Uniformity in Knowledge Work). If your goal is to pursue unique insights and contributions, you will want to tweak and tune your work environment in any and all of the ways that contribute to achieving that uniqueness.

Why are most of us constrained to leverage off-the-rack tools?

Inventing and building new tools is an order of magnitude more difficult than using existing tools. We tend to forget this when we reach for tools in an existing environment; you aren’t likely to think about what it takes to make a carpenter’s hammer as you pick one up to drive a nail.

Until recently, the fundamental tools of knowledge work were simple and readily available. Paper and pencil, blackboard and chalk, can take you far down the path of creating a knowledge work artifact of value.

Knowledge work, however, is fundamentally symbol manipulation in various guises. Communications and computing technologies are power tools for manipulating symbols. And, they are complex artifacts in their own right. You would no more think of writing your own word processing tool than you would think of forging your own hammer.

That does not, however, absolve you from learning how to choose and use available tools effectively.

Why is this perspective useful?

Adopting the perspective that the goal is a tailored environment and the available building blocks must be selected from what’s available sets up a tension that can be used to drive the design process.

Perhaps most importantly it provokes a recognition that simply picking tools is the least challenging task before you. That should establish an appropriate degree of skepticism about the blandishments of tool vendors and tool enthusiasts.

I took a look at this problem some time ago (Building Your Knowledge Workshop). That advice still applies. Your goal is an effective work environment, primarily for yourself. Individual tools come and go in your knowledge work environment much the same as tools accumulate and evolve in a conventional workshop. You need to grasp the work you are doing and the materials you are working with. And you need to learn what each tool can and cannot do in support of that work.

Where should you/I start?

There’s a decision to be made at the very outset of this process. It’s a choice about attitude or approach. You can elect to treat tools the way a new apartment dweller might. Get a starter set of basic tools assembled by some marketing intern at Home Depot and call the building super when you run into trouble. Or, approach the problem like a homeowner with a strong do-it-yourself bent. Investing in and learning to use professional tools for the most part. Knowing when to reach out to more experienced experts from time to time. Or, finally, you can offload your problems to a collection of experts and their tools. This increases your costs and leaves you beholden to the expertise and ethics of the experts you rely on.

I’m an advocate for the middle approach. That starts with getting a better handle on the work you do, followed by more diligently investing in learning how to use your existing tools. We don’t encourage either step in most organizational settings. Software development seems to be the only arena where practitioners routinely think about and invest in their tooling and practices.

Embrace the mess if you want to do better knowledge work

I’ve been deeply immersed in the recent profusion of new ideas, apps, and initiatives in the knowledge work  space. I’ve been working to make sense of a host of terms and concepts and discern their relevance to my own work. A partial list of those concepts (with some pointers to good entry points) includes:

There’s also a recent uptick in applications and services offering a path to implementing these ideas. These new apps are also fighting for mindshare with a set of existing apps. A very partial list (basically those apps I have experimented with or use with some regularity) includes:

Software developers, entrepreneurs, and evangelists of all stripes have to make the spine of their application, service, or approach clear and compelling. You’ve got to be a believer if you’re going to put in the time and effort to build something new. Early adopters also tend to be believers.

I tend to be an early adopter in many settings. But I’m also an old fart, so I’ve been jilted many times. Scar tissue provides perspective.

One of the drivers behind this surge in new work is the inexorable shift to knowledge work. Knowledge work is different from so much of the work that organizations have learned to manage and control. No matter what the bean-counters and compliance managers would like, knowledge work is inherently messy.

There’s a distinction in the world of early AI research that is useful in this context. The early world of AI research broke into two camps on the nature of intelligence; the “neats” and the “scruffies.” I took a look at this argument a number of years back in an earlier blog post on the realm of knowledge work–Knowledge management: the latest battle between the neats and the scruffies.

I once aspired to being a “neat”–business school is fundamentally targeted towards those who cherish and desire to impose order. The reality, linked no doubt to my ADD, is that I will always be a “scruffie.”

Fortunately, the world now aligns more closely with my “disorder.” You can’t get to “neat” without traveling through “scruffie.”

The challenge is that nearly all of the evangelizing and advice about new ideas is packaged as though that journey is over or, at least, easy. We get a “neat” picture of the destination. The journey is left as an exercise for the reader.

Even if the developers and early adopters acknowledge that there is a journey to be made, they gloss over the messy parts. If they share any details of the necessary hero’s journey, they offer just enough of the ugly parts to burnish their story. Preparing you for what you will encounter just gets in the way of the next chapters of their stories.

The absolutely essential step if you want to travel the path to being more effective as a knowledge worker is to accept that you have to walk the path for yourself. Seeking out more honest accounts of those who have traveled before you can help. Finding guides who can walk with you and help you avoid the quicksand and tar pits is even better.

But you’re still going to get dirty.

Building knowledge work toolsets

Swiss Army KnifeI first encountered the notion of “affordances” in Don Norman’s excellent The Psychology of Everyday Things (which was renamed The Design of Everyday Things a couple of years later).  From the world of design, an “affordance” is a characteristic of an object that offers clues about how to use or interact with that object; the design of a chair tells us it is something for sitting on, a pitcher is for holding and pouring things. Affordances can be difficult to design in a world of more complex physical objects; they can be nigh on impossible in the design of software tools and applications. One of the things that made early computer systems so confounding was that they offered no affordances to latch onto. Graphical user interfaces were a huge step forward in making software user friendly (or at least not overtly user hostile).

Affordances and the design thinking that goes into crafting good ones are rooted in the physical world; dexterity, reach, visual acuity, strength, all factor in to design. This is the world of ergonomics or human factors. Transferring that knowledge to the abstract world of software and the objects in our environment with significant software elements is no simple task. You need only think of the remote control for your DVR and set top box or the user interface of your bank’s ATM to appreciate how difficult this design work can be.

One failure (limitation?) of modern application design is affordances that run out of steam before users grasp the full capabilities of an application. If all chairs looked like a Shaker chair, how would we ever figure out what to do with a BarcaLounger; or the pilot’s cockpit seat in an F-16? The menus and window layouts of your typical desktop application (Word, Excel, Powerpoint, Outlook) get everyone up and running quickly, but they do nothing to hint at, much less reveal, any deeper capabilities or opportunities. So, for most users, most of the time, those opportunities go unrecognized and the capabilities never get exercised.

What separates power users from the rest of us, then, is a willingness to dig into users manuals (RTFM as a career advancement strategy) and to experiment and play with their tools to figure out what is possible. Otherwise smart people take marketing hype about “easy and intuitive” software seriously and judge themselves deficient when good software tools are often neither. The opportunity wasted is tremendously sad.

So, what do we do to help more people get more value out of their software? My specific interests happen to be about knowledge work. What can we do to help knowledge workers push their tools farther and better? Put another way, why do we settle for knowledge workers leveraging such limited subsets of the tools they already use or avoiding tools or techniques that might unlock significant new insights and outputs?

Although I’ve been talking about affordances I don’t think the blame or the answer lies exclusively with software designers. More realistic claims from software marketers wouldn’t hurt although I’m not holding my breath. As software users, one thing we can do is invest time to suss out more of the design models in the heads of the software developers who build the tools we are seeking to leverage.

Word processing software offers examples of what I’m thinking about.

Microsoft Word is likely the dominant word processor on the planet. You can find it installed on most any desktop or laptop computer you encounter. It ushered in the world of WYSIWYG computing where one goal of the interface was to represent your work in as close to final form as possible. Implicit in that design was that the “final form” was a printed page.

A consequence of that design choice was that you now had one tool that spanned what had once been a series of discrete stages in the process of bringing an idea to the printed page. Writing, editing, design, and layout are quite different cognitive activities. In a pre-WYSIWYG world, each of these steps had its own set of professionals, its own set of standards and practices, and its own set of tools. With Word you now have a single tool that can serve at all stages (at least for 80% of cases).

Whether that is a good thing is another question. Having one tool makes it more difficult to see that the activities in each stage are quite different. When you’re working out the structure of an argument, there’s little point to be worrying about what typeface and font size works best for a section heading. But a single tool blurs that distinction and boundary. You can be enticed into playing with those problems or thinking they are important to deal with now while your fundamental argument or storyline is still a mess.

A tool that is suitable across all these steps may be valuable within an organization. But at the price of obscuring the differences between different process stages. You could manage that problem if you made an effort to make the different stages of the process more explicit. But now the organization and its people need to work at cross purposes to the tools. You have a single tool obscuring the differences in the process while you try to highlight those same differences as you manage the development and evolution of any particular deliverable.

Scrivener is a popular word processing tool, especially among authors dealing with longer form writing projects. Its user experience embodies a very different model of the writing process than Microsoft Word. Scrivener makes the various stages of writing–drafting, editing, design, layout–visible and identifiable in its user interface. In particular, WYSIWYG is a secondary or even tertiary goal in the user experience.

Moreover, Scrivener was designed in a time when the printed page is only one of many target forms for final deliverables. It also supports multiple formats for electronic books, PDF files, and the web. To that end, the design of Scrivener separates the activities for structuring a draft output from formatting it for final output.

For users accustomed to the WYSIWYG model embodied in Microsoft Word this is a source of frequent confusion. Learning how to invoke specific functions and features in Scrivener isn’t terribly helpful until new users grasp the fundamentally different process model embedded in the design of the application.

Software marketers don’t like to acknowledge that software users require multiple individual software tools to handle the complexities of modern knowledge work.It is not their job to figure out how to fit multiple tools together to get work done.

This is an element of your job description that hasn’t been acknowledged or addressed in the average organization. You will likely be issued a starter set of basic tools. But don’t expect useful guidance on how to use them in concert to accomplish the work expected of you. It is yours if you hope to be an effective knowledge worker.