March 25, 2019

A Knowledge Workers Toolkit

Knowledge work can have some pretty tricky characteristics that renders it distinct from physical work. For one, it defies quantification. While chefs, carpenters and other tradespeople can see their efforts take shape into concrete, material output, the knowledge worker is not so fortunate.

Our raw materials are intangible - what tools could we use to manipulate them? Likewise, our output can seem quite ephemeral - did the thing we produced actually add value, and by what measure1? Worst of all, the effort we spend2 is elastic and difficult to wield in a consistent and predictable way. Time and attention spent often never translates directly into value extracted. Sometimes something as nebulous like a change of perspective can yield great benefits in orders of magnitude, but other times we may stutter and struggle for days to make any progress3.

Despair. How are we to cope with this and take control of our own faculties? What tools can we build to apply to our problems? Perhaps by applying a little metacognition (thinking about how we’re thinking), we can be a bit more deliberate and maybe obtain some tools for thought.

Mental Models

Arguably the closest thing to real tools we have are the mental models we employ when working on a problem. This is true is the most general sense, from changing a tyre to analysing a dataset. We’re always using an abstraction to make sense of the world. It helps us to make decisions that will give us the outcome we want. Success depends greatly on how closely the mental model we employ corresponds to the external world.

All models have limitations, however. They’re always bounded approximations since we’re only human and not omiscient: we can’t keep the full description of the universe in our heads. So it’s useful to be aware of the limitations and assumptions of the model we’re using. Find the boundaries, so to speak, and we may expose some biases.


Bias in this case is the tendency for a mental model to favour certain outcomes when applied in a context. I don’t think this is categorically bad, as we’re usually led to believe.

To reason about this, I like to think of the oft-cited quote by George Box4:

“All models are wrong but some are useful.”

A cleaver is great at chopping meat but perhaps rather unwieldy for peeling potatoes. This is because a cleaver has the characteristic of being large and weighty, with a flat blade edge well suited for chopping motions. However, it lacks a small, sharp, angled blade that is more suited to slicing and peeling.

We can analyse mental models in the same way we do with real tools. But first it may be useful to say that they all exhibit at least two types of properties. Ones that are direct and intentional (by design), but also some traits that are unintentional and emergent.

For example, using a metaphor of building construction to frame how software is created immediately brings us to think about it as a sequential process. One in which we lay blocks upon blocks of foundations until we complete a structure. The unintentional consquence of this model is that it hides the relationship between local and global components. Even worse, the metaphor offers no helpful description of how the software might behave. Its bias is the assumption that the whole is merely the sum of its parts. And that could obfuscate other aspects that may be important.

Some Characteristics of Models

In order to be more mindful of the mental models we’re using, it’s useful to know some qualities we may want to evaluate them against5. I’ve often used the following points to try and explore a problem space:

  • Precision: does the model have a quality of precision that can be tweaked? Does precision mean being being more specific (semantics) or purely in the mathematical/quantitative sense?

  • Fidelity: is there a threshold of quality we can increase/decrease to make different things noticable?

  • Topology: is distance and connectedness important aspects of the model?

  • Boundaries: are there any delineations between things? Are they strong or weak/porous?

  • Temporality: does time play a central role in interactions? Are events sequential or asynchronous?

  • Directionality: is there a direction in which things go important?

  • Authorship: do we have direct control on the outcome or can we merely direct it by manipulating second-order things?

  • Economics: is it useful to introduce an element of cost? What should be made cheaper or more expensive?

  • Relational: are there traits that make certain things belong together or interact? Are they fuzzy and probabilistic, or concrete and deterministic?

These are just some general things that may be useful to think about when approaching a problem. They are incomplete (this is not an exhaustive list) but I’ve often found some of them helpful when applied deliberately to problem solving.

In future posts, I hope to expand on specific models that I’ve used to make sense of phenomena I’ve encountered in software development. Hopefully, they will useful or at least entertaining to explore.

  1. And does it retain value or will it diminish? [return]
  2. What does it mean to expend effort? Can “effort” be substituted for “attention” or something else? [return]
  3. Chances are, you’ve probably experienced a fair share of Parkinson’s Law, especially if you work in an office. [return]
  4. He was of course referring specifically to statistical models, but I think it can be generalised into “all abstractions are wrong but some are useful”. [return]
  5. Unfortunately, none of this is ultimately useful without a context, but they offer a good foundation for exploring. [return]

© Sett Wai 2018