The Essence of Knowledge Work, Part 3

Knowledge workers take in information, process it by applying their knowledge to it, and output information (possibly) in a different format than they received it. You, like many other knowledge workers, produce your output artifacts by applying knowledge to the input you receive. Your knowledge includes everything you know and the input you receive from all possible sources, too. There are three dimensions to the information needs that each knowledge worker has:

  1. Dependencies (who needs your output and who provides you input)
  2. Information artifacts and their format
  3. Timeline for artifact delivery (time frame)

This is the last part of a three part series. Part 1 tackled dependencies. Part 2 looked at information artifacts. The focus of this article is the timeline for artifact delivery.

Life and business runs on commitments. A commitment includes the artifact that you deliver, a timeline on which you will deliver it, reporting on the progress of creating the artifact, and reporting on the final delivery. Businesses small and large run on commitments. Teams run on mini and micro commitments that team members make to each other. You must go to great lengths to meet a commitment you made to a teammate. When you realize that you cannot meet the commitment you made, then you must go immediately to the teammate and renegotiate the commitment.

Sometime this timeline is constrained by needs, contracts, or events beyond your or your colleagues’ control. This agreement is often derived from external commitments that the team made. While many times people would prefer to plan forward, most often you must plan backwards from the commitment date. See: Brief Introduction to Personal Planning for details.

For example, if the code needs to be tested before it can be shipped, and the testing team needs a day to test, and the deadline is COB Friday, then the developers must deliver the code no later than Thursday so that testing has enough time to test. If you factor in the possibility that testing might find a few defects, then maybe the code should be delivered on Wednesday, so that the team has a day to find and fix those defects.

It helps if you think of yourself as “Me, Inc.” and imagine that your colleagues that need to receive your output are your clients. The colleagues that deliver to you their output are your suppliers. You want to treat both your clients and suppliers well. (If you’d run your own business, you’d not make your clients wait or give something that they can’t use, because you’d not be in business for long.)

At times you might be upset that a “supplier” promised something that you need that has not arrived when you needed it. Give them the benefit of the doubt and go talk to them. If they have always delivered before then you should ask “What might be going on with them? What might hold them up?” Maybe they are trying their best, but something is not working, or maybe you just asked for something outside of their areas of competence. Ultimately, you will be more successful if you work with them and help them be successful so that they in turn can help you be successful.

Your value-add. The difference between what you get and what you provide is your value add. This is what your business (Me, Inc.) is providing to its clients. This has to be big enough for you to stay in business. Once or twice a year examine the value-add that you provide and validate that you are still providing a market competitive value in the domain that you are working.

At least once a year audit and measure your productivity. Think of ways to improve it, so that you can provide the same value in less time, or more value in the same time. A productivity improvement of about 2-5% is expected of you in most jobs. Consider that after a while, the only way that you can improve your productivity if you radically rethink not only your work, but possibly the entire work process in which you participate.

Allow time for learning. When you first start defining the artifacts and committing to timelines, make sure that your commitment timelines include time for learning. Keep in mind that nothing that you do for the first time works as you want it to work (true for all of us). Don’t be too hard on yourself. Give yourself a few months to get better at identifying your clients, identifying their needs, and negotiating the format and timeline of the artifacts. With diligent observation of your performance you will get better and better at delivering your work in a way that others will be able to use and appreciate. In turn, your suppliers will also get you what you need.

In Summary

The essence of knowledge work is the realization that knowledge workers must produce an output by applying their knowledge to the input they receive. The output must be in form of an artifact that some other knowledge workers can consume as their input. Understanding this is both empowering and practical. It will help you get better at what you do.

Start by asking who is relying on you and your output to get their work done. Are they getting what they need? Then figure out what do you need and from whom? You are processing information by applying the knowledge and experience you have to the input you receive. Your output must be in a format that your consumers can effectively consume. You must deliver on a timeframe that they expect so they can deliver on their commitments.

The work processes that tie the members of your team together into a sequence of people who deliver their output to one of their peers creates an information supply chain in your organization. A well thought out and executed information supply chain is a key ingredient of successful teamwork, and in turn key to successful organizations.

Enjoy the journey!

The Essence of Knowledge Work, Part 2

Your information supply chain consists of all artifacts that you consume (produced by your colleagues) and the artifacts that you produce (consumed by your colleagues). You produce your output artifacts by applying knowledge to the input you receive. Your knowledge includes everything you know and the input you receive from all possible sources, too. There are three dimensions to the information needs that each knowledge worker has:

  1. Dependencies (who needs your output and who provides you input)
  2. Information artifacts and their format
  3. Timeline for artifact delivery (time frame)

This is part two of a three part series. Part 1 focused on dependencies. This article focuses on information artifacts and their format.

What do your colleagues need from you? Do you know? Did you ever ask? For a software engineer the quick and obvious answer is that they need code. After all, a software engineer writes software, so that’s what others need. True, and it is not the complete answer. Talk to your colleagues to find out what else do they need.

Based on my past experience working on software teams here are two partial list of output and input artifacts that are expected from a software engineer and what a software engineer expects.

Software engineer outputs (partial list of artifacts)

  • Code
  • Code review comments
  • Test case review comments
  • Use case review comments
  • Design
  • Design review comments
  • Documentation
  • Documentation review comments

Software engineer inputs (partial list of artifacts)

  • Code
  • Code review comments
  • Test cases
  • Defect reports complete with reproduction steps
  • Use cases
  • User stories and epics
  • Design
  • Design review comments
  • Documentation

Your team might be different, so you must ask to find out what the other people need. Negotiate both the content and the format. There is a good chance that you are not giving them what they need now.

What do you need from your colleagues? Think through your work and identify those artifacts that you need to get your work done. There will be some give and take until you arrive at a list and definition of artifacts that can be delivered to you.

The need for artifacts. Artifacts are the work product (the output) of each person on the team. This can take different formats. These artifacts manifest themselves as writings, drawings, sketches, movies, pictures, etc. Not just spoken words. (However, spoken words in an audio file might work. Ask to find out if it does.)

For example, for a tester the artifacts created are: test cases, test execution records, defect reports, process improvement recommendations, etc. For a requirements analyst the primary output artifact could be use cases and user stories written in a Wiki, or maybe in an issue management system, like JIRA.

These artifacts could be deemed high quality if the development team can efficiently and effectively use them. They could be deemed low quality if they are too wordy or are missing critical details. The job of the requirements analyst is to take in information, apply their knowledge and experience to it, and produce artifacts that can be quickly and correctly consumed by the rest of the team.

The same thing can be said about many other roles on the team. Each person (knowledge worker) is part of the team because they can contribute something that the others can’t do, or can only do poorly. However, each person must make their contribution accessible to others on the team. If the others have difficulty consuming it, then the person needs to improve their output.

The consumer of each artifact in addition to consuming it, must also provide feedback to the producer and jointly evaluate the format and the quality of the artifact with the intent of improving it. The producer must evaluate their performance at creating the artifact, factoring in the necessary quality requirements.

Some people you work with will not want to create artifacts. They don’t want to write down anything that you ask from them. You have to help them understand that writing forces them to clarify their thoughts and resolve the inherent contradictions that otherwise would not come to the surface. Remind them the quote:

Writing is nature’s way of letting you know how sloppy your thinking is.

Richard Guindon, cartoonist

The need for creating artifacts does not obviate the need to have high-bandwidth conversations about those very same topics. The goal is to arrive very quickly to an agreement on the content and format of the artifacts, so that each person can effectively create their part of the joint work.

Once you identify how best you can serve your clients, and your suppliers identify how best to provide you what you need, your and your team’s productivity will dramatically improve. You will wonder how did you ever work any other way.

… continue to Part 3: timeline for artifact delivery.

The Essence of Knowledge Work, Part 1

Knowledge workers take in information, process it by applying their knowledge to it, and output information (possibly) in a different format than they received it. This looks like the information processing business.

Input —> Processing (by applying your knowledge) —> Output

Information Supply Chain

This basic formula describes the essential building block of information processing. Applying this model to the individual knowledge worker provides some advantages. Allows us to critically examine each part of the model with the goal of understanding and improving the overall effectiveness of the knowledge worker: mostly when applied to ourselves.

That knowledge workers need to be in command of the information they use and produce has been known for well over 50 years, but very few ask the questions that will put them in charge. According to Peter Drucker:

To produce the information executives1 need for their work, they have to begin with two questions:

  1. What information do I owe to the people with whom I work and on whom I depend? In what form? And in what time frame?
  2. What information do I need myself? From whom? In what form? And in what time frame?

These two questions are closely connected. But they are different. What I owe comes first because it establishes communications. And unless that has been established, there will be no information flow back to the executive. 2

Peter Drucker

There are three dimensions to the information needs as described by Drucker:

  1. Dependencies (who needs your output and who provides you input)
  2. Information artifacts (that you provide and receive) and their format
  3. Timeline for artifact delivery (time frame)

In this part 1 of a three-part series, let’s look at dependencies first and tackle the other two dimensions in subsequent articles.

Understanding your effectiveness starts with the critical examination of your own work. Who is depending on your work to complete their work? These are the people who are (sometimes) repeatedly asking for the slides, spreadsheets, design, unit test, component, or—fill in the blanks—from you. Some of these people will be complainers that you can’t please, but let’s not talk about them now. Here let’s focus on those folks who legitimately need your output.

An insightful way to wrap your mind around this problem is to think of yourself as a “company of one person” or as consultant and author Tom Peters put it: “Me, Inc.” Think of the people expecting your output as your clients. Talk to your clients about their needs and identify what you have to do to fulfill those needs.

The same way, think of the input that you depend on. Identify the people who produce what you need. They are your suppliers. You need to provide them with the proper requirements to get what you need. Most likely you will have to iterate with them on the requirements, since you may not know exactly what you need at the outset of any project. Do not over constrain what they should deliver to you (you don’t like it when your clients do the same to you).

Looking at a concrete example: as a knowledge worker in a software company who do you depend on and who depends on you? For example, if you are a software engineer you work with other software engineers, product managers, business analysts, UI/UX designers, testers, sales people, customers, etc. Some of these people expect things from you, and with others you expect things from them. Identify the people that depend on you and the people that you depend on to get your work done.

Sometimes, especially on very small teams, you might be your own dependency, as in whatever you create now, two weeks or two months later you will be consuming it, too.

At the core, the essence of knowledge work is information processing. You are applying your knowledge to the inputs you receive to produce an output. Crisply identifying the inputs, outputs, and the knowledge required will help you understand what you do, and how can you do it better. In subsequent articles I’ll tackle the other two dimensions.

… continue to Part 2: information artifacts.


  1. These days (in the early 21st century) when you read Peter Drucker writing about executives you can replace it with knowledge workers. 60+ years ago the majority of knowledge workers were executives, however today everybody who deals in information fits the definition.
  2. Drucker, Peter F. (2009-10-13). Management Challenges for the 21st Century (p. 124). HarperCollins. Kindle Edition.

Writing Crystallizes The Thought

Agile Teams often hold the belief that we should not write anything down because that’s waste. From a human perspective though we need to write things down because that’s the mechanism that allows us, or maybe even forces us, to think things through.

Even the Romans knew that “verba volant, scripta manent,” meaning “the spoken words fly away, written words remain.” So maybe the real question is not “Should we write anything down?” but rather “How much should we write down?” The face-to-face interaction should be followed up with the creation of an artifact that captures what the conversation clarified. This will serve as the basis for further decisions or conversations, or maybe assists in the reexamination of this decision when more data becomes available. Interspersing face-to-face conversations with written thoughts firms up ideas and speeds up the road to shared understanding and clarity.

Usually at this point somebody will jump in to say that all that writing is taking time and that writing a 100-page requirement or design document is a waste. Yes, 100 pages might be a waste most of the time. I think that the artifact produced should be a piece of focused and processed information. If it is 100 pages then it should be indeed a very complex issue, or somebody hasn’t done enough thinking about this. But I’ll leave this topic for another day.

This belief in writing things down was confirmed a few weeks ago as I talked to a new co-worker, Steve Feldman, who writes the Seven Seconds blog. He mentioned that he routinely asks his dev teams to blog about their work. The part of the work that is general in nature can be blogged on their outside blogs, while the company and product specific work should be blogged on the inside blogs. The act of writing things down externalizes the person’s thinking and opens up the ideas for a conversation with the rest of the team.

The blog entry with one’s thoughts will generate further conversation, both online and face-to-face. Each conversation should bring the team closer to identifying and solving the problem that they have set out solve.

Brief Introduction to Personal Planning

As a knowledge worker, you live in a world where a continuous stream of commitments are made and accepted ’round the clock. To succeed in this world, you must learn to make commitments and keep commitments. Since commitments that rest on a plan are more likely to be kept, you must learn to make plans quickly for your work and then carry out those plans effectively.

Maybe you have encountered the following situations: your client has to remind you that you haven’t provided the white paper that you promised over two weeks ago; you seem to be the last person to finish your work for the release and the rest of your team starts to notice it; or your presentation for the team meeting is not done until late into the evening the night before the presentation. If you have been part of the business world for a while then you know that commitments will be made–one way or another–so not making commitments is not a viable option.

The situations mentioned earlier often happen because you make commitments without thinking through and planning out that commitment. Sometimes you make commitments under pressure, direct or indirect, that influences you in ways that later come back to haunt. Or it could also be that you, like many people, probably feel that planning is arduous and unrewarding. It doesn’t have to be that way. With a little practice you can learn to make plans for yourself quickly enough to productively participate in the commitment making process. Armed with a bit of self-knowledge and a few handy practices you will be on your way to make planning fun and make commitments that you can keep.

Effective planning demands of you–and knowledge workers in general–to think through the information do you owe to the people that you work with. Specifically:

  1. To whom do you owe information?
  2. In what form do you owe that information?
  3. Under what timeframe do you owe that information?

You must make a plan to deliver that information successfully to the people that need it from you. This information represents your commitment and it might be in the form of written pages, diagrams, presentations, software code, or any other piece of work product. This is what you make, this is the output of your work. As a knowledge worker, your widgets are processed information: you take in one kind of information, think through it, analyze it, synthesize it, and produce a different kind of information ready for the next person to consume.

For you to do your job well, you must plan the processing of information into work products that your consumers need. Successful planning involves performing the following activities:

1. Identify Tasks. Identify and list out each piece of finished work that you are expected to complete. If the piece of work is bigger than what you can picture in front of you, then you have to figure out how to take it apart. You proceed on taking it apart until you can picture each new part in front of you. This easily can be the hardest part of the planning work in particular, and knowledge work in general.

2. Order Tasks. Arrange the work in the order in which you need to get it completed. The beauty of doing a plan for yourself is that there are no complicated dependencies. You simply list the work items in the order in which they can be done. If at any time you find that you got the order wrong, just reorder the list.

3. Estimate Size. For each piece of work that you identified, figure out the size of that work. The size can take many forms: How many problems do you have to solve? How many features and sub-features do you have to build? How many customers do you have to call? How many pages do you have to write? How many slides do you have to create? Remember that you will have to keep dividing things up until the pieces of work become small enough that you can wrap your mind around them.

4. Estimate Productivity. For each kind of work that you have identified, decide on a productivity metric that you can apply to doing that work. Search your past experience for anything similar. If you have never had a similar experience, then envision what would it take to do this and use your best judgement to establish a productivity measure for the work standing in front of you. Here you might consider the following: the number of pages that you can write per hour, the number of drawings that you can produce per hour, the number of defects that you can fix per hour, the number of problems that you can identify per hour, and so on.

If you estimate that you cannot get one item done per hour, then use the reverse measure and identify how many hours does it take to create one, for example how many hours would it take to draw a diagram.

5. Calculate Durations. For each piece of work apply the productivity measure to the size of the work that you estimated in the previous step, and compute how long will it take complete that part of work. This should be simple math: if you identified that your white paper is going be 6 pages, and you expect to write the paper at a rate of 2 pages per hour, then you are estimating that completing the white paper will take 3 hours.

This is where you might also want to think of some other tasks pertaining to the part of the work that may have eluded you originally: Should you have somebody review the paper? What happens if they find something in the paper which will require of you to rewrite the introduction? If you feel that these are likely scenarios, then include tasks for these in your plan.

6. Estimate Available Time. Look at your calendar and consider how much time you have available to complete this work. This involves thinking through all other commitments that you have already made, since those will also take up your time. Make sure to account for any small and large things that take up your time: preparing for a board meeting and preparing for a surprise birthday party for your friend could be equally time consuming and thus leaving you precious little time left to spend on the new commitment that you are about to make.

7. Calculate Schedule. Fill in your available time found in step 5 with the tasks durations that you computed in step 4. This will give you a schedule that can serve as the basis of your commitment.

8. Track and Improve. Once you start working on the tasks, track your time spent, record every new task that you discover, and track your time on those, too. Track with a purpose. Your tracking must validate the basic assumptions that you have made during planning: Have you identified the list of tasks correctly? Have you estimated their size correctly? Have you estimated your productivity correctly? Have you estimated your available hours correctly? When your answer is ‘No,’ then immediately ask: Why not? What caused the discrepancy? Can you figure out the cause of the difference? Can you find a way to correct for this next time?

As you answer some of these questions, you will find that your planning is going to become more accurate over the course of a few planning cycles. The more you have a chance to make a plan, track the plan, and analyze your results, the better you will get at this. This is not magic, not mysticism, it is only simple logic.

If at any time you find something wrong with the plan, you correct it on the spot. Record what you did and why you did it. Your list of corrections also serves to improve your planning.

Practicing the above planning activities may not make you a project planner who can plan the design and implementation of the next air traffic control system that requires coordination across multiple companies and hundreds or thousands of people, but it will make you a competent planner who can plan one’s own work.

In conclusion, to successfully make and meet commitments, you must learn how to plan your own work, understand your performance at doing the kind of work that you need to make commitments about, and continually observe how well are you doing. Your goal is to keep improving both your work and the planning of that work. Becoming proficient at planning and executing your work will enable you to become a much valued member of any team.

Enjoy the journey!


  • Watts Humphrey formulated these ideas relative to software development in his book A Discipline for Software Engineering.
  • Peter Drucker talked about concepts related to knowledge workers in many of his writings.