Category: Knowledge work

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.

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:

• Building a Second Brain – Building a Second Brain: An Overview \- Forte Labs
• Commonplace Book – How And Why To Keep A “Commonplace Book” \| Thought Catalog
• Digital Gardens – Digital gardens let you cultivate your own little bit of the internet \| MIT Technology Review. A gardening guide for your mind • Mental Nodes
• Evergreen Notes – Evergreen notes
• Everything Buckets – Mark Bernstein: Everything Buckets. The Case Against Everything Buckets — Alex Payne
• File system information base – File System Infobase Manager
• Idea File – Implementing an Idea\-Management System \- LessWrong 2\.0
• Jerry’s Brain – Jerry’s Brain
• Mindmapping – What Are Mind Maps and Why You Definitely Need Them?
• Zettelkasten – Create a Zettelkasten for your Notes to Improve Thinking and Writing • Zettelkasten Method

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:

• Best Note Taking App \- Organize Your Notes with Evernote
• MindManager – [Mind Mapping Software by MindManager \| MindManager
• Notion – The all\-in\-one workspace for your notes, tasks, wikis, and databases\
• Obsidian
• Roam Research – A note taking tool for networked thought
• The Archive \(macOS\) • Zettelkasten Method
• TheBrain: The Ultimate Digital Memory
• Tinderbox: The Tool For Notes
• XMind \- Mind Mapping Software

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.

I 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.

Managers do not solve problems, they manage messes
– Russell Ackoff

I’ve long been a fan of the late Russell Ackoff. This was one of his observations that continues to stick with me. As much as we like to think of the world as a set of discrete problems to be solved, reality insists on  being interconnected and messy. As I seek to understand and improve my own knowledge work practices, this is one of the pieces of wisdom I try to keep in mind.

One of the sources of mess that has been on my mind lately is scale. Things that seem obvious and simple always get messy as they get bigger. For example, I’ve just wrapped up a course on how to do requirements analysis. We run it as a field based course which means we work with local organizations to tackle a real problem. But it has to be a small enough problem that we can fit it into a semester’s worth of work.

I can require student teams to prepare the same work products that would be expected of them on the job but the problems aren’t big enough to make the need for some of those work products to be evident. Students do the work I ask of them, but they don’t really believe me when I assert that all of those products are relevant and important.

I’m probably irretrievably tainted by my early days in public accounting when I hung out with auditors. Now, this was so long ago that spreadsheets were still actual sheets of paper with rows and columns preprinted on them. Audits generated piles and piles of paper. The most natural thing in the world for an auditor faced with managing a stack of spreadsheets was to prepare another spreadsheet to serve as an index into the stack.

The physical scale of stacks of paper made this solution fairly obvious. Turn those stacks into bits, however, and the need to manage that scale problem disappears or, at least, fades into the background. If you can no longer see the mess, it won’t occur to you that it needs to be managed.

On a project team, there is often enough friction in dealing with multiple team members trying to coordinate their work that you can impose some level of control over the growing collection of digital materials being produced. But the usual pressures to “get to done” work against efforts to manage the mess. Persuading team members to give some thought to what they name that Excel file gets lost in the rush to work on what’s inside the file.

A sufficiently OCD project manager might prevail over a project team. Certain regulated environments can force the mess to be managed. But for individual knowledge workers, there are few incentives to deal with, or even recognize, the problems of managing the mess that is a digital work environment.

Getting work outside of your head is only a first step. Doing so gives you the capacity to take on problems that are too big to fit inside your head. Your reward for increasing your capacity is a set of bigger messes to manage.

I’ve been on a quest over the past year or so to understand the importance of getting outside of your head if you want to be more effective as a knowledge worker. The inciting incident for this quest was reading How to Take Smart Notes by Sonke Ahrens (my review is at Unexpected Aha Moments – Review – How to Take Smart Notes). I think I’m past the “refusal of the call” but I don’t know that there is a mentor to be found, although there do seem to be many others walking similar paths. Ahrens tells a story about Nobel physicist Richard Feynman that I traced back to James Gleick’s biography of Feynman (Genius: The Life and Science of Richard Feynman). Gleick tells it this way:

[Feynman] began dating his scientific notes as he worked, something he had never done before. Weiner once remarked casually that his new parton [In particle physics, the parton model is a model of hadrons] notes represented “a record of the day-to-day work,” and Feynman reacted sharply. “I actually did the work on the paper,” he said. “Well,” Weiner said, “the work was done in your head, but the record of it is still here.” “No, it’s not a record, not really. It’s working. You have to work on paper, and this is the paper. Okay?”

This is what my math teachers would label a “non-trivial” insight. However, if they made that point when I was studying math, it sailed right past me. Sure, you could sometimes salvage credit on a problem set by “showing your work” but it never occurred to me that “showing” and “doing” your work was the same thing. I always felt that the work was supposed to be going on inside my head, that the goal was to get everything inside my head before exam time rolled around. Certainly the testing and evaluation systems reinforced the notion that you were supposed to keep the important stuff in your head; storing it elsewhere was likely to land you in serious trouble if you got caught referring to that external storage during the exam.

Some of this is the problem of “toy problems.” In teaching settings, you need to work with problems that can fit into class sessions and semester-long projects. With most of these you can get away with lazy practices; you can manage it all in your head. If you’re lucky, the course designer may try to force you to follow good practices above and beyond simply finding the “right answer.” As a student, you’re still likely to miss the point of learning the supporting practices. [As an aside, this is now something I’m working on improving in my course design and delivery]

Once you start to look for it, you do see that smart people have been offering good advice about how to deal with the limitations of your unaided memory and brain. Think of Anne Lamott’s advice to write “shitty first drafts,”  Peter Elbow’s practice of “freewriting,”  Tony Buzan’s advocacy of “mind mapping,” or John McPhee’s ruminations on “Structure.” All of these are the kinds of techniques and practices that can make us more effective at creating quality knowledge work artifacts. But it isn’t clear that we encounter this advice as early or effectively as we should.

If we do stumble across this category of advice and fold it into our work practice, we can gain a meaningful edge. We’ve taken elements of the work out of our heads and into our extended work environment. We’ve increased the range and complexity of material we can now draw on to create better deliverables.

I’m in the midst of working this out for myself. I actually think that this is something that each knowledge worker is going to have to design for themself. I’m suspicious of claims that someone’s new tool or application contains the secret answer. Right now, I’m investigating various sources with an eye toward identifying design principles and ideas worth extracting or reverse engineering.

Some of the more interesting trains of thought include:

• §Taking knowledge work seriously (Stripe convergence talk, 2019-12-12) | Evergreen note-writing helps insight accumulate | Executable strategy for writing
•  Tool for Thought – The New York Times
•  stevenberlinjohnson.com: Tool For Thought
•  The Incredible Creative Power of the Index Card – Forge
•  Here (with 2 Years of Exhausting Photographic Detail) Is How To Write A Book
•  Why Roam is Cool – Divinations
•  Getting compound interest on your thoughts with Conor White-Sullivan
•  The One Thing You Need to Learn to Fight Information Overload
•  Berners-Lee: Talk at Bush Symposium: Notes
•  This is how I did it: created the best reference manager set up for research & writing – Natural Resource Ecology Laboratory at Colorado State University
•  Drawing Diagrams in the Head and with Technology: Benefits, Cognitive Mechanisms, Artificial Intelligence, Apps, and Sleep Onset Dreaming – CogZest
•  Create a Zettelkasten for your Notes to Improve Thinking and Writing • Zettelkasten Method
•  How to Write a Note That You Will Actually Understand • Zettelkasten Method
• Building a Second Brain: An Overview – Forte Labs

The late Peter Drucker continues to be a source of insight and inspiration for me.  In 1999, he published “Knowledge-Worker Productivity; The Biggest Challenge” in the California Management Review. I’ve written about it before (Knowledge work and productivity). I want to explore the following observation:

The crucial question in knowledge-worker productivity is: What is the task? It is also the one most at odds with manual-worker productivity. In manual work, the key question is always: How should the work be done? In manual work, the task is always given.

I’ve started to think of this question as “Task Zero.”

The invention of zero was one of the great advances in mathematics; perhaps we should respect that power. One of the curious things you learn as a computer programmer is to start counting from zero rather than one. Certain things become easier when you do.

One of the reasons I’m drawn to starting at zero is that it frees up my thinking. If you think of yourself as starting from zero on a map or a coordinate system, you are free to move in any direction. Starting at one immediately commits you to a direction.

That’s tempting because a direction gets you moving. There’s a great observation from Cory Doctorow that reflects this:

Start at the beginning,” he said. “Move one step in the direction of your goal. Remember that you can change direction to maneuver around obstacles. You don’t need a plan, you need a vector.

― Cory Doctorow, Homeland

We like movement; it feels like progress. But they’re not the same thing. Take a closer look at Doctorow’s quote; he’s advocating movement in “the direction of your goal.”

Clarifying the goal is Task Zero. It is the “what problem are we trying to solve” question that grizzled consultants pose to annoy eager young MBAs and impatient clients.

It’s worth giving this task an identity separate from the tasks that follow. It’s like that pregnant moment at the end of a countdown to launch just before movement begins.

I was usually good at the  stuff that gets rewarded in school. Good enough to  get away with also being a bit of a smart ass. The problem was that school came easily enough that I rarely had need to develop good study habits. Not a problem that I worried about at the time. The bigger problem was that I never saw the connection between study habits and effective work habits after you left the classroom and wandered into real life.

For a long time, this wasn’t actually a problem because there wasn’t a deep connection between schooling and real life. The only habits taught in school that mattered for later were to show up on time and do what you were told.

An odd thing about the knowledge economy, however, is that almost everything you do in school is a form of knowledge work. It’s a place where you could be laying down habits and practices you can call on in the future. Instead, we’re evaluated and rewarded for demonstrating our mastery of content. No one pays attention to how we developed that mastery.

Today, there’s increasing attention to the notion of learning how to learn and there’s lots of advice and material on note-taking techniques, or memorization tricks, or thinking habits. But, it’s all secondary. We let the superficial differences between the classroom and the real world obscure the deeper alignment we could be exploiting.

That’s a missed opportunity. The content we learn will become obsolete, but the practices will retain their value. The classroom should be where we develop the habits and practices we could continue to employ when doing knowledge work for a living.

Moving classes online back in March triggered a new emphasis on the notion that the knowledge work we do is better and more easily done when you get it out of your head and somewhere in front of you where you can see it and improve it. This is a position I’ve come to only after a long process of fighting the notion in practice and gradually coming around to that notion and working to update and adapt my own work habits and practices.

Practicing what you preach is always much harder than the preaching part. As part of convincing myself to work harder on improving my practices, I went back and gathered up some of the key moments in the evolution of my thinking if only to shame myself into more practice and less preaching. It occurs to me that assembling these pieces in one place may be useful to others as well.

• Review – Sound advice on managing collaboration in teams – There’s a particular point in this piece about evidence that teams charged with creating new ideas always seem to revisit and replan their efforts somewhere near the midpoint of their work.
• Balancing Uniqueness and Uniformity in Knowledge Work – Most of what we have to say about work emphasizes uniformity and predictability. My Toyota Prius and yours should be substantially identical. Knowledge work is the opposite; the work in only valuable to the extent that it is new and different
• Managing the visibility of knowledge work – In a technology dominated economy, knowledge work is effectively invisible and that makes it harder to manage.
• Observable work – more on knowledge work visibility – They say you can’t manage it unless you measure it. If you can’t see it, how can you even measure it?
• The 80 IQ point move: knowledge work as craft – Stop thinking in terms of factories and start thinking in terms of artisan workshops
• Crumbling pyramids; knowledge work, leverage, and technology – Organizations built around knowledge work are also built on apprenticeship models both functionally and economically, Technology is making apprenticeship harder to manage and sustain.
• Doing and Managing Knowledge Work: TUG2010 Keynote Reflections – This was the place where I first started to talk about the notion of “observable work”
• Showing your work- intermediate knowledge work artifacts – We need to move beyond the notion of deliverables and make the processes of knowledge work visible throughout
• Bring back working papers – Paper intensive work practices threw off useful intermediate artifacts. Now we need to design those intermediate artifacts
• Effective Executives Are Design Thinkers – We tend to think of design as a specialty skill. I think it’s become an essential skill for anyone doing or leading knowledge work.
• Communications Divides Within the Organization; Look to Homer – Here’s some rumination on a distinction first proposed by a Jesuit priest named Walter Ong. His thesis was that writing gave us a new way thinking quite different from the oral thinking that represented much of early civilization.

In 1992, Larry Prusak and I were working for Ernst & Young exploring the links between information technology and strategy. We thought it would be a good idea to organize what we knew and turn it into a book. We put together a short proposal, pitched the idea to the powers that be, and landed a contract with John Wiley & Sons to deliver a manuscript. Being a diligent project manager, I sat down to plan the effort. We had worked out a chapter outline, so I started with that classic planning strategy of working backwards from the deliverable.

I wish I could lay my hands on that outline and the plan I wrote from it. We reorganized the book from top to bottom multiple times between that first outline and the final manuscript we delivered. My first reaction was to blame myself for being a much worse project manager than I claimed. My second reaction was to focus on the estimating error of not factoring in the multiple revisions and rewrites that happened with each chapter.

It took a long time to recognize the deeper lesson hiding in plain sight. Successfully working backwards from a target deliverable depends on how clear a picture you have of that deliverable. There are always pressures trying to convince you that your picture is sharper than it is.

The temptation whenever you start a new consulting project is to generate the outline of the final report as part of your proposal efforts. That, however, applies an industrial, mass-production, mindset to a process that ought to be about addressing the unique problems and situations of this client in this moment. On the other hand, clients come to you because you have a reputation for solving problems similar to the problem they believe they have .They are paying for your expertise.

How do you draw on the work you have delivered in the past, without succumbing to the temptation to phone it in? How do you fold in knowledge of prior deliverables without blinding yourself to this problem’s new, and possibly unique, questions? Rely on prior deliverables too heavily and all you do is create variations on a theme. Ignore the lessons contained in prior work and you are no more valuable than any random smart person.

Assuming you bring a threshold level of professionalism to the task, what else can you do to avoid being led astray by old answers when you are facing a new problem? One thing is to distinguish between how far you can see and how clearly. Working backwards is a useful strategy, but that doesn’t mean you are in a position to work backwards from the finish line. Thinking through deliverables is only one tool in your kit.

Some pointers to prior thoughts on deliverables

I’ve written about deliverables multiple times on this blog. Here are a few of the more immediately relevant entries.

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

– Deliverables – the fundamental secret to improving knowledge work

– How better thinking about deliverables leads to better knowledge work results