Same stuff... Different day.
"With subsequent drawings of the fractal curve, sudden changes may appear." - Ian Malcolm
In my previous article, I discussed the idea of “value” and that it can be defined in many different ways. I also set out my stall suggesting that we can take systematic approaches to create value.
But prior to getting into how to apply a systematic approach we need to have a reasonable definition of what a systematic approach actually means. So, with that in mind, I want take a small tangent to understand two of the foundational elements of systems themselves.
The first is the idea of “process” and the second is “feedback”. I’ll talk about feedback in the next post, but in this one we’ll look at processes.
Most people are aware of the idea of processes, but maybe don’t think about them on a day-to-day basis. Nonetheless, like maths and language, it’s not overstating it to say they are a foundational force operating behind everything in the known universe. Whilst our traditional education teaches us about many specific instances of processes, such as rock formation, how to balance equations, visual composition and learning a sport; the field of process and systems thinking doesn’t tend to be seen as a discrete subject.
However, due to their wide proliferation, there are benefits to learning broad “systems-thinking” skills - as the language of processes and systems is applicable across many fields.
Flowcharts are a useful way to visualise processes and look like this…
There is some jargon in here that is useful to know. Processes at their core are “started” by an “event” or “trigger” (sometimes you’ll see events denoted by a lightning flash⚡). They take in “inputs”, involve “decisions” and “steps” - sometimes called “tasks” or “operations” (which may have “conditions“ associated with them) and they produce “outputs” before they “end”.
These are the basic component parts of an “algorithm”, and all processes can be described this way, from getting out of bed in the morning to having a cup of tea, going to the shops or going to war, painting a portrait, or riding a bike.
For example, We recently had family over for dinner and I volunteered to make dessert. Notice that “trigger” there? And, so at that point, I became a slave to the algorithm.
I prepared my ingredients and my competitive nature - the “inputs”.
I followed the recipe “steps” and…
…behold! The “outputs"…
The nice thing about processes is that - whilst they can be complicated - they are deterministic. This means that - all other things being equal - if you start with the same defined inputs and diligently follow the same steps, they will result in the same defined outputs.
1 + 2 will always equal 3.
It’s important to note here that “outputs” and “outcomes” are different things. Within a process, we are not concerned with outcomes - just outputs. We’ll discuss why the distinction is important in a future discussion about goal setting, but for now, just recognise that the output of the process was the tart. The warm fuzzy feeling from the smiles on my families faces and smug satisfaction from the plaudits I received were the outcomes. (Perhaps a background delicious morsel of thought to chew on for next time - given the context of value creation - “Is an outcome or an output more valuable?”)
When it comes to documenting and communicating around processes, it’s worth remembering that “the map is not the territory” and that flowcharts are not the only representation we can use. Just as maps of the same location can look very different depending upon: their use; their context and; the expected prior knowledge of the map reader… so too - a process can be communicated or visualised in many different ways.
In ancient history, a process might have been communicated orally by a journeyman to their apprentice: “Let me show you how to do that again”. However, in today’s information age, that communication might more often take the form of lists of inputs and written method or checklists of steps such as the recipe example. You might also see processes represented visually, such as the “How to make a cup of tea” diagram below…
Complicated processes, requiring expert execution and timing can also have unique specialist representations. Mathematical and musical notation are examples of this.
N.B. This can also vary by depth of specialism such as the Russian chanting music below
As I mentioned earlier, all processes have a starting point kicked off by a trigger of some sort, and end. Once an output has been produced, that’s it. Job done. Sounds like a plan. Hmm, in fact - this actually sounds a lot like a plan!
So, what’s the difference here?
Whilst similar, documented processes are subtly different from plans.
Processes are designed with repetition and reuse in mind and so kept as abstract as possible, such that they can be applied consistently in different cases.
If you think about a plan for going on holiday - you may want to go to Lanzarote to get some sunshine and so your plan would include steps such as..
Go to the Jet2 website and book a flight and hotel.
Book the long-stay carpark at Manchester Airport,
Go to the bank and buy €250 for petty cash.
But, if you repeated this plan over and over you would soon become bored and broke.
On the other hand, a process for going on holiday might be made up of steps and decisions such as…
Book holidays off work.
Decide your budget.
Identify potential resorts and book a room.
Find suitable flights
Buy Travel Insurance
Notice that there’s no specific budget, destination or airline mentioned in the process.
It describes how you go on holiday, but not the specifics of your individual holiday. You can think of designed or engineered processes as a set of instructions, a recipe or “how-to” guide that can be repeated. The key thing here is that it can be shared and applied by others wanting or needing to do the same thing. Processes are the rules of the game - not an individual game.
This can sound a bit academic, but the strict separation of “process” and “content” is important for a process to be generalised and so applied beyond more than one unique situation.
This points to some of the communication challenge around processes. They require a level of abstraction that many people aren’t comfortable with. Concrete examples can help some basic understanding, but systems-thinking requires a level of abstraction - as it is this abstraction that allows for a processes to be repeatable.
So, processes are both repeatable and - in order to be valuable - are repeated often.
This all sounds quite straightforward. “Get this thing… do this to it… and “ta-da”! Result!” However, if this is really the case, why do they sometimes fail or lead to unexpected results?
Whilst processes are stable and deterministic, there is something else at work that makes systems dynamic and non-deterministic and so has the potential to make or ruin everyone’s day. That “something” is the oft-misunderstood concept of “feedback”.
It’s this element of feedback that is at the core of systems thinking and can explain - in spite of having robust processes:-
why a small change can have a big impact (the butterfly effect);
why a consistent approach often leads to consistent outcomes…
…but sometimes doesn’t;
why some small issues escalate quickly and other large ones seem to resolve themselves;
which situations are worth investing effort in and which you can “set and forget”.
We’ll discuss how specific types of feedback affect processes next time but in the meantime, you can subscribe below to be the first to know when I post.
See you next time and thanks for reading!
Footnote: Feedback loops can literally make or break a system.