One of the tasks that needs to be done, but doesn’t feel like you’re doing anything, is planning. Planning your day, or week, or planning a project: these are all exercises in prioritisation.

It’s a universal truth that we all have the same number of hours in the day. Those who seem to get more done, have just prioritised differently. Lamenting that you’re just “too busy” is saying that you’ve prioritised enough things.

When doing knowledge work, planning for – and prioritising –the tasks of reviewing, writing, approving, or storing documents and reports is not lost time, it’s doing your job.

A common frustration in knowledge work is not being able to make enough time to do all the reading required in our roles. It takes effort to read for comprehension, and that can’t be done by skim-reading or speed-reading.

Another frustration is with the documents themselves. Many of them are not very readable. The logic, layout, and content are not presented in a readable way.

There probably are a lot of words in those reports, specifications, or standards, but in many cases, knowledge is awkwardly, not smoothly, transferred.

The length of a report shouldn’t convey its worth: the content should.

Reviewing other people’s work is a key part of being in knowledge work. Getting our own work reviewed is also a key part of doing knowledge work.

The review cycle culminates in the ole signature on the signature panel. Sometimes the signature name is printed and legible, sometimes (most times?) it’s not. On drawings it tends to be a tiny scribbled initial, usually hard to read.

Maybe it only matters who signed it when something goes wrong; but it should matter always. It should matter when you’ve put your signature on the signature panel: you’ve now demonstrated knowledge, and competency.

In most managerial roles, there is a point in time when you will need to approve something. This might be approval of a budget expenditure, approval to retrench a portion of your workforce, or better yet, approval to hire new resources to help with the workload.

The other kind of approval falls more often to technical or engineering roles, and that is the approval of a document, design basis, report, or specification.

Approval of knowledge-based documents should not be taken lightly. There is responsibility inherent in that approval. It confirms that you are consciously taking responsibility for the document content.

Here is a definition of context: “circumstances that form the setting for an event, statement, or idea, (so that) it can be fully understood. Example: ‘the proposals need to be considered in the context of new European directives’.”

The example is useful. Because if we were to, say, review the proposals in the context of old American directives, the review will be ineffective.

Context is everything. When you send around a document for review, include information about the context. It makes a difference to the reviewer, whether they review for clarity, grammar, or, in the context of future Australian directives.

Sending a document around for review should include three pieces of information: a deadline, the context, and, a preferred format for comments.

Comment format is not a well-developed part of knowledge work. With all of the advances in technology, the task of marking up text documents seems to have missed the boat. Most review cycles I see are more disorganised than they could be.

As a minimum, tell reviewers whether you prefer in-document markups (track changes), or commentary in the margins.

You’re in charge of the process, so think about what you want. And then, tell them what to do.

A task that many knowledge workers will do many times in a career is to review someone else’s work. And hand-in-hand with that, is the complement task of sending your own work around for review.

One thing we never seem to do, in either role, is allow enough time to do the review thoroughly. The person sending probably forgets to allow time to deal with the comments that come back. And of course, the reviewer inevitably ends up scrambling to skim-read it moments before the review comments are due back.

Both roles (reviewer and sender) benefit. Allow yourselves enough time.

The most common mistake made in knowledge work, is sending a document around with action “please review this and let me know your comments”.

The intentions are noble. In fact, other problems will develop, if documents aren’t reviewed.

The expectations are known. Well, perhaps it’s more appropriate to say both parties know the expectations. Sort of.

The three things wrong with that request are 1) there’s no timeline given to return comments, 2) no indication of what is the preferred format for the comments, and 3) the context is not given to help the reviewer focus on the right thing.

Part of being in knowledge work is the task of ‘redirecting’ that knowledge. Our tasks require taking some bit of knowledge, adding value to it, and passing it to the next step in the process.

Working on our computers, or on the phone, or reading or writing or filing. When talking to others, when collaborating, when presenting in a meeting: that’s all redirecting your knowledge to someone else, to be used for something else.

Otherwise, it’s not knowledge work. If we’re not redirecting our knowledge, after having added value to it, then, it’s work that a robot could probably do.

It’s a bit of a puzzle that I’ve done management consulting work, and I don’t recall coming across the work of Elliot Jaques (1917-2003). I had to look him up.

He’s apparently a ‘controversial Canadian theorist’. One article, though, proved we’re not related. He pronounced our surname “Jacks”, whereas my (correct) pronunciation is “Jakes”.

I’ll dabble into his theories. The marked thing is the origin question he explored: whether there is any importance to the fact that the salary of low-level workers is estimated on hourly, daily, or weekly basis, while salary of executives is described as an annual amount.

Video is catching on as a medium to teach, communicate, and socialise. Of course, through 2020, it became the only way to communicate in many cases.

Video makes a lot of sense as a reporting mechanism. Just because I go on a bit here about how important the writing of reports is, doesn’t mean I don’t realise that video may continue to become a major communicate mode.

However, to differentiate your video report from a rambling influencer on youtube, you probably want to properly write out and structure your report, regardless of whether it’s delivered on paper or on video.

Communicating through reports is required in most knowledge work. At some point, you’ll write a document. And there are different types of documents, of which reports are just one of them.

In knowledge work, most documents will then be read by someone else. That someone else will receive your words and interpret them into their own knowledge work.

Writing reports – or any document – demonstrates your ability to communicate and also goes a long way to demonstrate your knowledge.

So, while you might strive for leadership roles, it’s wise for everyone to have written effective documents on the way to leadership.

Reports are written to inform, to provide conclusions or recommendations, or to communicate a result. It’s possible there are more reports written than are needed. It’s probable that many reports are longer than they need to be.

If we remind ourselves why the report is being written, it may reduce extraneous information. If we’re clear who the audience is, before starting the report, it may be a different report than if written for just ‘anybody’.

Join me on March 10th for a webinar that will help identify keys to good reports, and more. It might help you write anything better.

Report Writing. If you're in the knowledge workspace, you probably read or write reports. Probably both.

Episode 3 of my Beyond 100 series will cover that very essential ingredient of communicating knowledge: the writing of reports.

The whole point of a report is to communicate knowledge. So, when a report is incoherent, disorganised, disjointed, or seems to not communicate knowledge at all, then it is simply not effective.

On the other hand, when faced with the task to write a report, knowing how to start can alleviate the likelihood of an incoherent, disorganised, disjointed report that doesn’t actually communicate knowledge.

I’ve always enjoyed the silly little wordplay with my birthday being the only day on the calendar that tells you what to do. You know, march forth, march ahead, march on.

It’s wordplay, and, words are so important.

It’s the only way we communicate, through words. Whether written, spoken, or even sign language or the 110011 of binary coding.

We communicate through words. Communicating knowledge is essential in the knowledge work environment.

So, march forth.

(The photos are from my 50th birthday ski day last year. It has become a beautiful bookend, to a decade, and to life before Covid.)

A common approach to storing of information is “I’ll do it later”. This is a mistake.

Like you brush your teeth every day, doing a little bit of filing of accumulated knowledge every day is an essential step to efficiency.

We all know the fuzzy feeling on our teeth if we miss a brush. Unfortunately, there’s nothing equivalent when we don’t file away the day’s knowledge.

But long term, like that fuzzy feeling turns into rotten teeth, the unfiled pile of knowledge becomes a monster on the desk or on the screen.

Storing information efficiently starts with a daily routine.

The first mistake made when it comes to reading, is not allowing enough time for it.

It’s too easy to think it will ‘only take a few minutes’ to read a 25-page document. No. To comprehend it properly, you need at least 30 minutes.

We can debate speed reading hacks, and perhaps there are reading skills that can be developed to improve reading efficiency. For the average reader though, mostly you just have to allow the time to read.

So, when reading reports, specifications, or a contract, or anything else important for your knowledge work, do reserve time for it.

The easiest writing mistake to fix, for reports, technical specifications or similar, is to write shorter sentences.

Reading a report recently, I came across a sentence that was 68 words long!

Sentence length should vary. The maximum length should be about 20 words.

Fiction and literary prose can get away with long running, deep and dreamy sentences that go on and on, carrying more than one thought or topic, because reading fiction is very different to reading technical or knowledge-based information; so, do yourself a favour and split the sentences. (That one’s only 47 words and it’s already a head-spin).

There are mixed messages around mistakes. We’re told to learn from our mistakes; but then again, there are situations when mistakes should simply not be made.

Sometimes mistakes are minor (like misfiling a report), and sometimes they are catastrophic (like using an outdated revision drawing for a piping modification).

Everyone handles mistakes differently: proudly owning them, hiding them away, or, ignoring them and hoping no one notices.

We all know we are all going to make mistakes. The practical accept the probability, and try to have plans or solutions to prevent them, or to deal with them when they happen.

If you deal with documentation or knowledge, it’s an infinite loop of tasks and requirements.

An infinite loop is not a bad thing: it can be quite powerful actually. If there’s one thing that cures uncertainty, it’s predictability. And that can be an infinite loop.

Because if you’re in an infinite loop, at least you might know what’s coming up next. You can be ready for it.

In our documentation/knowledge loop, the infinite tasks are: read, write, edit, approve, retrieve, utilise, store, redirect, review, plan, and think.

During work time, you will be on one of those tasks. Expect it.