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!

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.

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

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 executives¹ 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. ²

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.