Part 1: Autonomy – Autonomy Support – Autonomy Enabling

I wrote the 1st of a 2-part post some time ago, but never published it because I didn’t get around to completing part 2. I’m finally publishing part 1 now…because it might ‘make me’ finish the 2nd part.

I’ve been on a book-reading1 and work-experiential journey over many years and have reached a place that I’d like to ‘set out clearly in writing’ (for myself, and others) …and yet I’ve struggled to do this so far (a.k.a writer’s block).

I’ve been talking ‘about’ (but not been writing) this post for months!

So here goes…

Some context:

I (and hordes of other people) work in, around, and across large, complex people-centred systems. Think government departments, NGO’s and so on who are trying to help thousands of clients2 better live their lives.

Such systems are usually highly bureaucratic, operating in an (attempted) ‘control system’ way.

They can be helped to see the problematic performance that this system design provides to their clients, but they (we) can then struggle with moving to a different way of thinking and being.

The aim of this post (‘Part 1’) is to set out the ‘what and why’ of moving to a different paradigm, where ‘control’ is replaced by ‘autonomy’. ‘Part 2’ will aim at discussing the rather important topic of a ‘how’ to get there.

As the title and opening image suggest, there’s an ‘autonomy’ chain (from the client, all the way through the system)

What follows is broken up into:

  • Link 1 (of the chain): Autonomy;
  • Link 2: Autonomy support; and
  • Link 3: Autonomy enabling.

Link 1: Autonomy – People-centred…what does that mean?

I used the term ‘people-centred systems’3 above and I should set out what is being meant, and its relevance.

(As usual) I am writing in respect of service systems (as distinct from manufacturing).

Service systems themselves have been broken into different archetypes. I’ve read various ways of setting these out4, but here’s a simplified version (of 3 archetypes) from me:

  • Archetype 1: Transactional where, given the nature of a customer’s demand (a.k.a. need), it should be able to be resolved in a single interaction.

Example: If I contact my home entertainment provider because I want to change aspects of my plan (e.g. gain access to a movie channel), then I should be able to achieve this by the end of that one interaction.

Note: this may or may not happen in the one interaction, depending on how they have designed their system to respond! It might turn into a right dog’s dinner!

  • Archetype 2: Process where, due to the nature of what the customer/ client needs, it could not be delivered in a single interaction. Instead it needs to enter a process.

Obvious example: If I contact a builder because I want an extension to my house, this can’t be delivered within an initial interaction. Instead, a bunch of (often well understood) stuff now needs to happen (and hopefully flow).

I should reach a point at which the process is completed: I’ve got what I wanted (hopefully efficiently and to a high quality) and I can go on my way.

  • Archetype 3: People-centred (or Relational) where the nature of the need is about the person (client) themselves. This is far more complex than a transaction or a process. All our social systems fit here.

Each person (client) is unique and recognising this is of fundamental importance if we are to help – we can’t just treat it like ‘a transaction’ or ‘put them through a ‘process’.

To help the person, we will need to achieve engagement with them (reaching and sustaining a trusting relationship), and then understand and support them through a (dynamic and evolving) journey in which they have the most important role to play.

The other word used here is relational, because THE important variable for successful change is the relationship between the person and their helper(s).

“At the heart of this new way of working is human connection. When people feel supported by strong human relationships, change happens. And when we design new systems that make this sort of collaboration and connection feel simple and easy, people want to join in. This is not surprising.” (Hillary Cottam, ‘Radical Help’)

The big mistake that many social systems make is that they are designed along transactional and process lines by a (centralised) control system. A relational response can’t be achieved transaction-ally. Sure, such a system might be able to ‘smash out’ transactions…but it will most likely keep its clients dependent upon it, with repeat visits and, sadly, relapses and deterioration.

So, I’ve tried to explain ‘people-centred’ and you might now think ‘er, okay, so what?’

Well, if we are talking about people, and them achieving meaningful and sustained change, then we need to understand the fundamental importance of self-determination (a.k.a autonomy).

People achieve true change when they choose to do so for themselves.

We end up with the (hopefully) rather obvious point that the best way to help another person is via autonomy support (with this concept set out in detail in a previous post), which can only happen via strong human relationships.

Link 2: Autonomy Support – Variety…and how best to handle it

So, we’ve got:

  • the uniqueness of every client and their contextual and dynamic situation;
  • each client (a human being) needing to ‘go there for themselves’; and
  • helpers (also human beings!) that need to travel alongside them, without judgement or attempts at control.

Looking at this, we can see that we have enormous variety in a people-centred system (in clients, in helpers, in ‘client–helper’ relationships). So, what’s the best way to handle this?

Turning to W. Ross Ashby’s Law of requisite variety to assist…this is explored by Gerrit Broekstra in his book ‘Building high-performance, high-trust organisations’:

“Variety is a measure of complexity and refers to the number of possible states of a system.

[There is a] colossal proliferation of variety in dynamic systems.

Applied to organisations in their complex environments, only matching the variety of the organisation can soak up the complexity of the situation with which it is confronted. No hordes of consultants, planning committees, surveys or management training courses can do the trick.

[The most effective way to deal with such variety is to] be organised on the basis of the principle of self-organisation….as exemplified in autonomous groups.

Or, to put it into a simple statement:

          “Only variety absorbs variety.” [Stafford Beer]

I recognise that the above reads as rather theoretical. Here’s a practical example:

Take any large social system. It is usually trying to serve a large geographic area (perhaps even a small country).

A central control system attempts to:

  • monitor what’s going on across the whole (ref. KPI’s);
  • judge from afar (ref. targets, comparisons);
  • design ‘solutions’ (ref. departments/ functions/ specialist roles, products & services, detailed policies and procedures…)

…and then push these out to all (to be ‘standardised’) and then…‘rinse and repeat’.

Not only does this fail to absorb client variety, it often (usually) frustrates it!

The opposite would be where each ‘locality’ functions, by design, as an autonomous unit – a group of peers who (are enabled to) take responsibility for the wellbeing of their local cohort of clients and helping them with their unique needs.

“Self-managed teams are far more productive than any other form of organising. There is a clear correlation between participation and productivity.” (Margaret Wheatley)

This creates that glorious (yet rare) combination of:

  • each client feeling that someone actually cares about them;
  • each front-line worker feeling like they have a meaningful job; and
  • each unique client situation (variety) being understood, with bespoke support provided (variety absorbing variety)

“Idleness, indifference and irresponsibility are healthy responses to absurd work…if you want someone to do a good job, give them a good job to do” (Frederick Herzberg)

We’ve now added the concept of autonomous units to deciding how best to help and support a cohort of autonomous clients.

So, if autonomous units are what’s required, where does that leave the concept of ‘organisation’?

Link 3: Autonomy enabling – Organisation…what should it be for?

This post is not suggesting that such autonomous units can, or even should, work on their own. It is saying that they pull for help from central support functions when they need to.

The (paradigm-shifting-ly) huge difference is that the front-line autonomous unit is the one leading what they need help with, rather than being dictated to.

They also decide whether any central support provided is actually helpful, and adopt or disregard it accordingly.

The onus is on the enabling centre to provide valuable support (as judged by those helping clients).

“The logical consequences of this way of viewing organisations, with its abundance of freedom of choice for its purposeful parts, unequivocally leads:

    • on the one hand, to the autonomy of the operating units and the people contained in it as purposeful entities; and
    • on the other hand, the remaining ‘upper part’ of the high-variety organisation as an enabling entity, actively involved in furthering the development of the autonomous unit and their people.” (Gerrit Broekstra)

A sense-check on the purpose of ‘organisation’:

“Hierarchical systems evolve from the bottom up. The purpose of the upper layers of the hierarchy is to serve the purposes of the lower layers…

The original purpose of a hierarchy is always to help its originating systems do their jobs better…

This is something …that…a greatly articulated hierarchy can easily forget.

Many systems are not meeting their goals because of malfunctioning hierarchies.” (Donnella Meadows)

Right, so we’ve worked our way through the concepts of self-determining clients (tick), autonomous units (tick) and an enabling (as opposed to controlling) centre (tick), but if this is sooo good, why doesn’t this eventuate?

That’s the subject of Part 2: the problem of changing from ‘this’ to ‘that’.


Addendum: Towards a picture…

If we’d like to ‘draw a picture’ of what the fundamentals of an effective people-centred system might look like, whilst remembering that “all models are wrong, some are useful” (George Box),

Then here’s an attempt from me…

I’ll build it up in three stages:

Picture 1 – The core:

1. The client (in green) is at the centre, along with the principle of self-determination (a.k.a. autonomy). It is about helping them on their journey, not (attempts at) pushing them through ours.

2. Their family/ Whānau and friends (in yellow) surround them, in recognition that:

  • no one is an island. The client exists within a social structure (for good, and sometimes, not so good)
  • to effectively support a client, we need to understand, contextualise and appropriately leverage their social network. This includes helping the client do the same. This might be the most powerful thing we can do.

3. The helper(s) (in blue) directly working with the client (‘value creating’). Their aim should be to create, and retain, a ‘working alliance’, in which there is mutual trust and respect. This will be about:

  • active/ reflective listening (truly seeing the world from the client’s point of view); and then
  • supporting the client through their journey, including resolving their transactional and process needs along the way

In doing this, we shouldn’t expect that helper(s) need to know everything. We would hope that they can easily ‘pull’ knowledge (from a useful source) as and when they need it. Note the deliberate choice of the word knowledge, rather than ‘policies and procedures’.

Picture 2 – adding support ‘in the work’:

We’ve now added a support ring around the core.

4. Local support (also in blue) that support the value creating workers in helping clients. Their aim is to be ‘in the work’, to observe the work as it happens, to be pulled ‘live’ as and when the value creating worker hits an obstacle.

 Such a pull may result in:

    • developing the capability of the helper (‘in the moment’ experiential learning); and/or
    • capturing evidence of obstacles outside of their control

5. Accessible help (in red) which represent those things that naturally sit outside the capability and/or capacity of local support.

It (deliberately) isn’t worded ‘available products and services’ because this isn’t the nub of what’s required. Sure, there might be a set of services available to be utilised, but it is up to the local team (with the client) to determine what to pull for, and when.

Further, the client isn’t being ‘referred over to’ the help. The help is being pulled into the client and their value creating worker…. who will also consider whether it is working for them or not.

Picture 3 – adding the enablement of those in the work:

6. Central roles (in purple) whose whole purpose is to enable those working with clients. They don’t attempt to control. Rather, they enable when they are pulled for help in removing obstacles in the way. This is a drastic change to the conventional central function.

The locus of control is with those directly helping the client.

An enabling response might include a focus on developing any of:

    • the knowledge available;
    • the tools (such as financial and technology support);
    • the accessible help (such as adding/ linking to new services, making them more flexible,…);
    • the capability of those helping clients (and those supporting this).

A note re. ‘Delivery engine’: Many central functions of large organisations are working hard to become ‘Agile’. I’d concur that it is important to work on ‘how’ to deliver (efficiency). However, of more importance is ‘what’ to deliver (effectiveness).

So, whilst we would want an ‘Agile’ delivery engine, we want it to be delivering to enable (from pulls), not to control (via pushes).

Being ‘Agile’ might be necessary….but it’s by no means sufficient.

And this completes an ‘autonomy – autonomy support – autonomy enabling’ model.

Or (if you are a Kiwi who watches the NZ comedy quiz programme ‘7 Days’) …”and this is my picture”

Footnotes

1. A book reading journey for this post – for those that are interested:

  • I first came across the idea of different system types and the transformational importance of matching the appropriate organisational model from reading a brilliant Russell Ackoff essay in his book ‘Ackoff’s Best: His Classic Writings on Management’. If you’d like to understand (or remind yourself of) this, then I wrote a post some years back: “Oh, so that’s why command and control doesn’t work very well!” Today’s post picks up where the ‘what might that [social] model look like?’ question posed at the end left off.
  • Some years back I read Hope and Fraser’s 2003 book ‘Beyond Budgeting’, which gave me an initial introduction to Jan Wallander and his wonderful thinking in respect of how best to run a large service system for the good of clients, and employees. If you’d like a bit of an introduction to Wallander and his different thinking then I wrote about him here: Back to that ‘Profit Sharing’ Nirvana
  • This book led me to Gerrit Broekstra’s 2014 book titled ‘Building high-performance, high-trust organisations: Decentralisation 2.0’. This gets into some meaty understanding of the ‘what and why’ of a different model. Broekstra refers to the model as an ‘autonomy and enabling’ paradigm.
  • I was on a parallel path when I read Edward Deci’s ‘Why we do what we do’, which introduced me to self-determination theory and the hugely important concept of autonomy support.
  • I had original come across Deci from reading Alfie Kohn’s ‘Punished by Rewards’.
  • I then managed to get hold of Jan Wallander’s 2003 book ‘Decentralisation – why and how to make it work’, which nicely got me into the nuts and bolts of how he successfully led the change of a service system from centrally controlled to autonomous units. [This is the subject of my ‘Part 2’ post]
  • I also read Hilary Cottam’s 2018 book ‘Radical’ which cemented my thinking in respect of the need to create relational (rather than transactional) systems when we are trying to help people help themselves.
  • I then read Miller and Rollnick’s book on Motivational Interviewing (3rd Edition) which also connects extremely well.
  • And Motivational interviewing fits well with Gerard Egan’s book ‘The Skilled Helper’.

And this all comes together into an ‘Autonomy – Autonomy support – Autonomy enabling’ logic. Now you know why I was struggling to put something into a single post.

2. Clients, not customers: See footnote on my previous post for a comment on the difference

3. Person-centred system: I believe that the root of this phrase is Carl Roger’s person-centred approach.

4. Service system archetypes: Stuart Corrigan’s 2012 little book ‘The need for change’ was the first time I read about service archetypes. This thinking has been refined/ matured by others since then. Also reference Hillary Cottam and her setting out relational systems.

5. Re. people-centred/ relational: Amusingly (to me), many ‘for profit’ consumer businesses are desperate to be relational with us…even though they are, by their nature, transactional or process system archetypes. They want to forge a relationship with us (their customers) and yet we don’t want it! Think about that communications/ entertainment provider – they’ve often invested millions in expensive ‘Customer Relationship Management’ (CRM) technology that remembers your birthday!

6. Systems within systems: A tricky thing about people-centred systems is that they are likely to involve transactional and process sub-sets within. The important bit (I think) is to realise that the people-centred (relational) system is the master, and transactions and processes are its servant…. they aren’t separate.

A social system example: Let’s imagine that I am working relationally with a client on their journey.

  • Whilst doing so, they might move address – it should (probably) be a single and simple transaction to handle this change in circumstances.
  • Further, my relational work might lead to the client wanting help to, say, gain a qualification – this should be a smooth process to set up and then help them to achieve.

Both the transaction and the process sit within the relational journey of helping them better lead their lives (whatever that means for them). Here’s a diagram that hopefully visualises these words:

Oversimplification

!cid_image001_png@01D18034So it seems that many an organisation repeats a mantra that we must “simplify, simplify, simplify”…they accompany this thrice repeated word with rhetoric that implies that this is so blindingly obvious that only a fool would query this!

As such, anyone questioning this logic is likely to hold their tongue…but I’ll be that fool and question it, and here’s why:

It’s too simple!

Here’s where I mention the ‘Law of requisite variety’ which was formulated by the cyberneticist1 W. Ross Ashby in the context of studying biological systems. Stafford Beer extended Ashby’s thinking by applying it to organisations.

Now, rather than stating Ashby’s technical definition, I’ll put forward an informal definition that I think is of use:

“In order to deal properly with the diversity of problems the world throws at you, you need to have a repertoire of responses which is (at least) as nuanced as the problems you face.” (What is requisite variety?)

!cid_image002_png@01D18034

Using the diagram above, let’s say that the problem types on the left (shown by different coloured arrows) represent the different types of value demands from our customers.

Let’s say that the responses on the right are what our system* is designed to cope with (* where system means the whole thing – people, process, technology – it doesn’t refer merely to ‘the computer’).

We can see that our system above is not designed to cope with the red arrows and incorrectly copes with some of the yellow arrows (with an orange response)….the customers with these value demands will be somewhat disappointed! Further, we would waste a great deal of time, effort and money trying to cope with this situation.

What on earth are you on about?!

“Management always hopes to devise systems that are simple…but often ends up spending vast sums of money to inject requisite variety – which should have been designed into the system in the first place.” (Stafford Beer)

Many large organisations engage in ill thought out and/or overly zealous ‘complexity reduction’ initiatives (incidentally, system replacement projects* are corkers for this!) that strip out more than they should and the outcome is unusable and/or hugely harmful towards satisfying customer value demands…which ends up creating un-necessary complexity as the necessary variety is ‘put back in’ via workarounds and ugly add-ons and patch-ups.

(* Large public sector departments have been excellent at this….often scrapping multi-million $ projects before a single live transaction gets into a database.)

Note: for readers aware of the ‘Lean Start-up’ thinking, you might cry out that this appears to go against the Minimum Viable Product (MVP)/ experimentation point…but it doesn’t…in fact it supports thinking in terms of target conditions rather than merely stating ‘make it simple’ objectives and setting related arbitrary targets.

Standardisation?

You might think that, because service demand is infinitely variable 2, then I am suggesting that we need to build infinitely complex systems that can cope with every eventuality with standardised responses. Well, no, that would be mad…and impossible.

In service, we can’t hope to know every ‘coloured arrow’ that might come at us! Instead, we need to ensure that our service system can absorb variety! This means providing a flexible environment (e.g. guidelines, not ‘straight jacket’ rules), and empowering front line staff to ‘do the right thing’ for the specific variety of the customer’s demand before them, and pulling appropriate expertise when required.

Standardisation in service is not the answer.

Cause and Effect

Don’t confuse cause and effect. Simplification should not be the goal…but it can be a very agreeable side effect.

“To remove waste [e.g. complexity], you need to understand its causes….if the system conditions that caused the waste are not removed, any improvements will be marginal and unsustainable.” (John Seddon)

If you think “We’ve got too many products and IT applications…we need to run projects to get rid of the majority of them!” then ask yourself this: “Did anyone set out specifically to have loads of products and IT applications?” I very much doubt it…

You can say that you want fewer products, less technology applications, less complex processes…less xyz. But first, you need to be absolutely clear on what caused you to be (and remain) this way. Then you would be in a position to improve, which will likely result in the effect of appropriate simplification (towards customer purpose).

If you don’t understand the ‘why’ then:

  • how can you be sure that removing all those products and systems and processes will be a success? and
  • what’s to stop  them from multiplying again?

The goal should be what you want, not what you don’t want

“If you get rid of something that you don’t want, you don’t necessarily get something that you do want…improvement should be directed at what you want, not at what you don’t want.” (Russell Ackoff)

The starting point should be:

  • studying your (value stream) systems and getting knowledge; and then
  • experimenting towards purpose (from the customers point of view) , whilst monitoring your capability measures

The starting point is NOT simplification.

A classic example of the simplification mantra usurping the customer purpose is where organisations force their customers down a ‘digital’ path rather than providing them with the choice.

  • To force them will create dissatisfaction, failure demand and the complexity of dealing with it;
  • To provide them with choice will create the simplicity of delivering what they want, how they want it…with the side effect of educating them as to what is possible and likely moving them into forging new habits (accepting that this takes time).

In conclusion

So I’d like to end on the quote that I have worn out most over my working life to date:

“Make everything as simple as possible, but no simpler.” (attributed to Einstein)

The great thing about this quote is that it contrasts ‘relative’ with ‘absolute’. “As simple as possible” is relative 3 – it necessitates a comparison against purpose. “Simple” is absolute and, as such, our pursuit of simplification for its own sake will destroy value.

Thus, the quote requires us to start with, and constantly test against, customer purpose…and the appropriate simplicity will find itself.

Notes:

  1. Cybernetics: the science of control and communication in animals, men and machines. Cyberneticians try to understand how systems describe themselves, control themselves, and organize themselves.
  2. Infinite variability: We are all unique and, whilst we will likely identify a range of common cause variation within service demand (i.e. predictable), we need to see each customer as an individual and aim to satisfy their specific need.
  3. There’s probably an Einstein ‘relativity’ joke in there somewhere.