One. Two. Three. Four. Five. Six. Seven. Eight. Nine. Ten. Eleven. Twelve. Thirteen. Fourteen. Fifteen. Sixteen. Seventeen. Eighteen. Nineteen. Twenty. Twenty-one. Twenty-two. Twenty-three. Twenty-four. Twenty-five. Twenty-six. Twenty-seven. Twenty-eight. Twenty-nine. Thirty. Thirty-one. Thirty-two. Thirty-three. Thirty-four. Thirty-five. Thirty-six. Thirty-seven. Thirty-eight. Thirty-nine. Forty. Forty-one. Forty-two. Forty-three. Forty-four. Forty-five. Forty-six. Forty-seven. Forty-eight. Forty-nine. Fifty. Fifty-one. Fifty-two. Fifty-three. Fifty-four. Fifty-five. Fifty-six. Fifty-seven. Fifty-eight. Fifty-nine. Sixty. Sixty-one. Sixty-two. Sixty-three. Sixty-four. Sixty-five. Sixty-six. Sixty-seven. Sixty-eight. Sixty-nine. Seventy. Seventy-one. Seventy-two. Seventy-three. Seventy-four. Seventy-five. Seventy-six. Seventy-seven. Seventy-eight. Seventy-nine. Eighty. Eighty-one. Eighty-two. Eighty-three. Eighty-four. Eighty-five. Eighty-six. Eighty-seven. Eighty-eight. Eighty-nine. Ninety. Ninety-one. Ninety-two. Ninety-three. Ninety-four. Ninety-five. Ninety-six. Ninety-seven. Ninety-eight. Ninety-nine. One-hundred.

Those who know me, know I participate in ultra-endurance events like Ironman triathlons and running events of 100km or more. This weekend, I was signed up to participate in a unique event called a “backyard ultra”. Look it up if you’re interested. But never mind, it was cancelled, due to the snap lockdown in Brisbane this week. I guess I’ll run a few loops in my neighbourhood instead.

I’m taking another break from #100wordsaday. It might be for the weekend; it might be for the month of April. As with a backyard ultra, we don’t know when it will end.

I was in a role as Acting General Manager of an engineering department, in my early 30s. It was during a takeover/merger, and the manager who had been seconded elsewhere was returning.

It was a pivotal decision moment for me, and he put it plainly for me. It was time to decide if I wanted to be a specialist (technical) or generalist (managerial).

Not that it was a difficult decision. I’m pretty sure I wouldn’t have been in the AGM role if I had leanings towards technical expertise.

If you’re going to be a generalist, be an expert at it.

Thinking, reasoning, making inferences, making sense. These are all required if logic required. Being purely logical is almost the opposite of being creative and innovative.

A logical argument first needs a solid and clear proposition statement, idea, or concept. That statement (or hypothesis) will either be accurate (true) or not accurate (false). To build confidence and belief in the proposition, some facts or details are presented. Eventually, when enough information and knowledge has transpired, a conclusion about the proposition can be made.

For those who lean towards being logical, also remember there are others out there who don’t think logically.

For any process or activity that has been done before, there’s usually a logical sequence for it. We benefit from the knowledge of those before us, who have figured out the best sequence.

A silly example is socks before shoes. Less silly examples are valve opening procedures, or painting the house walls before the timber flooring goes in.

The builder of the new house in our neighbourhood have put in the flooring before painting, and are calling themselves innovative. Innovation is important, and it’s fair to question ‘we’ve always done it that way’. But sometimes, it is better that way.

I see the word argument and often first think quarrel or disagreement. It’s unfortunate, because an argument is also a ‘thing’, as in the reasoning given for (or against) something under discussion. A good argument, as a thing not the action of, allows us to compare evidence, seek proof, and continue the process of reasoning and discussing.

A well-written report should pose a solid and clear argument, without being argumentative. The argument might start with a conclusion and explain how the author got there, or, it might start with examples and reasons, building to a conclusion. Either structure argues well.

Getting, or giving, an overview about a topic, project, or solution, is a necessary work task. Overviews are the helicopter, high level view.

An overview is a summary of a lot of other detail and knowledge. So, if you’re getting an overview, be cognisant that you are only getting a summary, which someone else has prioritised.

If you’re giving an overview, keep in mind the audience: their knowledge, experience, and expectations. In order to give a well-structured, logical, and understandable overview, you need to know your topic in great depth. Don’t underestimate the effort needed to give a good overview.

Learning a new skill, or entering a new market, has risks attached. Innovating by using unproven materials has risks attached.

In all cases where we are trying something new, there are risks.

I’m aware of a builder who has taken on a new line of business (residential in addition to commercial), as well as building the new home out of innovative materials.

A council inspector came by today and picked up on a number of safety and regulation breaches.

Either this innovative builder learns from this experience, and gets better, or, he goes out of business. Either outcome is right.

I read an insightful comment about “value” today:

“Something cannot be valuable unless it can be lost”.

The comment, by structural engineer Peter Stanford, was on a forum related to a discussion about credentials; in particular, the intrinsic value of registration (of engineers in this case).

The insightful point is that to value it, registered engineers should lose that registration credential in certain circumstances.

It’s obvious when related to things - they have value (your bicycle, your diamond earrings, your no-claim insurance bonus). It’s not so obvious about skills or abilities. These are also valuable; they can also be lost.

Proof-reading is something any writer, of anything, in any context, should just do. It’s especially important in knowledge work. But any writing – be it emails, reports, technical specifications, letters to the editor, or comments against articles: they need to be proof-read.

The sole intent of proof-reading is finding errors.

And if you’re too close to it, it might be hard to find them.

A trick I’ve used for important documents and reports, is the ‘read aloud’ function available in MSWord. Hearing the text spoken aloud has picked up minor errors, which when fixed, make the reports all the more polished.

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.