Let’s explore some terminology through an extremely relatable activity: doing the laundry!

Of course, the point here isn’t to understand laundry (although it’s inevitable that we soon will — I apologise for how nerdy it’s about to get), the point is to find correlations in the systems that we want to understand and improve!

Summary

In systems thinking, we model systems in terms of Stocks (lists or piles of things) and Flows (how those things move into or out of a given Stock).

When you have more than one Stock in a system, we can start to observe Feedback loops of items moving between them.

At greater orders of magnitude, we start to see streams of effort, and the overall, primary stream of effort, which we call the Value stream.

Systems have Capacity, and they have Demand. They also have Bottlenecks and Constraints.

Modelling with systems is recursive; we have smaller systems inside bigger systems.

Stocks

Wherever we have an accretion of items that all share the need for a common processing step (or choice among steps), we have a stock.

What are the stocks in the laundry system?

Work-in-process (WIP) laundry

Work in process: the term we use to describe things we have started but not yet finished. It doesn’t matter how likely it is that we’ll finish it; we’ve started it, so it’s WIP.

Each of these is a stock, in that they are discrete from one another. Any given garment can not be in more than one of these places:

• In bedrooms, in laundry baskets (or, let’s be honest, sometimes it’s the bed and the floor).

• All jumbled together in laundry baskets next to the washer (again, a pile on the floor is quite likely).

• Laundry sorted into batches - darks together, lights together, sensitive cloth separated.

• Same as before, but now we’ve dealt with stuff like stain removal.

• Currently washing

• Recently washed (ready for drying)

• Drying

  • In a dryer

  • Or hung on a line

• Recently dry (ready for folding, and ironing)

• Ironed (if appropriate) and folded, ready for packing away

Completed laundry

Clean clothes and linens, in the place we expect to use them: packed or hung in the right cupboards.

This is the ‘outcome’, the ‘business value’ of the process. Anything that isn’t here yet, is by definition WIP, and not-yet-valuable.

Everything else

The laundry itself, in all its various phases, is the obvious stock.

However, there are other kinds of stocks, too:

• Cleaning products — Detergent, stain remover, bleach, fabric softener, fragrance pellets, dryer sheets. Consumed at a rate that’s fairly consistent with the flow of laundry.

• Tools — Laundry baskets (an important batching tool — imagine having to hold piles of wet laundry in your arms!), the washer, the dryer, clotheslines, clothing pegs, laundry baskets. Not consumed, but eventually worn out, so there’s a slower form of consumption here.

• Waste — dryer lint is a waste product that is also technically a stock. If you don’t deal with it, you’ll quickly run into issues.

• People — technically a stock too! At least, from the perspective of the system, a person is an agent that is capable of accepting and relinquishing stock items. Not consumed, but it certainly can feel like it, sometimes 😂

Flows

A flow is movement to a stock (inflows), or from a stock (outflows).

There are so many common examples!

• Water in a sink: inflow from the tap, outflow through the drain hole.

• The temperature in a room: inflow from the heater, outflow through the window (in winter), inflow from the sun, outflow through the air conditioner (in summer).

Inflow and outflow can be symmetrical (like a sink which drains as quickly as it fills) or asymmetrical (much faster filling or much faster draining).

You’ll know how big this asymmetry can feel when the stock in question is your bank account 😄

The number of stock items that flow at a time can be few, or many.

• Pieces (as in ‘single-piece flow’) — when only one or a few at a time, e.g. washing a jacket or a pair of shoes.

• Batches — when there are many items at a time — e.g. typical laundry loads of clothes or linens.

If you re-read the laundry stock list above, you can easily identify the flows; just imagine what it takes for a given piece to move into or out of a given stock:

• Getting the kids to bring the laundry baskets from the rooms.

• Loading a washer. Unloading a washer.

• Hanging laundry to dry. Taking it down.

• Folding a pile from one basket to another.

• Packing laundry into cupboards.

When we include humans as stocks, then there are actually more flows hidden among these.

As a human being needs to move all laundry around (we don’t have commoditised end-to-end laundry robots yet), every time a human does something, they are ‘inflowing' laundry to themselves, and then ‘outflowing’ laundry into the next stock.

• Dirty laundry basket → person → washer

• Washer → person → dryer

This may seem inane right now, but this is crucially important to bear in mind when we look at systems of work that are larger in leverage and scope than doing the laundry.

Ignoring the capacity of individual team members is a pretty reliable way to overwhelm them and degrade a system of work!

Feedback loops

Whenever something ‘downstream’ changes how things work ‘upstream’, that’s a feedback loop. It’s a loop in that information is now travelling in the opposite direction to the ‘work’, and because of this, the next iteration of the work changes in some way.

We have reinforcing feedback loops, where every iteration increases or magnifies the subsequent iteration. They’re exponential. Compound interest is a common example.

And we have balancing feedback loops, where the system will iterate towards stability. A thermostat will stop heating when its thermometer reaches a certain high reading. It’ll start heating again when it reaches a certain low reading (which could be one degree lower than the high value). The system balances itself.

What examples do we have when doing the laundry? For the most part, these are all balancing feedback loops, in that we sometimes push away from the norm and then stabilise at a new norm.

Can you think of an example of a reinforcing feedback loop in the system of laundry?

We did the laundry but it isn’t clean

• Change inputs: use hotter water or colder water, or a different detergent, or more of it.

• Change processes: use a stain remover before washing.

The laundry doesn’t smell nice, even though it’s technically clean

• Change inputs: use fragrance pellets.

• Repair tools: clean and service the washing machine.

• Change processes: don’t let freshly washed clothing sit in a basket for too long; work in such a way as to shorten this wait time so that it can be dried as soon as it’s washed. (More on this in a bit.)

The laundry is clean, but we’re not working efficiently

We are using too much cleaning product at a time, or it’s taking longer than it needs to.

• Change inputs: use less, until quality degrades below standards (the smell test).

• Change processes: use shorter wash cycles, cold wash instead of warm. Hang things up instead of running a dryer.

We left the lint in the dryer and it has to work harder and harder to push the moisture out. Mould can form. In extreme cases, lint can come into contact with a heating element and start a fire!

• Repair tools: repair and clean the dryer.

• Change processes: be sure to take the lint out of the dryer after every load!

Value streams

The chain of these flows is what makes up the overall “value stream”:

Value streams are typically thought of as linear (at least in terms of how we measure throughput), but they can also diverge and converge, skip steps, and of course, they can loop around.

• Some items use different tactics e.g. use the dryer machine for clothing and linens that won’t shrink, use the hanging line for everything else.

• Some items use completely different processes entirely, e.g. suits are dry-cleaned, and rugs are steam-cleaned.

• Some items skip steps, e.g. we don’t iron socks or woolly jumpers.

• Some items skip almost all the steps e.g. a clean item in the room’s basket going straight back into the cupboard.

And of course, it loops. We clean something, then we use it, and then it’s dirty again. And then we clean it again.

(At least, until ‘3D printing fresh clothes at home that we only wear once’ becomes cheaper and more sustainable than the current system of buying and washing it repeatedly).

Capacity and demand

There’s capacity: how much laundry we can clean at any given time (we can also call this ‘supply’), and demand: how much laundry we currently have to clean.

Each stock has a capacity, and these capacities are different to each other. For instance, the washer can only take so many items at a time, but we can make a much bigger pile than that on the floor!

The laundry system as a whole also has an overall capacity, which is the aggregate of all the stocks in the system. Everything piled up, plus what we’re washing, plus what we’re drying, plus what we’re folding, plus anything at rest that isn’t in the cupboard.

Value demand is the laundry we successfully cleaned and packed away.

In our feedback loop examples above, we saw that sometimes we had to rewash things. The fact that we have to wash it again causes new demand; this form of demand is called ‘failure demand’, in that it’s avoidable demand if we can prevent the associated ‘failure’.

Together, value demand and failure demand make up the total demand on the system.

Relationship between capacity and demand

There are layers. There’s what’s happening at the moment, and there’s the patterns of what happens over time.

The system oscillates between these states continuously:

• Underwhelmed: too little demand. Only a small amount of laundry; batches are not big enough to be processed. Not something anyone will complain about!

• Overwhelmed: too much demand. Lots of batches at once i.e. a big ole laundry pile-up. I believe the song goes “never-ending-lau-ndryyyyyyyy”?

• The Goldilocks zone: balanced demand/capacity. (Is ‘whelmed’ a word?)

If all the laundry is fully clean and packed away, and no one is making anything dirty, the system is empty and idle. We all yearn for this state, but somehow, never attain it 😅

Pattern: Less capacity than demand

If we spend every (reasonable) minute doing the laundry, and somehow still always have a big pile of dirty laundry to do, then we have less capacity than we need. There could be so many reasons why.

• Not enough time to do the labour (which is also a way of saying, not enough hands to help)

• Machines are too small

• Not enough drying space

Sometimes, these causes are temporary and can simply be weathered; e.g. when actual weather limits drying capacity, we can just wait it out, or we can use a laundromat service.

Other times, we need to intervene systemically or the system will implode (or a person will explode!) Get bigger machines. Make the kids help. Reduce demand by making people wear things more than once (not underwear!)

Pattern: More capacity than demand

Bigger or more is not always better.

It's possible to have too much capacity (or, put another way, not enough demand), and create a situation of inefficiency.

For example, a machine that’s too big for the average load will waste detergent, water and electricity. Otherwise, if we wait until we do have enough to wash, it will cause us to wait too long; ‘slow cycle time’. It becomes an unsatisfying trade-off.

We can end up here when the kids (finally!) leave the house.

Get smaller machines, or sell them, and switch to outsourcing to a service or to a laundromat.

Bottlenecks and constraints

There are bottlenecks all over the place, all the time. Waiting for someone to unload the washer, with more dirty laundry to load: bottleneck. Dry laundry waiting to be taken down, with wet laundry to hang up: bottleneck.

Governing constraint

Somewhere in this system, there’ll be a bottleneck that’s deciding the overall throughput (speed) of the system. This is the ‘governing constraint’ of the system. It can and does move around!

When all we have is dirty laundry, the washer (and the availability of the person loading it) is the governing constraint.

When all we have is wet, washed laundry, the governing constraint moves to ‘having enough drying space’.

This is what the Theory of Constraints by Eli Goldratt is all about. If we want the overall system to go faster, we need to figure out where the governing constraint is and do things to help improve it directly, rather than work on other places in the system which are not part of the governing constraint.

When we’ve plenty of drying space, then washing dirty laundry is exactly the right thing to do to make things better.

But, when we’re out of drying space (the dryer is running and the lines are all full), washing more dirty laundry is going to make things worse, not better, despite it being a productive activity.

This is pretty obvious to anyone who’s had piles of washed laundry start to smell because it stood for too long — in this case, it was easy to receive feedback that our timing was off.

In knowledge work, though, this is far less obvious. The ‘smell’ is nuanced. Higher levels of WIP. Longer queues of next-up tasks. More prioritisation activity, escalations, and “asap” rush jobs. More heroics (‘cancel all my meetings’, overtime) to get things done.

The Theory of Constraints helps us to have the whole system work at a speed that’s appropriate for the constrained step, so as not to let these queues form. We’ll dig into this more in a future article!

Limiting constraints

These are the decisions or situations deciding the capacity of the system.

We have one washer and one dryer. We have so much hanging space. We have so many people who can move laundry between them.

The point is, these decisions constrain the throughput of the system.

The governing constraint is the limiting constraint deciding the overall throughput of the system right now.

Enabling constraints

Not all constraints are ‘bad’! Sometimes we impose constraints of our own to make the work better, for a given definition of ‘better’. These are known as ‘enabling constraints’.

We might use them to manage for efficiency: we don’t run a washing machine with less than (say) 50% of a load, so as to get a minimum amount of value from the consumption of those resources. We accept that sometimes it’ll take longer for a given item to be cleaned, so that we can apply this batching rule that enables overall efficiency.

Without this constraint, we might end up running the washer with a 20% load frequently, and that’d be wasteful.

—

It’s important to recognise that most of these terms are about the relationship between capacity and demand. If there’s no demand, there are no bottlenecks or limiting constraints in effect at the moment.

Systems of systems

This ‘stocks and flows’ model is recursive. From the ‘outside’, a stock is a stock. From the ‘inside’, a given stock can be another system, with yet more individual stocks and flows within it.

As someone who pays for a laundry service, in your mind, the service is a stock with an inflow and an outflow - you provide dirty laundry (and payment) and get back clean laundry. For the people who run that service, though, they have many stocks and flows to deal with.

Similarly, your laundry system is situated in a bigger ‘household’ system.

Wearing clothes and using linens, hand-me-downs from older to younger siblings (or parents to kids!), these are all non-laundry stocks and flows that interleave with the laundry system in some way.

There’s also the total stock of these items in the household, which decides the possible demand for the laundry system. This can change when buying new items, donating clothes to charity, receiving and giving gifts, and so on.

(Again, seems inane, but important when we apply this model to our work!)

Let’s look at some examples of the outer situation deciding how the inner system will work.

A single person or a couple with minimal needs

A single person or a couple without children can use outsourced equipment (a laundromat), and so will decide when and what to wash differently from those who have their own equipment. It may even decide what textiles they buy.

A family with a baby

A young family with a baby will have higher demand (lots more stuff to wash) and lower capacity (tired parents!).

A large family

Families with lots of kids will have higher demand and could have more capacity if the kids are taught to help!

A family with big, hairy, smelly dogs

This family is going to have a lot of really dirty stuff to deal with. They may need heavy-duty detergents or machines to manage it all.

A professional laundry service

A professional do-it-all-for-you laundry service will have much stricter processes, far more optimised equipment and materials, far higher quality training, greater capacity, etc. Same stocks and flows, but substantially different elements and scales at each one.

They have to because, for them, profit is capped by maximum utilisation with the least possible waste and failure.

They want their machines and people working every minute because that’s the only way to achieve the greatest possible value as a business.

(Of course, there’s also the bigger picture reframing in which we always want to have some capacity available so as not to annoy and drive away repeat customers, but that’s a topic for another time.)

Recap

So there we have it. We explored these terms today, using laundry as an example:

• Stocks

• Flows - inflows, outflows

• Feedback loops - upstream, downstream, balancing loops and reinforcing loops

• Value streams

• Capacity (supply) and demand - value demand and failure demand

• Bottlenecks, governing constraints, limiting constraints, enabling constraints

• Systems of systems

What did you learn? What connections did you make?

What questions do you have?

Perhaps next time you’re doing the laundry, you can impress your partner (or your cat) with how clearly you can now see and understand the laundry system of work. And, maybe, now you have good, logical, systemic reasons to ignore that pileup for a couple hours? 😁

See if you can use these concepts to see your current systems of work in new and illuminating ways, and then let me know what you discover!

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• Mastodon — https://mas.to/@rost

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/

Why care about this at all?

Many of the teamwork and system changes we’ve made within Cognician’s Platform team over the last 5 years were directly aimed at reducing our cognitive load.

From moving specific work streams to different teams, to the playbook we follow when dealing with ad-hoc requests, we’ve found and ‘gardened out’ a ton of extraneous effort from our systems, both social and technical.

We’ve also done several big projects that took months to complete, to streamline our effort for years to come: one of the biggest was to switch to a mono repo for our source code. (If this is something you’d like to hear more about, let me know!)

This has allowed us to operate a living system with very little (comparative) effort, to make meaningful investments into that system’s growth, and to have space and time to make other, newer ‘development bets’ as a team. All while keeping the lights on and meeting our business’s daily needs.

We’ve done all this while also making it possible for everyone on the team to enjoy their non-working hours with mental clarity and peace, knowing that the work side of things is set up for success. No late nights or weekends at work are needed.

And, we’ve plenty of time and space to coach and mentor our junior team members, whether they’re new to the role, or just new to our team.

High-leverage effort, calm and well-rested people, and plenty of room for growth and change. Three BIG wins from pursuing a single powerful line of inquiry: mapping cognitive load, and making investments to reduce and streamline it for the whole team.

Of course, that’s not to say that we have ‘fixed everything’…. there are always some things that could be simpler or easier to deal with. It is a living system, after all. It’s part of the dance! 😄

Today I’ll share a short a primer of this model of cognitive load, and then look at some options for finding and reshaping your system of work to optimise load for your team.

Contents

• A primer on cognitive load

• Caveats

• Strategies

  • Part 1. Mapping cognitive load - 3 strategies

  • Part 2. Make investments to reduce load - 5 strategies

—

A primer on cognitive load

I learned this model through the excellent Team Topologies book.

Your ‘cognitive load’ is finite, and, for a given focus of attention, can be categorised in three ways:

1: Intrinsic Cognitive Load

The mental ‘software’ of your chosen activity:

• How to think through the work

• How to code / draw / write / your-verb-here

• How to use the tools

• Environmental context, such as links and passwords

2: Extraneous Cognitive Load

All the stuff you wish you didn’t have to deal with:

• Slow builds

• Broken tools

• Over-complicated systems

• Rabbit-hole discussions

• Success theatre

• Pointless meetings

We all have our 'favourites' :-) Here are Cory House’s:

Twitter tweet

I couldn’t agree more, Cory!

3: Germane Cognitive Load

This is the subject matter you’re applying your mind and energy to.

• The new skill or information you're learning

• The program or prose you’re writing

• The art you’re creating

• The systemic challenge you’re unravelling

This is the good stuff. The stuff we want to live and breathe.

—

Optimally, you want as little of the Intrinsic load as necessary to function, and you want no Extraneous load at all.

Why?

So that you have maximised space for the work itself: the Germane subject matter.

Reducing or removing the Extraneous in particular, is important in two directions:

1. Greater budget for Intrinsic skills.

   High-skill specialists tend to work in a focused manner (in that other people handle the more mundane or administrative aspects of the work) because they need the cognitive bandwidth!

2. Greater budget for Germane context.

   Put another way, the bigger the problems you can solve.

Removing Extraneous cognitive load:

• Feels great

• Promotes flow states

• Gets the best out of everyone’s contributions

It should be a major goal for Complexity wranglers and Tool-builders alike.

I summarise this model of cognitive load as:

1. Intrinsic: skills and facts

2. Extraneous: noise and waste

3. Germane: needs and value (and more facts)

Caveats about dealing with systemic cognitive load

Before we dive into the 8 strategies, it’s important to position them in the broader context.

Diminishing returns

There is a finite amount of load that we can reduce. At some point, effort in this direction will produce little value.

Thankfully, though, most teams who haven’t looked at their work through this lens, typically have plenty of straightforward interventions they can benefit from.

It is incredibly unlikely that digital knowledge-work teams avoid all of these issues by happenstance!

Right time and place

Sometimes, circumstances may require that we leave things as they are, and put all of our effort into the primary, core work activity, to make forward progress during a momentous time for the team or business. This is one of those ‘disagree and commit’ situations — knuckle down, power through it, push through to the win condition.

Once the dust settles, though, don’t forget to come back to it. A perfect time to return to this idea is during the retrospective of that big push!

It’s also work

Systemic change is also work.

It creates a temporary load of its own, as we reason through things together and make deliberate changes, and as the full team learns to live with these changes, and take advantage of the ‘new normal’ we’ve created.

It’s a 2 steps back, 10 steps forward sort of thing. Be ready for this. Take it into account when making plans.

Strategies for dealing with cognitive load

To reduce intrinsic load is to reduce the number of things I need to be able to do or to remember, as I do my work, or as I interpret the work of a teammate.

To reduce extraneous load is to remove unnecessary or redundant effort from the work and from the environment.

We follow a basic two part process, in a continuous loop:

Part 1 — Mapping the load - 3 strategies

Before choosing one or more of these interventions to apply, get clear on where your team’s load is.

Part 2 — Experiments and investments to improve load - 5 strategies

Once you have enough clarity to know where your biggest issues are, then you can get to work making things better.

Part 1: Map out your team’s cognitive load

There are three high-leverage approaches to take here, which all build on each other:

1. Start a learning board

2. Talk to people

3. Reflect on the work as it happens

I recommend trying them all. You want to see the shared system from more than one angle, and you want to control for faulty human memory.

Also, like many things in the world of work, it’s continuous and cyclical. You keep doing them all!

—

1. Start a learning board

Gathering

Use the findings from the next two tactics to make a list of options for improvement within the team’s tools and processes.

Rank these observations by ‘pain level’ (frequency, subscription - % of team, severity).

Experimentation

As you and your team start to make investments as detailed in the next section, contrive experiments to run that could teach you more about the issues, and what might make them less bad, or go away entirely.

All the strategies below are options, but you’ll likely have more of your own. Either way, be sure to be clear on these questions:

• Do they reduce intrinsic cognitive load? How so?

• Do they reduce or remove extraneous load? How so?

• What do we intend to learn from this experiment?

• How long will we run it for?

Rank these experiments by effort, and by how much pain they’d reduce or remove.

Run the experiments that are in the value + effort sweet spot.

Key things to remember about running experiments:

• We delay judgment while the experiment is running.

• We’re not trying to fix something so much as we’re seeking to learn what would cause the thing to be fixed. It’s subtle, but vitally important to bear in mind.

• The only way to fail is to learn nothing from it!

As you learn from your experiments, you can make decisions about how the work works, and use what you learn to construct and run more experiments.

Advantages to running a learning board

• We can limit how much extra cognitive load your experiments create by limiting the number of experiments at any given time. Ideally, you start with just one, and add more over time as comfort and bandwidth increase

• It’s a centralised source of truth for the current how-the-work-works situation for your team

• It’s an excellent source of information for onboarding new joiners.

I first learned this idea from Claudio Perrone, through his talk on PopcornFlow (first 30 mins or so — slides here).

I got the name “learning board” from John Cutler, who put this 3-minute explainer video together.

John writes of the fantastic Beautiful Mess newsletter, which I heartily recommend!

—

2. Talk to people

Have 1:1s and team discussions. Talk to folks from other teams that your team interacts with regularly. Look at your system of work from lots of different perspectives.

Ask lots of questions. Share the screen and demonstrate how things are broken or slow. Work to see the system through your people’s eyes as clearly as possible.

Include questions on cognitive load in your sprint or project retrospective template.

In this mode, you’re looking for issues with high frequency (happens daily or multiple times a day), and high subscription (percentage of people on the team).

Those items that have both properties — high frequency and high subscription — are BIG levers for relieving substantial and immediate pressure in the system.

Encourage folks to volunteer these observations early and often.

Questions you could ask:

• What’s annoying or frustrating you right now?

• What do you wish could be simpler, faster, or take fewer steps?

• How do you get stuck, and how do you deal with it when it happens?

• Wave a magic wand. What’s no longer in the way?

• When contemplating a decision: how will this increase/decrease which kind of cognitive load?

—

3. Reflect on the work as it happens

After every task, do a mini ‘After Action Review’.

For ad-hoc requests, ask: why did we have to do this? What would make it unnecessary for this to be delegated to us, or for any human to have to deal with this again?

For the items that are necessary for the team (i.e. our usual work), look for ways to reduce that effort. Find ways to move it away from complex and towards simple. After finishing a task, write down the things that caused friction, either for individuals, or between individuals.

Then, at an appropriate level of effort, go and fix those things (using the strategies below, or your own), so that the next time this issue or request would have occurred, the correct response or intervention is already in place to deal with it.

To give you a sense of where this kind of reflection can lead, here’s the list of interventions we routinely applied as we responded to ad-hoc work of various kinds:

• Write documentation: FAQs, explanations, reference material, how-to guides, so we don’t have to write all this out when people ask questions

• Fix one or more bugs, so we stop having to support folks past them

• Silence annoyance-level error messages, so folks stop getting distracted by them or reporting them

• Migrate some data, so folks stop getting confused

• Build one or more features, so we stop having to do things manually

• Remove redundant features, documentation or data, so we stop having to direct people away from them

To me, this is the spirit of continuous improvement.

Part 2: Make investments to reduce load

Just as with mapping, intervening is also continuous and cyclical. All these strategies build on each other.

Where you begin, and what order you work in, will be based on your particular situation. (Therefore, this order I present them in here is arbitrary.)

1. Fix the tools

2. Directly attack entropy

3. Train the tools, train the practices

4. Write and maintain a knowledge-base

5. Set up a ‘stupid questions’ channel

This list is not exhaustive, however, if you’re doing all of them sufficiently well, it’ll be a lot easier to see whatever else there is that needs your attention 😅

—

Fix the tools

Look at the most frequent activities of the team and find slow or broken things that are used often (daily is a good threshold to begin intervening), and speed them up, or fix them.

These are all examples of load reducers for software development:

• Working test suites

• Static analysis tools with editor support

• CI processes - this directly correlates with one of the four DORA Metrics (Deployment Frequency). Running from start to finish in less than 15 minutes is the sweet spot. Any improvements after that are just fantastic ‘quality of life’!

• Scripts to run everything on a dev machine

• Scripts to run anything to do with cloud environments

• Automate routine things so that humans don’t have to remember to do them

Each team will have its systems with similar needs and opportunities for simplification and repair. Find yours, and fix them.

Also, be sure to set up a process to keep them all updated and in good working order.

—

Directly attack entropy

A good ‘digital hygiene’ discipline is fundamental to counteract entropy. We must clean up after ourselves, early and often.

This is a wonderful lesson from the culinary world: Mise en place. A working kitchen would fall apart completely if they weren’t relentless and deliberate about keeping their environment optimised for a few people to prepare food for many people — quickly, hygienically, and with high quality.

We can benefit from the same thinking for our work!

Deleting unused stuff — from small stuff like unused files, documents, etc, to not-so-small things like entire unused features or systems.

Correcting obvious mistakes as we encounter them:

• Spelling mistakes

• lint errors / warnings

• Annoyance-level bugs that are easy to fix if we would just focus on them for a short time

Removing inconsistency when we find it.

Unifying needlessly duplicated or fractured things - for us, moving to a mono repo was a HUGE reduction in so many things at once.

Removing unnecessary meetings. Shutting down unnecessary traditions (e.g. producing reports each week for people who never read them).

Bonus points for automating good hygiene e.g. breaking the build when the linter has warnings.

Some of these can sometimes mean substantial refactoring work, in that they need to be planned out and focused on.

Also, we have a saying in programming: ‘Deleted code is debugged code — Jeff Sickel’.

This means that you can remove work and waste from the system by deleting things so that we don’t spend any time talking about or fixing anything inside them.

—

Train the tools, train the practices

People also need to use these tools correctly. There’s a discipline element to it — everyone needs to contribute. Fixing tests. Refactoring for consistency. Reporting bugs correctly. Deleting unused stuff. It all helps, it all makes a difference.

• Pair with people to see what shortcuts or tool knowledge they’re lacking. Write shortcut notes together and have them practice.

• Write how-tos together, for next time (see the next point).

If you do it long enough, eventually you will help people to learn how to do this for themselves automatically whenever learning a new tool. They’ll become self-sufficient learners.

Build all of this into your mentorships.

Of course, directly invest in your people with books and courses and the like, too!

—

Write and maintain a knowledge-base

Ideally, this would all be in a single system for your team, but it may be spread out over several systems (especially if your business is not small any more).

Either way, you want any particular piece of knowledge to be one of these types:

• FAQs — this is best kept in a tool with excellent metadata and search capability. We use StackOverflow for Teams, and it has over 1000 questions in it!

  • Another bonus: Over time, we spend less time waiting for humans to provide answers, AND we switch context less often.

• Explanation — Narrative prose that spells out whatever the thing is. Could be a single document or a whole Notion database full of linked wiki pages.

• Reference — Any enumerations of facts. From spreadsheets to API references and everything in between.

• How-tos — system-specific playbooks that focus only on how to take a specific set of steps to get a specific outcome. This might be used by different teams to those who maintain the systems, so they might be kept in different a knowledge-base to the other categories.

We separate these types out from each other to simplify and focus each piece; for example, we don’t try to provide ‘how to’ guidance in the middle of a reference document, or list FAQs inside an explainer.

Instead, we cross-link between these different types to provide that context. This allows us to reduce repetition in our documentation, which eases corrective and maintenance work.

We create coherence and context for the reader by cross-linking between these pieces, and by using consistent language across all the different types.

For that reason, you’ll probably want to maintain a Glossary, too 😊

The last three items here come from the excellent Diataxis framework for writing technical documentation. I believe they are suited to any knowledge work context.

—

Set up a ‘stupid questions’ channel

I believe that the only stupid question is the one you didn’t ask (at least, within a well-intentioned, purpose-aligned team of people).

Set up a channel in your team chat space that’s specifically for folks to ask their ‘stupid’ questions. Make a point of modelling this behaviour yourself. Imposter syndrome is real; people need to see that it’s not only safe to do so, but that it’s normal and expected to do so.

Model ignorance and vulnerability, demonstrate to the team that it’s OK not to ‘know’. This directly invests in growing and strengthening your team’s psychological safety.

Of course, the point here is that many seemingly stupid questions are actually some of the best questions we could ask, because they reveal the gaps in our perceptions and understanding, and our various products, be they internal or customer-facing.

Lean into learning together, on purpose. Take full advantage of all the “beginner’s mind” you can find in your business. Juniors and new joiners should be encouraged to participate, and recognised and celebrated when they do.

To reduce effort over time, be sure to harvest and codify FAQs from this channel!

For more on psychological safety, I heartily recommend Tom Geraghty’s Psychological Safety newsletter.

Over to you

Using cognitive load as a framework for assessing the ‘personal cost’ side of systems is hugely beneficial. Using its guidance to improve the system can provide great predictive power and reduce effort substantially. You can get a lot more value for a lot less effort.

With the load optimised, growing the team is also optimised, because no one has to take on any unnecessary load, nor does anyone need to spend time training people on those redundant things.

I’ve given you a couple of starting points. A low-effort first step you could take: share this with your team, have them read through it, and then have a ‘so what do we want to do with this?’ discussion as a team.

I can help

If this is something you’d like help with, I offer a modest number of consulting hours per month. We can look at your system of work together, and reason through where the highest leverage places are for you to intervene next.

If this is something you’re interested in, please reach out via any of the links below!

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• Mastodon — https://mas.to/@rost

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/

There are two shorter pieces in today’s newsletter.

Both are about the idea that we should deliberately be setting boundaries to protect our time and energy. One deals with your attention, and one deals with decision-making.

They’re both excellent conversation starters during a 1:1 with your team mate, or a team retro.

#1: A simple technique to protect your energy and attention

Time management — scheduling your calendar, timeboxing, etc — is useful, even if just as a way to set boundaries with your team, but I believe the true skill is actually attention management.

Attention is the primary resource we spend, as individuals in knowledge-work.

Previously, I wrote about situational awareness as a skill. One of its advantages is it compresses the 'seeing and connecting' effort in time, thereby increasing the results you enjoy from paying — spending — that attention, or, measured from the other side, reducing the amount of attention you needed to spend to get those results.

Another way to ensure your attention is spent wisely, is to control all the ways in which other people can spend it for you.

So.

Here's that technique:

Stop letting other people decide when you pay attention to things.

In today's world of remote work with digital tools, that boils down to making this one basic change:

Push notifications: Disable them.

On your computer, on your phone, on your tablet, on your smartwatch. All of them. Yes, even that one. Yes, really!

But Robert, you cry, how will I know when I am needed? What if I miss out? #fomo

You're right! You can't just disappear. You still need to show up. You still need to be subscribed.

The remedy is simple, it's just not as effortless as passively waiting to be distracted all day long:

Schedule time to process your inboxes, and stick to that schedule.

These are all inboxes:

• Chat/IM — Slack, MS Teams chat, etc.

• Tasks — Asana, Notion, Monday, etc.

• Role-specific — Engineers: exception tracker, infrastructure alerts. Customer success: user support requests. Etc.

• And of course, good old email.

Depending on your role and responsibilities, some will need checking often. That's fine. Develop the habit of checking them often — but be sure to close them again when you switch back to your next Deep Work session.

Another energy management trick is to save the 'shallow work' — inbox processing, responding to stuff, gardening your digital work areas — for when you've already spent your primary creative energy for the day, and don't have much left in the tank anyway.

Multitasking is a myth

We can focus on one thing at a time, and we can switch that focus quickly, with practice.

Even with practice though, rapid context-switching — which is the real name for the activity we call multitasking — is costly in terms of energy, and in terms of time.

It takes real 'activation energy' to load context in (to read, to understand, to situate yourself, to form opinions and plans about how to act), but it also takes energy to hold just enough of what you were doing before in your head so that you can return to it in a moment; to switch back.

Is the trade-off of a quick reaction worth the loss of productive effort on your planned work?

With better planning, you can spend less energy to produce more value. Enjoy a flow state more often.

Accomplish your Important goals, rather than only reacting to urgent requests.

Why not commit to a two-week experiment, and see how much better your results are, and how much calmer you feel?

So, to recap:

• Disable push notifications.

• Process your inboxes on a schedule.

• Focus on your deep work, knowing you can't be distracted from it.

Bonus tip

Also, stop getting automated email notifications for stuff happening in other systems that have their own inboxes, e.g. Notion or Asana. Why process those things twice?

#2: Saying 'no' is one of the most important skills you can learn.

Here's 4 reasons why, and 3 ways to do it. (And, why it'll earn you trust.)

We want to please the people we serve. We want to make them happy.

But if we say yes to everything that's requested of us, we can very easily become overwhelmed, despite having the very best of intentions. And then we are helpful to no one.

Sometimes, we need to say no.

4 reasons to say 'no'

1. Often, as experts, only we can see that what they’re asking for won’t actually meets their needs.

2. Or, the cost to us (or to us and to them) is too great.

3. Or, we may simply not be capable of following through on a schedule that helps them.

4. Once we commit, we need to be sure that we’re prepared back it up. We may not be able to do that.

3 ways to say 'no'

So, from time to time, we need to say no, one way or another:

• No can mean ‘not yet’ (a deferral). This is what we mean by “no is temporary, yes is permanent”.

• No can mean ‘not what you’ve asked, but here’s another way to meet your needs’ (a negotiated alternative).

• No can also simply mean ‘not at all, in any shape or form’. The request may simply just be inappropriate, or directed at the wrong people.

Saying 'no' builds trust

In a healthy system-of-work, all three are necessary from time to time.

Saying no immediately is the most energy-efficient way to deal with something that you shouldn’t be doing. Saying yes and then backing out later is much harder and costlier in terms of social capital, stress, trust erosion, and so on. Loss aversion is very, very real. You’re doing everyone a favour by preventing it when it’s necessary.

If you never say no, then the only logical outcome is that you’ll be micro-managed by someone more senior than you. It’s just a matter of time.

If you’re the most senior person, you could exhaust your resources without meeting your goals! It’s even more vital.

Learn (when and how) to say no!

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• Mastodon — https://mas.to/@rost

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/

Over past 13 years as a (still first time) CTO, I’ve come across two models that have proven to be helpful time and again when navigating tough decisions and disagreements.

They’re also great 1:1 coaching tools, especially when signs of apathy, contempt or overwhelm are starting to show.

Disagreement

At the heart of it, a disagreement can be people ‘talking past each other’. We have a different view on the shared reality.

There are so many ways this can happen! Whether a feature should be built, or removed. Deciding which tool to use. It could be more fundamental — recognising that our current strategy isn’t working, and needing to make a courageous change in the team or the business.

Sometimes, it manifests as a personality clash.

Agreement

We need a way to frame it in a way that enables us to generate options for moving forward.

Building agreement is about feeling genuinely heard, uncovering assumptions, correcting misunderstandings, and finding connections between these views.

So that the ‘disagreement space’ can become smaller and easier to reason about.

See clearly

By using these models, there’s a high chance that find a way to agree, and map a solid way forward that everyone buys into.

Now, we might still conclude that we fundamentally disagree, but now it’ll be clear about what, and why. And, we’ll have also be clear about which details we do not disagree on — a shared vision of the world. This is helpful when keeping our eyes open for new information or opportunities to handle the disagreement in future (because sometimes, these things take time to work out).

Let’s check them out.

Model 1: the Spine Model

The model

Needs → Values → Principles → Practices → Tools

Key takeaways

• Needs are our ground truth. Start with clearly stating and empathising with each other’s needs.

• Work down the spine through Values/Principles (a 2-layer ‘things we care about’ lens) down to Practices (’things we actually do’) and Tools (’mechanisms we use to do those things).

• Ensure that everyone recognises these conclusions. Use them to generate questions and options for moving forward.

• If we disagree ‘upstream’, we’re not going to agree ‘downstream’. You’ll save time and energy avoiding frustrating, fruitless discussion.

More reading

Spine Model website

Credit goes to Kevin Trethewey and Danie Roux.

Model 2: Layers of resistance

The model

1. We Do Not Agree on the Problem

2. We Do Not Agree on the Direction of the Solution

3. We Do Not Agree That the Proposed Solution Resolves the Problem

4. Yes But... the Proposed Solution Will Create Other Problems

5. Yes But... there Are Huge Obstacles to Implementing the Proposed Solution

6. Unverbalised Fear

Key takeaways

• See if you can find one or more of these layers in the points people are making.

• Reflect this back to them - “it seems you are saying ___, is that right?”

• If we reach unverbalised fear, that’s also useful; we can recognise that perhaps folks are simply overwhelmed and can’t reason clearly at the moment. This could signal a need to delegate, or defer, or work on solving some other more fundamental issue first.

• Like the Spine, ensure that everyone recognises these conclusions. Use them to generate questions and options for moving forward.

• Like the Spine, if we disagree upstream, it’s unlikely we’ll agree downstream. You’ll save time and energy.

More reading

The Layers of Resistance - The Buy-In Process According to TOC, by Efrat Goldratt-Ashlag (Eli’s daughter!)

Credit goes to Eliyahu Goldratt, author of The Goal and Theory of Constraints.

Now you try it out

Use these two tools to disagree constructively and find a way forward for your team.

Save time and energy avoiding useless discussion.

Focus the effort on the right layer in either model (i.e. where there's actually disagreement), and use the appropriate language to have that debate.

There’s other bonuses: Emotions calm. Empathy and trust builds. You get to learn a ton about each other, and the problem space you occupy together.

And, if you disagree with me, now you have two great ways to say how 😎

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• Mastodon — https://mas.to/@rost

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/

The term "situational awareness" comes to us from the military world.

It's defined as 'understanding an environment, the elements within it, and how both are changing in space and time'.

You may have heard of the 'OODA loop', developed by USA Air Force Colonel John Boyd. OODA stands for Observe, Orient, Decide, and Act. It was developed to train fighter pilots to be more agile than their opponent.

Situational Awareness is the outcome we get when we run the first half of this loop; Observing and Orienting.

Ok — so you're probably not a fighter pilot. How is this relevant?

In today's fast-moving, ever-changing world of digital work, we encounter complex issues and opportunities all the time. Often, the stakes can be high, or the situation can be totally new to us.

Being able to orient yourself and the people around you — with speed and accuracy — is a crucial skill!

What does this skill unlock?

• Map out facts, opinions, assumptions, causes, and relationships and quickly.

• Socialise your perceptions and understanding with anyone, which enables delegation and collaboration.

• Stop wasting time playing 'broken telephone'.

• Make better decisions!

Over time, the benefits build up

• Cognitive load reduces, even as your capacity increases.

• Learn from each and every encounter. Grow as individuals, and as a team.

• Less fear, uncertainty and doubt for your team and your ecosystem.

• Build trust and autonomy for you and your team — become the experts!

It's a fast-track to expertise in the 'responding to things' part of the work, which, let's face it, is a large proportion of the work!

Intentionally building skills and habits in this area levels you up in all the work you do.

Complexity is unavoidable

Every day, the digital world of knowledge work moves faster and becomes more complex.

Constraints change. We encounter new opportunities. We lose or gain resources — whether it’s time, access to people, tools, or you-name-it.

The most recent tsunami: ChatGPT.

We have to adjust, adjust, adjust as the world happens to us, all while we are trying to happen to it in some meaningful, productive way.

To be nimble as a team in this world, we need an intentional practice for establishing situational awareness.

After all, it doesn’t matter how efficient you are, if you’re efficiently doing the wrong thing. To know what the right thing to do is, you need to track your reality clearly.

In complex knowledge work, we need to accumulate information (Observe) and we need to form a coherent understanding (Orient). And, as we Decide and Act, we need to reference both of these parts continuously, and, update them as we go, as we create change and receive feedback.

Generic principle

If you’re feeling like I’m saying things here that are patently obvious, there’s a good reason for that!

Each of us already has some degree of practice with SA, even if we've never heard the term before. For most of us, it's implicit and hidden in the work.

We each learn to do just enough of this for ourselves to be competent in our roles. From simple sticky notes on our desk, all the way up to fine-tuned personal wiki databases, we have our own way of 'keeping track of our world', of being aware.

Similarly, many of our 'normal work' processes are designed to produce SA in some formal way. Work systems like Kanban and Scrum include rules and processes for producing and maintaining SA for their particular categories of effort. Team retrospectives and incident reports are a technique for looking back at the recent past to add additional kinds of SA that weren't available as events unfolded.

As good and as necessary as both of these are, they have disadvantages. They are either unconscious or intuitive (and therefore inconsistent) or too formalised and specific (and therefore applicable only to parts of the work).

There's a generic pattern, a principle, that we can lift out and apply to just about anything, and derive immediate and long-lasting benefit.

Situational awareness is a mindset, a state of being. You can tell when you have it (because you're clear and ready to act) and you can tell when you don't (because you feel uncertainty and doubt... you have that 'fog of war' WTF?! feeling).

Scale

The other thing to recognise is that we deal with many situations in parallel. An intentional practice allows us to manage many situations at once with less strain. Good SA helps us load in context when context switching.

And, it's recursive. For example, a software bug report is a situation, but so is a collection of related bugs, and the current capacity and capability of the team dealing with those bugs, and the principles and practices that this team follows, and the strategic imperatives and goals that this team is obligated to accomplish.

These are all situations, operating at different levels of abstraction, all interrelated and interdependent on each other. And that big picture is itself a situation.

They all need someone to be aware of them, so that they can be managed, guided, nudged, or intervened with, as appropriate.

Having an intentional 'build and socialise a coherent understanding' practice allows us to work within and across these levels with greater clarity.

Expertise

To provide our team, business, or ecosystem with leadership to reduce pain and increase value with the time and energy we have.

To make sense of things today, as they are today.

With time and practice, it allows us to scale our attention, both horizontally (e.g. lots of bugs at once) and vertically (up and down the abstraction 'ladder' I describe above).

I've received feedback from lots of different people over the years, that I'm calm and dependable, and I'm someone you want to call when things are 'going pear-shaped'.

I truly believe that my situational awareness skill is the core superpower that people are actually reaching for, and interacting with me is just the shortcut to accessing it!

I also truly believe that anyone can learn this skill and become just as valuable.

The fundamental process

Ok. Sermon over!

What does it look like in practice?

At least one person on your team (congratulations, that's you!) needs to take the responsibility to take the right steps, and to repeatedly check whether you're on track with it.

Next, I’ll provide a generic set of steps that any digital team could follow. My only assumption is that you're working together via online tools — team chat, video calls, real-time collaboration documents (e.g. Google Docs, Notion, Miro).

Then, we’ll look at how this process applies to a couple different scenarios, to demonstrate the principles in action.

Setup

1. Make a dedicated workspace to contain the situation. Label it so that the goal is clear.

2. Share access to everyone who needs it. Grant them permission, and provide them with the link.

Both steps in setup are crucial.

The dedicated space with a clear label is important to avoid confusing the situation with anything that’s unrelated. Using a tool with a good search capability means you can handle lots of situations in parallel.

And, sharing access is important as we want to remove all friction for collaborators to do the right thing.

Without these, we end up with conversations and information spread out across multiple systems, channels, emails, and so on. It’s simply not possible for anyone to see what’s happening. Total fog of war.

This requires real discipline. For some situations, the decision to take this step and insist that people participate correctly can make all the difference, especially when the stakes are high, and 'fight or flight' mode is kicking in.

Process

1. Every question, answer, fact, observation, opinion, assumption relating to this situation goes into that workspace. Screenshots, links, pastes from emails… everything that’s relevant. This is the ‘situation’.

2. As information accrues, organise it to build a coherent understanding. With iteration, this produces the ‘awareness’.

3. Everyone uses this shared space as their source of truth. They do not work elsewhere.

Which questions you're asking, and how you're organising that information is, of course, situational (I'm not even sorry), and is a topic for another time.

How do we know we’re doing this correctly?

Early and often, we ask ourselves “Is the situation clear to everyone?”

Questions and responses should be squarely aimed at getting to “YES” for that question.

Recap

So, to recap, the skill of building situational awareness is to:

1. Recognise the need to establish clarity.

2. Create a shared space, and make everyone use it.

3. Accrue information and build coherence in that space.

4. Relentlessly pursue the "are we clear now?" question.

That's it. If you're doing that, you're doing it correctly. It doesn't matter what tools you use, or what capital-letter work management framework you're using.

"But Robert," you cry, "this is so basic and obvious?" I agree.

It's deceptively simple. Obvious, even. You may even actually say ‘duh, but I knew that!’ as you were reading this.

The thing is, knowing it isn’t enough. You actually have to do it, and, you have to be relentless with your focus as you do it.

Exercise and making good food choices are basic and obvious, too, but if you don't do them, you won't benefit.

What confusion is your team dealing with today, that you could practice this skill on?

Roll up your sleeves and get stuck in!

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/

During our work at Cognician, we’ve tried out and integrated (some or all) of a bunch of different practices, models, frameworks, and so on.

In this article, I’m sharing a map of more than 70 topics and concepts. Think of this article as both a guide for making improvements in your work life, and a roadmap for this newsletter for the next little while.

Where is all of this coming from?

To give you a bit of context, our Platform team builds, maintains and operates a B2B SaaS web platform, in the domain of andragogy — learning-for-adults.

The people who shape, design and write the software (Dev), also deal with its operations (Ops) — feature releases, migrations, user support, knowledge, exceptions and outages, routine maintenance, and more.

We’ve been at this for 13 years, now!

We consistently have more to do than we have time or energy for. We are continually uncovering new information, being presented with forks in the road, and with distractions away from the current mission.

We’re also growing and changing as people, as time passes. The current people change (new skills, new goals). New people join. Sometimes, people leave.

All of this makes for a very dynamic and challenging (in a good way) work life. We’ve had to problem-solve our way through all sorts of situations, dynamics, opportunities, and crises.

Does this sound familiar? My guess is that you can see yourself in this picture, even if you’re not in the structure of B2B SaaS software, or in the domain of learning-for-adults.

Not every practice sticks, of course. Whether or not we actively apply or practice a given idea or method today, one thing we generally hold on to, is its terminology. Having nuanced but accurate language really helps our team move through complex work together, and tackle complex behavioural changes together. Oftentimes, that’s all you need!

About you, fellow adventurer

These are the assumptions I am making about you:

• You work in a team with other people.

• You work in ‘knowledge work’.

• You stand to benefit substantially from at least one idea that I share today. Hopefully, many more than one!

Something I am not assuming about you: your experience level!

You could just be starting out, or you could be a decades-long veteran, or anywhere in between.

And, anyone can learn and apply everything in this map. It’s all learnable skills, rather than some sort of innate talent. I truly believe that everyone can do it!

Wait — just what is ‘knowledge work’, anyway?

I’m willing to bet you already do it, even if you’ve never heard the term before. It simply means working with information and information systems, typically supported by technology.

Anyone whose job primarily consists of reading, understanding, analysing, synthesizing, writing, drawing, planning, programming, configuring, calculating, or otherwise consuming, transforming, or producing information a.k.a. knowledge, that person is a knowledge worker.

Scientists. Architects. Writers. Product Managers. Marketers. Engineers. UX specialists. Community Managers. ChatGPT Prompt Engineers. The list is endless, and growing faster than ever.

If you’ve ever read or written a work email, you qualify. I know you can do much more than that, though!

Two important facts to remember:

1. It’s just a big game of make-believe; it’s all in our heads.

2. It’s a social game. We play it together with other people.

3. Ok, ok, three facts — technology is increasingly the primary substrate for this all activity.

We need to be able to share what’s in our heads with each other skillfully, and to be perceive and understand what’s in each others’ heads clearly.

And because technology is in the middle, learning to work with that technology wisely, to maximally benefit from its advantages, and to consciously counteract its flaws, shortcomings and biases — all of that is vital.

My aims

Learning or adopting something on from this list can be a force-multiplier for your energy and attention.

I hope for two things:

1. You learn something from me (and perhaps you want to know more).

2. You have something I can learn from you (and perhaps you want to share it).

In the best case, you can connect the dots between something I share here and something that’s challenging in your work or team at the moment, and it helps you make some meaningful forward progress with it.

Some disclaimers

I do not claim to be an expert on any of these topics; I know just enough to add some sort of value in our team and in our context. I am simply sharing what we’ve encountered on our adventures together ❤

I’m not trying to suggest that this list is comprehensive or complete. I fully expect to learn more useful concepts to apply and integrate. Please share yours!

And lastly, remember that all models are wrong, but some are useful! And YOU are the arbiter of what’s useful. Remember, this is all language for exploring complex and dynamic systems and interactions. Apply due scepticism and rigour, but also — keep an open mind! Ultimately, YOU make your own meaning.

That applies to this article, too!

—

Be sure to bookmark this article’s web page, as I will be expanding it as I learn more, and, as I write on individual topics, I’ll link to those articles from here. Eventually, this will become an information hub for the world of knowledge-work.

Ok. Enough preamble! Have you refilled your cup? Let’s dive in!

A Guide for the World of Knowledge Work

Overview

Broadly speaking, all this stuff seems to fit into five rough areas:

• What you know

  • …. about how people work, and how the ’world of work’ works.

  • … about your specific environment.

• What you do

  • … routinely.

  • … proactively.

  • … reactively.

That first ‘people and world-of-work’ topic is a big one, chock-full of context-agnostic (and therefore dryer) information, so we’ll index it last, after working through the other four topics, which are more rooted in our lived experience.

—

Things you know, part one

Be situated

To be a good contributor, team member, leader, supporter, and advocate, you need to be clear on all of these topics:

• Your team’s values, principles and agreements.

• Your team’s practices, processes, and rituals.

• Your team’s goals.

• Your team’s capacities.

• Your team’s capabilities.

• The needs of your team members - you, your colleagues, your manager, and their manager.

Remember, you’re in the team — you are in scope for all of the above!

This is a major part of your system of work.

—

Things you do

Your habits — things you routinely do

You just do these things without needing to be told, because you personally get value from doing them, and because you understand the value that you bring to your team and your organisation by doing them.

• Bond as human beings — laugh and tell stories together!

• Communicate clearly about your own needs.

• Sense your environment clearly.

• Signal to your environment clearly.

• Proactively manage expectations.

• Investing in the people around you.

• Advocate for the team, and for its people.

• Working against entropy.

• Mise en place.

• Recognise and deal with unsuitable patterns of behaviour.

• ‘Stay in your lane’ (respect boundaries), but support others in theirs.

• Safety first — diligently do your bit when it comes to your team’s compliance requirements.

—

Your skills — things you proactively do as you work

Aside from what your LinkedIn profile says you do (marketing, programming, copywriting, product management, whatever), you:

• SEE — Be able to rapidly build accurate situational awareness - for yourself, and everyone around you. Knowing how to:

  • Ask good questions

  • Search - find things quickly

  • Map - explore the unknown and build up a view for your team

• THINK, and DO

  • The most important thing you can do is make a decision. It provides leverage, because it reduces uncertainty in the work. Turn a set of options into a firm path forward for everyone to follow. This is what makes you the expert.

  • The bigger the decision, the more important it is to socialise the decision and how you made it. This matters just as much when it’s in the work itself, or about ‘how the work works’.

• SAY — We live in the information age; be able to produce and package information.

  • You can write.

  • You can ‘draw’.

  • You can speak.

—

When [stimulus], then [response]

These are a bit more specific and situational, and you might not relate to them directly. Whether you do or not, the pattern should be clear: know how to respond suitably in your context.

• When responding to demand in an inbox, if someone ‘did it wrong’, offer kind guidance towards the correct method. My pet peeve: not receiving links or screenshots when being asked to fix an issue 😁

• When a request is made of your team that you need to say no to, you know to do so, and you know how to handle the discussion.

• When answering a FAQ, guide folks to use your team’s FAQ knowledge system.

• When dealing with a crisis of some kind — such as a service outage in the production system you operate — fix it first, retrospect it after. Do keep good notes as you go, of course. Also, “never waste a crisis”.

—

Things you know, part two

Things you understand

• It’s about people, all the way down.

• It’s all creative work.

• Ignorance is the default state of being. Learning is the default mode of behaviour.

• It’s not what happens that matters; it’s what we do about it that matters.

• Every action is a vote for the ‘way we do things around here’.

• Context matters; it’s not so much ‘right or wrong’ or ‘good or bad’ as it is ‘suitable or unsuitable’.

• Balancing acts

  • Demand vs capacity.

  • Responsive vs focused.

  • Costs vs benefits.

  • ASAP vs Just in time.

—

Concepts, models, frameworks, methods, techniques

• About people

  • Cognitive behaviour

    • Biases e.g. survivor bias, loss aversion

    • Fallacies e.g. sunk cost

    • Imposter syndrome

    • Introversion, extroversion

    • Neurodivergence

    • Cognitive load

    • Emotional intelligence

    • Managing attention

  • Growth Mindset

  • Maslow’s theory of self-actualisation

  • Motivation, and the self-determination theory

  • Non-violent communication

  • Psychological safety

  • Authority, Power, Influence

  • Locus of control, sphere of influence, sphere of concern

  • Roles, rather than Identities

• About systems of work

  • Systems thinking - stocks, flows, feedback loops

  • Make the work visible

  • Queuing theory

  • Throughput accounting vs cost accounting

  • Theory of Constraints

  • Complex (alive) vs Complicated (dead)

  • Cynefin - model of complexity

  • Conway’s law

  • Team Topologies

  • Westrum’s typology of organisations

  • Double-loop learning

  • Requests, commitments, impediments, and WIP

  • Value demand, failure demand

  • Causes of waste

  • Causes of delay

  • Andon cord

  • Spine model

  • By goal vs by method

  • Adding knowledge workers also adds work

  • A bad system will beat a good person every time

  • Lead people and manage things

  • Doing the thing right vs doing the right thing

• About the work itself

  • Appetites vs estimation

  • Making vs Mending

  • Glue work

  • Understanding value

  • Quality can’t be inspected in later

  • Incoming QA

  • Outgoing QA

Phew. That’s a lot of stuff!

In my Notion document for this article, almost every one of these 70+ bullet points lead to a page with notes and sources, ready to be turned into an article.

My plan is to turn each and every one of these topics into something you can use to immediately improve work life — for you, and for the human beings around you.

Thank you for reading, and mega-ultra-double thank you for writing back.

I wish you a great week!

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• Mastodon — https://mas.to/@rost

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/

Here’s a totally made up hypothetical situation…

Xavi, a Customer Success Champion, wants, like, anyone from Engineering or whatever to fix an urgent bug, as it’s impacting Tasha, a VIP user from an important customer.

Having never done this before, he writes up a hasty, emotionally charged paragraph in a Slack channel, tagging @engineering. Words and phrases like “red alert!”, “ASAP!”, and “critical relationship!” are liberally sprinkled in, but it’s scant on actual details; there’s only a cropped, low-resolution screen grab showing a generic error message, and of course, the name “Tasha”, to go on.

(Xavi is not wrong to do this; it really is important, he just doesn’t know how best to get this sorted out.)

Given how many other inbox items there are to get to, he swiftly moves on with his day, feeling that he’s done a good job of delegating this important customer need to the right people, with no delay. And with plenty of exclamation marks!

—

Andrea, from Engineering, who’s on the internal support rotation today, sees the request and responds to Xavi, asking him to log a formal bug report.

“Formal” in this case means that he is to go to a specific Asana project, hit New Task, choose the Bug Report template, and fill in the necessary details.

Included in the template are steps to provide useful screenshots, links to affected pages, email address of the affected user, as well as the actual text and attachments of the user-reported issue.

Anything that’s missing should be sought from the user first; the task should be parked in a waiting area until they’re provided.

Andrea mentions that the Asana project link is in the internal support channel topic, next to the words “FILE BUG REPORTS HERE →”.

Andrea tabs back to working on the documentation updates she was busy with before the ping came in, feeling that she’s done a good job of guiding this clearly important task into the right channel for accurate resolution.

Neat and orderly, wrapped in a bow.

—

So… now what?

The work is stalled at this point, but everyone believes they’ve already done the right thing.

Dr. Ron Westrum, a sociologist, who, as part of his research into what makes for safe, successful outcomes more likely in high-risk, high-complexity fields (such as air flight), found that the following cultural human factors are predictive of respectively low, middling, and high quality and safety outcomes.

He grouped them into three broad descriptors of the organisation in which these humans operate, collectively, Westrum’s Typology of Organisational Cultures.

Here they are:

Westrum’s Typology of Organisational Cultures

Let’s explore what it might be like in each of these cases for Xavi and Andrea, and therefore also for Tasha.

See if you can find elements of the model as you take the different scenarios in.

In the Pathological case, they could stall out — neither of them wants to take the next step because it’s “not my job”. They each believe they’ve done what their role requires (and they’re technically correct), but nothing comes of it.

After nothing happens, it’d probably be escalated. Fingers would be pointed. Blame assigned. Perhaps even some outright conflict, if this is finally the proverbial “feather that breaks the camel’s back“ for this team.

Either way, it’s a bad outcome for Tasha; who is either going to wait a long time, or not get any help at all.

Indeed, in a Pathological organisation, there may not even be an Andrea around to guide Xavi, or a place for Xavi to go to get this guidance. There may even not be a Xavi to represent the user to begin with!

—

In the Bureaucratic case, we have already seen this begin. Andrea’s guidance is to follow a carefully prepared channel. That’s pretty bureaucratic, so far, which doesn’t necessarily mean it’s a bad thing, if it produces good outcomes. In this case, it does; it’s designed to scale to meet a high degree of concurrent demand.

Xavi doesn’t know this, or care about this, he just wants to get back to the next thing. So he rolls his eyes a little, and ‘maliciously complies’ by pasting the Slack message he’s just typed into the new task, and hits send. He doesn’t really take in the goals of the template’s information design; after all, he’s not An Engineer.

Andrea (or whoever’s on inbox triage at the time), then has to review the report and ask for the missing bits to be completed again. Eventually, after enough back and forth in the task comment thread between Xavi and whoever’s on duty, enough information is gathered, and an Engineer starts working on the bug. This may take hours due to the delay incurred during this back and forth.

Later, once the bug itself is fixed, there’s no feedback beyond “fixed” followed by the task being marked complete. Xavi writes a flowery and apologetic message to Tasha, with a politically correct version of “welp, engineering folks, what-ya-gonna-do?” threaded in there.

—

In the Generative case, Andrea follows up her standard ‘use the template please’ response with an offer to coach Xavi via screen-share. Xavi happily accepts the support, and they spend 15 minutes working through it together.

Andrea shares a bunch ‘why this process is helpful to us both’ type context in this conversation, which helps Xavi to understand why his part is important, and how doing it helps Andrea’s team to help both him and the important customer he’s representing. Xavi is able to connect the dots between his personal effort of learning the process and the template, and getting the outcome he wants.

Not only do they fill the task in together, but they also work through all the source material they can find. The support request email itself, whatever they can see in their proprietary platform’s user activity log, the configuration governing Tasha’s experience… really anything that helps them both to form as complete a picture as possible of what the user is struggling with.

They still come up a little short, but as Xavi understands the importance of this, he’s able to go back to Tasha with a clear, actionable request for additional information (which he and Andrea prepare together — Andrea has a playbook of copy-paste steps to draw on, which Xavi bookmarks for next time). The task itself is parked in a “Waiting for Input” list with everything they’ve gathered thus far.

As soon as Tasha responds with that information (who appreciates the prompt attention, and crystal clear next steps to follow), Xavi adds it to the task and moves it back into the “Inbox” area. Marko, the next engineer available, sees it within 10 minutes, and his diagnosis work begins.

As he has all the details he needed before he started work, he’s able to replicate the issue clearly, identify the cause quickly, write up a new regression unit test that probes the issue, fix the bug itself, merge into the staging branch, and then, after it’s peer-reviewed by Andrea, deploy the staging branch to the production environment.

Then, Marko and Andrea write a concise summary of the issue and how it was resolved, and provide any next steps for Tasha to take. The task moves into the “Waiting for input” area again, and Xavi is notified.

Marko also creates a documentation update task, citing the bugfix task, and shares a few bullet points of what needs to change, and how.

Xavi writes to Tasha with the good news, informs her clearly what to do to move past the issue, and the job is done. Everyone rightly feels the ‘job well done’ feeling, each having played their part and provided suitable peer support at key moments.

—

In each of these scenarios, a bunch of attention and energy is expended, for a certain amount of value.

In the Pathological case, the value-to-effort ratio is so low, it’s laughable. No one is satisfied. Apathy and contempt are likely present in equal parts. Sadly, we’ve all either been on the receiving end of such service, or been unlucky enough to work in an organisation where this is the way things (don’t) work.

In the Bureaucratic case, the value is there, but the associated waste and delay is higher than anyone really wants. Each person probably believes they personally would make it better if they could, but ‘this is just how it is, sorry. I did my job.’ And, there’s still some apathy and perhaps even some contempt. No one really knows why things kinda suck.

In the Generative case, everyone genuinely gets their needs met. Yes, the effort is still non-trivial for some folks, but the value return for that effort is much longer lived, and it’s optimised such that the next investments everyone makes are more likely to solve something novel, rather than on repeating the same old patterns. That is, Xavi doesn’t need to be guided again; Andrea has the bandwidth to help someone new.

Xavi learned a valuable process, which he and anyone he represents will benefit from. Indeed, he’s able to bypass the Slack channel step entirely now, and go straight to filling that task template in himself, and, he has a fairly good chance of requesting details from those he supports without any assistance from Andrea or any of her colleagues. He’s also well positioned to guide his peers to do the same!

All of this reduces demand on the system, and it all reduces delay. Both of which contribute to an overall increase in throughput of the system. Everyone performs their roles well, and are spending their respective ’attention budgets’ appropriately.

Andrea, or whoever’s on duty, has more time to help other folks out, or perform other tasks, because now Xavi is self-serving.

And, the system they both support got better, not just for Tasha, but also for anyone who follows in Tasha’s footsteps next time, thanks to the improvement in documentation.

Also - stepping back from the work, and looking at the social side - Andrea and Xavi likely had a good time working together. Andrea felt good because she got to teach Xavi something she cares about, and Xavi appreciated the attention and care in ”leveling him up”. They now have a shared experience — a bond — which will help them when their shared system of work is placed under stress in future.

And let’s not forget Tasha, who got some stellar customer service!

My goal is to help you to see the systems you’re in. I believe that once you do see, it’ll be hard to unsee. You’ll have become more conscious.

Seeing is the first step to making improvements, and to removing pain.

With each person seeing the systems that they are in, they are far more likely to have empathy for each other’s responsibilities and needs, and to recognize that neither of them can succeed without the other. It’s a team game.

Perhaps you’ll be able to do the same for your peers, your manager, your direct reports, and for the extended organisation around you.

You might already be a leader of people, whether as an engineering manager, one of the many flavours of P manager — Project, Product, or Portfolio. Perhaps you’re more senior, working in upper management or in the C-suite. Or, perhaps you’re someone who is specialized, working to deliver some key part or another of the product you’re building or supporting.

If you see the system, you can think through interactions with greater objectivity. You can think in terms of roles, incentives, feedback loops, waste, delay, demand, and many other wonderful models for sense-making.

—

In systems thinking, we have this profound quote from Dr. Russell Ackoff:

…the performance of the whole is never the sum of the performance of the parts taken separately, but it's the product of their interactions.

Paraphrased, that becomes:

A system is not the sum of its parts, but rather the product of its interactions.

Too often, we deal with performance as something to do with the individual.

That is, that the ‘wrong action’ is an individuals’s action. Someone is usually ‘to blame’.

However, the reality is the ‘problem’ is not due to the behaviour of one individual or another, but rather the emergent outcomes of their collective behaviours.

That is, it’s possible for two ‘rights’ to make a ‘wrong’.

My hope is that I can help you — and anyone you’re working with — to find these interactions and work on them at that level, which means being able to see these interactions; to see the system. And help everyone involved — not just those that would be ‘blamed’ — to do better, and to have a better life at work.

So that you can guide your system of work more towards living those Generative stories, just like Xavi and Andrea, Marko and Tasha got to experience together.

—

Credits and sources

1 — Westrum’s Typology of Organisational Cultures

The original paper:

• https://qualitysafety.bmj.com/content/13/suppl_2/ii22

An overview published by the Google Cloud folks:

• https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture

I first learned of this topic when listening to Gene Kim speak with Dr. Westrum himself. I hugely recommend it, and the whole IdealCast series.

2 — Dr. Ackoff on Systems Thinking

http://deming.org/ackoff-on-systems-thinking-and-management

There’s plenty of video (including in the link above) of Dr. Ackoff’s lectures. He’s a wonderful, engaging speaker, and has many interesting stories to tell. Another big recommendation from me!