Category: Knowledge work

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

Back when I was a Chief Knowledge Officer, I struggled with the problems of how to better tap the collective knowledge and experience of an organization filled with extraordinarily smart people. There were the technical problems of what to collect and how to organize it. There were the organizational change problems of how to persuade those same smart people that sharing their expertise my way was in their best interest.

I had an epiphany when I came to see knowledge management less as an organizational problem and more as a problem for individual knowledge workers. From that problem, the first task was to figure out how to get better at sharing knowledge with yourself. Which led me to the notion of observable work. Dave Winer’s thinking on narrating your work was an excellent entry point to that train of thought.

During that process, I sketched the following diagram as I collected my thoughts:

Scarcely rocket science but it was helpful to me. The next step was to think about what larger scale patterns or clusters might be discernible That led to this picture:

I thought it could be useful to revisit this and unpack it from the perspective of more experience and insights culled from other smart people. Let’s start with generating a new list of “Stuff” that seems to have something to do with knowledge:

 

10K	Data Flow Diagram	Log	Speech
10Q	Data Record (row)	Lyric	Spreadsheet
Abstract	Database	Manuscript	Stanza
Acronym	Database Query	Map	Statistic
Affinity Diagram	Database Schema	Mathematical model	Statistical Model (Regression)
Agenda	Dataset	Melody	Statistical Test
Annotated Bibliography	Descriptive Statistic	Message	Story
Appointment	Dialog map	Mindmap	Subroutine/Module
Bibliography	Dictionary	Musical Score	Syllabus
Block diagram	Directed Graph	Network Diagram	Synopsis
Blog	Email	Note	Term Sheet
Blog post	Encyclopedia	Notebook	Theory
Blueprint	Equation	Orchestration	Threaded Discussion
Book	Federated Wiki	Outline	Time Series Analysis
Book Series	File	Poem	Timeline
Bookmark	File Folder	Phone Call	TLA, ETLA
Bug Report	Financial Schedule	Phone Number	Transcript
CAD Drawing	Flowchart	Photo	Trip Report
Calendar	Forecast	Podcast	Tuple
Card Catalog	Formula	Précis	Tweet
Case study	Gantt Chart	Presentation	Tweet Thread
Catalog	Glossary	Presentation Slide	Url
Chat message	Graph	RACI Matrix	Use Case
Chat log	Group Calendar	Reading List	Voice Recording
Chord Progression	Hyperlink	Report/White Paper	Video Clip
Citation	Index	Resume/CV	Video/Movie
Code	Infographic	RSS/News Feed	Webpage
Code Repository	instant message	Scene	Website
Computer Program	Interview Notes	Schedule	Wiki
Concept map	Issue	Script	Work Breakdown Structure
Concordance	Issue Inventory	Search query	Work Plan
Conference Call	Journal Article	Search results	Working Draft
Consulting Report	Journal Entry	Simulation model	Working Paper
Contact record	Journal/Diary	Sketch
Contract
Conversation
CRUD Matrix

You could continue to add to this list. Or, you could explore what subsets organized by discipline—mathematics, economics, programming—might reveal. I think the broad distinctions between notes, working papers, and deliverables remains useful I’ve been looking at those questions myself of late (notes, working papers, deliverables). My advice used to be to start with deliverables and work your way backwards. That grew out of years of consulting work focused on the needs of clients.

Lately, I’ve been wrestling with the problem of managing at scale either as an individual or as a larger group. Techniques and practices that work for a single project or a handful of clients/projects break down as both time passes and numbers grow. Organizations address these problems by dedicating resources to them. They create and enforce the rules that annoy individual knowledge workers who haven’t yet run into scale problems in their own work.

These kinds of problems often surface in data management settings. The simplest example that springs to mind is sorting a list of names and addresses. Someone setting up a spreadsheet to invite friends to a surprise birthday party might set up one column for name and another column for phone number. Simple enough. Someone who’s been burned before will start by splitting the name into separate columns for first name and last name.

The point is that the “obvious” solutions to knowledge work data management problems have lots of unanticipated flaws that don’t surface until you cross scale thresholds. It seems perfectly reasonable to file project deliverables away by client and project until you have a hundreds of clients and projects and none of that information helps you track down the regression analysis you did sometime last year for one of three clients but you can’t recall just which.

Zettelkasten advocates make a compelling argument that the classification schemes natural to a knowledge manager actively inhibit the creativity meant to be the defining characteristic of knowledge work (good tags and bad tags). There is more worthy thought and discussion about categories of notes and emerging structural layers of notes.

The conclusion that is slowly emerging for me is that part of being an effective knowledge worker is a need to design your own knowledge management environment and that this design needs to anticipate that your needs and understanding are a continually evolving driver of that design.

I’ve been nibbling around the notion of the data layer of knowledge work for some time. We’re accustomed to talking about deliverables in knowledge work. I’ve argued about the problems of visibility in knowledge work and the benefits of making knowledge work observable. Lately, I’ve started to explore the realm of working papers and intermediate knowledge work artifacts.

Three broad layers are emerging in my model of the data layer:

• Deliverables: Presentations, reports, infographics, e-books, or any other self-contained package designed to be left in the hands of a client or the public. The notion of a deliverable is a powerful organizing idea, although it sometimes implies that anything not a deliverable isn’t relevant.
• Working papers: Spreadsheets, process flows, trip reports, design sketches, use cases, statistical models, simulations or any other intermediate work product useful to an individual knowledge worker or to a project team. Working papers may or may not be shared with others.
• Notes: Everything else. Interview notes, reading notes, journal entries, outlines, mindmaps, whiteboards, marked up placemats from breakfast meetings, or any other external representation that helps a knowledge worker capture or elaborate an idea.

Metadata

Since we’re thinking about data, we also have to deal with what metadata is necessary or useful to maintain. If you work down from the deliverables layer, the default choice is to group deliverables by project. If you do knowledge work for any length of time, project information grows complex. Any given project might be part of ongoing work for a particular client.

On the other hand if you work up from notes, other metadata questions surface. While you might be able to identify a project, notes and note taking often happen before you have a specific project in mind. Do you collect or preserve metadata about the source of a note—is a note about an interview with a client, your thoughts about something you’re currently reading, or connected to some ongoing topic of interest? ‘

Working papers can be carved out of bigger deliverables or bubble up from the notes layer as your thinking develops. Which suggests that these metadata requirements will be a blend of the layers above and below.

The point of collecting this metadata is to make the proliferation of materials in the data layer manageable. Extracting and reporting on metadata ought to make it easy to monitor the developing status of the collection of notes, working papers, and deliverables that comprise an active project. How many interviews have we completed? Have we tracked down the data for the regression analysis we are about to perform? How many uses cases have we identified? How many have been written? Reviewed?

Formality and Explicitness

For one person working on a single project, this seems to be an inordinate amount of fuss and worry about something you can keep track of in your head or informally by reviewing an inbox or browsing a file directory. For large scale efforts by large teams, it might pay to invest in full time staff and formal systems.

For the middle arena where we spend the bulk of our time, the temptation is to rely on informal methods and practices. That’s a mistake. A better choice is to invest some thought and effort into making these distinctions and introducing a modicum of formality.

Resources

I’ve worked on these notions in a number of place. There’s a lot of other, excellent, work in this realm; I’ll save that for another day and another blog post. This list is chronological:

• A Strategy for Improving Knowledge Work — Enterprise Systems
• Managing the visibility of knowledge work
• Observable work – more on knowledge work visibility
• Doing and Managing Knowledge Work: TUG2010 Keynote Reflections
• What’s in a name? Unexpected demands on 21st century knowledge workers
• Making knowledge work visible
• Showing your work- intermediate knowledge work artifacts
• Bring back working papers
• The 80 IQ point move: knowledge work as craft
• Knowledge work and stable intermediate structures

Early in my education as a computer programmer I encountered Niklaus Wirth’s seminal Algorithms + Data Structures = Programs. The fundamental insight was that algorithms and data structures have to be fashioned in concert; a good choice of data structure can simplify an algorithm, a clever algorithm might allow a simple data structure.

An example from the pandemic environment we are all living through is working with exponential functions (an algorithm). You quickly learn that expressing the data as logarithms (a structural choice) greatly simplifies much of the analysis. Complex curves turn into simple straight lines.

If you’re a good engineer, computer programmer, or data scientist, you’re trained to think about these tradeoffs in a systematic way. In the realm of knowledge work, we have lost sight of this useful distinction. We spend the bulk of our time and attention talking about the equivalent of algorithms.

What is the opportunity to simplify or improve our effectiveness at knowledge work if we devote more attention to the data layer of knowledge work? What kinds of tradeoffs should we be looking for when doing knowledge work? What choices about how we organize and manage data might improve the quality or effectiveness of doing knowledge work?

Working from home is revealing how much of our daily work is kept in check by guardrails we don’t see or think about. We’re struggling to explicitly handle and deal with stuff that the environment handled for us invisibly. I’ve written elsewhere about the value of making knowledge work visible to make it more manageable. This is further elaboration of that line of thought.

What’s guardrail? It would be anything in your environment that provides a constraint on how you work without interfering with the work. Examples include;

• dedicated office space
• dedicated personal computer in the office
• work email address
• work calendar with standing meetings scheduled
• formal title and position in the organization
• reporting relationship to a boss
• specified working hours
• work phone number and voice mail
• team assignments

None of these things are exotic. We take them for granted and that’s the point. They help everyone “stay in their lane” and maintain focus on getting work done.

Being able to say “not my job” has been a time-honored prerogative of many an office drone and organizations functioned quite well. As you rise within an organization, there are fewer opportunities to claim “not my job.” As an executive much of your job is to define the jobs and the lanes. In well run organizations, executives also acquire support systems they can call on to handle that scope and responsibility.

Executives set agendas, which means they also set the boundaries in the environment that matter. If you accept that knowledge workers also function as executives, then one consequence is that knowledge workers are responsible for setting and managing their boundaries.

Carving out a lane is a more demanding task than staying in one.

If you’re a knowledge worker, you are only person aware of all the competing demands for your  attention. Matrix management is one technique to acknowledge and negotiate conflicting priorities. It also assumes that those managing a row or a column in the matrix know more than the individual knowledge worker occupying a matrix cell. I’m tempted to leave off the qualifier and visualize knowledge workers simply occupying cells.

To return to the perspective of an executive for a moment, executives contend with many distinct systems—leading their organizations, serving on boards of other organizations, collaborating with peer professionals, contributing to their communities, and the like.

Each of those systems operates on an implicit assumption that their priorities are preeminent. Which leaves you as an executive or knowledge worker as the only person in a position to reconcile competing priorities.

One element in that reconciliation is working out what to do about guardrails. We don’t tend to think about them if they are well designed. As a knowledge worker you get to lay down guardrails or choose to ignore them. Either way, the responsibility has to be yours.

This feels like a separate task from designing and managing your substantive knowledge work. Let me offer a simple example from my own work. In addition to my consulting work, I am teaching, I serve on several not-for-profit boards, and I manage several ongoing activities at our church. One of the things I’ve done to create guardrails between these responsibilities is  to use separate email addresses and discrete inboxes for each activity. I’m letting a simple feature of my technology environment help me define lanes.

This process of consciously seeking opportunities to define lanes or guardrails in the work environment is an example of what my friend Benn Konsynski describes as “cognitive reapportionment.” It is a component of being a knowledge worker in today’s environment.

Peter Drucker is one of those intellectual heroes you end up with if you’re of a certain business/nerdish bent. What can you say about the guy generally thought of as one of the first management gurus who also observed that:

I have been saying for many years that we are using the word ‘guru’ only because ‘charlatan’ is too long to fit into a headline.

One of my favorite Drucker books is *The Effective Executive.* I did a fairly lengthy review a couple of years ago (Effective Executives Are Design Thinkers). His  argument is that executives must focus on being effective—on doing the right things—and not worry terribly much about whether they are efficient.

He would be bemused by today’s obsession with productivity and “getting things done.” He had no objection to doing things right; he simply thought it was a very distant second to doing the right thing.

Drucker is also credited with coining the term knowledge worker. Lately, I’ve been thinking that the term “worker” is misleading. A worker is someone who operates within the structure and guardrails laid down by those executives focusing on doing the right think. If we’re not careful, this absolves the worker from responsibility for choosing what constitutes “the right thing.”

How often have you heard someone claim that they are only a “worker bee?” Perhaps you’ve said it yourself at some point. This is an attempt to deny responsibility for effectiveness; to ask someone else to make the hard decisions about the right things to do.

What the knowledge economy does is to remove the distinctions between executive and worker. We are all both and own the problem of choosing the right things to do. Each of us needs to work out and continually update our list of right things to do; we are each responsible for becoming effective.

That’s much more demanding work than being efficient. Being efficient means optimizing within the context of a stable environment. Who wouldn’t like that?

The last few weeks have been a powerful reminder that we don’t operate in a stable environment. That has been true for some time. Now, it’s harder to pretend otherwise.

If we want stability, then we must create it from the choices we make.

This was Drucker’s insight about executives. Their first responsibility was to make conscious choices about what were the right things to do. What executives do is to create stability. And this responsibility now belongs to each of us.

Last time out we talked about the idea of a stack as a simple metaphor for organizing and thinking about underlying complexity in technology or organizations. I thought it would be worth taking a look at some of the origins of fighting complexity in the technology realm that brought us here.

Computer software is among the most complex constructs of human creativity. Wrestling that complexity under control has occupied the attention of many smart people. Talking about technology stacks is a shorthand way of thinking about this complexity. We’ve touched on the problem of complexity. The other problem we have to address is change.

There are three core concepts from the systems design world that are worth understanding and adapting to the organizational realm. They all relate to the design question of how best to carve things up into reasonably discrete pieces. The world of software is all thought stuff. There are few external constraints to shape your designs.

Systems designers look at three concepts when they are evaluating design choices about ways to carve a big system into more manageable pieces:

• information hiding
• coupling
• cohesion

Information hiding is the systems design equivalent of “need to know.” How do you keep what you reveal about a module to a minimum? Put another way, what secrets are useful to keep.

Coupling and cohesion are complementary concepts. Cohesion is a measure of how closely the internal details of a module fit together. Do we have a team where everyone knows their role and responsibilities or do we have a random collection of people moving in the same general direction.

Coupling measures the degree of connectivity between modules. Cars traveling the same highway are more loosely coupled than the cars making up a commuter train.

If you’re interested in digging deeper, I’ve added pointers to some of the underlying literature where these notions were worked out. Think of it as a bit of information hiding on my part. If you’re comfortable with this level of explanation, you’re done. If not, you have the path to where to go next.

Once you have a clean mental model of a stack of modules formed by applying notions of information hiding, coupling, and cohesion you have a strategy to cope with complexity with less risk of finding yourself overwhelmed. If you can get a reasonable answer to your question at the layer you see, then you’re done. If not, you work your way down to the next layer. There are few questions that will require you to dig through multiple layers to find an answer. There are fewer still that require you to keep every layer in the stack in mind to understand.

Next time we’ll see how we might translate this strategy from technology to organizations.

Pointers to background work.

Nygren, Natalie. n.d. “Missing in Action: Information Hiding.” Steve McConnell. Accessed March 7, 2020. .

Parnas, D L. 1972. “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM 15 (12): 6.

Stevens, W P, G J Myers, and L L Constantine. 1974. “Structured Design.” IBM Systems Journal 13 (2).

I’m a fan of case studies–both as a teaching tool and a research tool. They’re often disparaged. And caricatured. I certainly had my own reservations when I first encountered them. Why couldn’t somebody just lay out the problem and get on with solving it? What was the point of all the arguments and background and history and politics?

As I’ve written about before, I was eventually invited into the process and became a case writer. Now I was inside the mess and searching for the threads I could weave into something coherent. What had seemed unnecessarily complex as a student was a deliberately crafted simplification of the actual situation.

There’s an old maxim that the best way to learn a subject is to teach it. Writing stories about it is a close second.

In organizational settings becoming a competent performer is a process of learning the important stories. In most organizations that was largely an oral tradition. It was also an oral tradition that largely took care of itself. Most of us could sit back and gather round the watercolor while older and wiser heads clued us in to what was important and what was passing fancy.

That’s not so true anymore. Organizational and environmental change continues to accelerate. The people who might have the perspective to recognize and craft the relevant stories may already be gone or at the tail end of shortening tenures. What was once an organic outgrowth of routine organizational activity now has to be recast as an intentional and designed practice.

I think it has also become a more democratic and decentralized practice. In effect, we must all become case writers about our organizational environments. Resources and power flow to those who can weave the most compelling stories.

It can be tempting to interpret this as an indicator of organizational decay. A better view is that the most coherent stories warrant the organization’s resources. Learning to craft stories that are the right balance of threat and opportunity, tradition and innovation, and process and people becomes the new form of a compelling business case. The business case evolves from being a recitation of facts and figures to a story that enlists the right team of rivals.