Workers on scaffolding

Building blocks for a resilient organization

It was great to have so many people attending my webinar “Building blocks for a resilient organization” on April 23rd. The subject seemed to be resonating with a big audience and I want to thank everyone for their engagement and questions and especially to the many who got back to me through Linkedin or email: it looks like the community of people who get passionate about ORGANIC agility is growing day by day.

Here you can find the recording of the session, also available on YouTube: have a look at it and feel welcome to share it around with friends and colleagues.

In an era of global challenges, volatile markets and exponentially faster changes, the slow response of decision making and hierarchies makes organizations more vulnerable. Obsessive focus on processes and structures derives from the common mistake of thinking of organizations as machines rather than thinking of them as organisms, social networks of thinking individuals who care about doing a good job.

A new way of thinking about leadership and decision-making is necessary. Instead of a rigid framework you rather need guiding principles to apply in different contexts: don’t copy what someone else has done before and instead find your own solution.

In this webinar, I gave an overview of the building blocks of ORGANIC agility: the leadership framework, principles, tools and practices that help on your journey. With these, you can create an organization that can organically grow and adapt to challenges of the future.

The ORGANIC agility framework allows different kinds of agility to grow in different environments, instead of imposing a single model on everybody. In this way, it is possible to map existing capabilities to market demands, and evolve following trends, as opposed to implementing a specific organizational blueprint, which might have become irrelevant by the time it is finally implemented.

The first element is the Leadership Framework. It is often the entry point for organizations, both because usually, leaders in organizations have been fighting the uncertainty of the markets for long enough to have an instinctive grasp on complexity and because engagement at the leadership level increases the probability of positive results. There are three key aspects to ORGANIC Leadership: first, it sees leadership as a capability rather than a role. Second, it can be combined with and recognizes multiple leadership models that are out there in the world today and sees their value in context, placing particular emphasis on the complexity-informed models. Finally, this is the only current framework that combines situational awareness, leadership attitude, and organizational culture in order to improve effectiveness with the minimum of resistance, and it is presented alongside an intervention model that can facilitate the transition to a different kind of leadership.

The second element is a set of five principles, which play the role of scaffolding alongside the leadership framework. The principles represent different degrees of complexity and different intervention needs. Scaffolding, in this case, reminds us that the principles are not rules that are meant to be followed forever. There are different kinds of scaffolds: some support the construction of a building whose future shape we already know, some provide nutrients for growth to happen, and some completely disappear once they are no longer needed. The same applies to the five principles: once they have been fully integrated into an organization and become part of its DNA, explicit reference to them is unnecessary.

Principles come associated with tools, the third element of ORGANIC agility. They are meant to help the translation of theory into practice and make complexity manageable. Understanding the present condition, establishing fast and diverse feedback loops, and exploring multiple options are all essential.

OrgScan overview


Remember to sign up to the upcoming webinar, continuing on the same ORGANIC agility pattern. The upcoming webinar takes place on May 22nd. More details and signing up. To learn more about ORGANIC agility, you can have a look at the website.

We created an online SenseMaker pulse that would test the level of resilience of various industries sectors towards COVID-19 and learn how many have been adapting successfully to working remotely. We encourage you to participate in the pulse and share a story by accessing the following link: collector.sensemaker-suite.com/?projectID=BusinessResilience_Master. It will take no more than 10 minutes. You are also welcome to share multiple stories as well as the link with friends and colleagues.

We will prepare a report based on the collected stories, which will help everyone understand more and take inspiration from.

 

ORGANIC agility: The handbook is now here!

For most readers of this blog, there will be nothing new about the words “ORGANIC agility”. Put simply, ORGANIC agility decenters the mechanical approach that sees organizations as machines built of discrete parts but sees them instead as living networks of relationships between people. Their growth, their culture, and their ability to adapt are all related to this sense of potential and responsiveness that can be found in natural, evolving systems. We believe that this approach is the best way to resilience in the constantly shifting and dangerous market environment organizations of all sizes operate in.

ORGANIC agility draws from a rich background of organizational theory and offers support in the form of a leadership framework, a flexible scaffold of five guiding principles, and a set of practical methods and tools. As you can imagine, the entire concept can be quite dense. Last year we started composing a booklet, initially with the purpose of orienting our training attendees around its landscape. This soon took a life of its own and expanded to include information around each of the core concepts of ORGANIC agility, alongside practical tools to support the theory components.

Responding to popular demand, we are now making this handbook available to the general public, hoping that anyone who is interested in organizational culture, leadership, resilience, and adaptation can benefit from access to it. With this handbook, we hope to support your explorations and start you down new paths, not with an exact map, but with a compass.

You can purchase the handbook on Amazon in print and Kindle formats.

The Cynefin Framework

What does the word ”Cynefin” mean?

The word “Cynefin”, pronounced ki-neh-vin, is a Welsh word that cannot be directly translated into English. However, it is commonly translated as ‘habitat’ or ‘place’ and means a place of multiple belongings. We are all rooted in many different pasts which profoundly influence who we are, but of which we are only partially aware. i.e. geographic, tribal, religious, cultural, etc.

Origins of Cynefin

Cynefin was first developed by Dave Snowden in 1999 in the context of knowledge management and organisational strategy. By 2002, it had developed to include complex adaptive systems theory. It was further developed and elaborated with Cynthia Kurtz as part of their work with the IBM Institute of Knowledge Management, and by Mary Boone to extend the model to Leadership. It appeared as the cover feature in the Harvard Business Review in 2007 in the context of leadership.

What is Cynefin?

Cynefin_framework_Feb_2011

Cynefin is a decision framework that recognises the causal differences that exist between different types of systems, proposing new approaches to decision making in complex social environments. Cynefin is also a sense-making model, not a categorisation model. In a categorisation model, the framework precedes the data. This is good for exploitation but not exploration. In a sense-making model the data precedes the framework, making it good for exploration.

The 3 basic types of systems involved in Cynefin are; ordered, complex and chaotic. Ordered systems are divided into 2; simple and complicated. There are 5 domains in total; Simple, Complicated, Complex, Chaotic and Disorder (in the middle of the image above).

Before we move on to describe the various domains, I hope that the two sentences below will help you understand why Cynefin can be so beneficial for us:-
We need to think differently about different problems. There is no one size fits all approach and the actions you take depend on which domain you are in.

 

1. The Simple Domain

In the simple domain we are in an ordered system where the relationship between cause and effect exists, is predictable in advance and is self evident or obvious to any reasonable person.

We apply best practises and the approach is to:-
SENSE — CATEGORISE — RESPOND
Sense           – See what’s coming in
Categorise  – Make it fit predetermined categories
Respond     – Decide what to do

Eg. A clerk in a banking institution calculating compound interest. Best practise is applied in terms of predefined formulae and given an input the results are always the same.

 

2. The Complicated Domain

In the complicated domain we have an ordered system where there is a right answer and where a relationship does exist between cause and effect, however, the answer is not self-evident and requires analysis and/or the application of expert knowledge. There can be several different ways of doing things in this domain, with the right expertise.

We apply good practise and the approach is to:-
SENSE — ANALYSE — RESPOND
Sense      – See what’s coming in
Analyse  – Investigate or analyse, using expert knowledge
Respond – Decide what to do

Eg. Anything that can be solved with professional training or external consulting services, like the need to develop software in a specific language (ie. C# or Java).

 

3. The Complex Domain

In the complex domain we have unorder where the relationship between cause and effect can only be perceived in retrospect and the results are unpredictable. Complex systems are therefore dispositional and not causal. Here, we need to create safe to fail experiments and not attempt to create fail safe design. We cannot solve complex problems with best or good practices alone. While conducting safe to fail experiments, we must dampen the parts that fail and amplify the parts that succeed. In this domain we get emergent order and practice that is often unique.

Emergent practice, behaviour or order results and the approach is to:-
PROBE — SENSE — RESPOND
Probe      – Experimental input
Sense      – Failures or successes
Respond – Decide what to do ie. amplify or dampen

Eg. Most types of innovation. Professional training or best practices are replaced with probing different approaches and ideas, sensing the results/feedback to see what works and what doesn’t, and responding appropriately (by amplifying and dampening our probes).

 

4. The Chaotic Domain

In the chaotic domain no cause and effect relationship can be determined. We have to stabilise the position very quickly!

We discover novel practice and the approach is to:-
ACT — SENSE — RESPOND
Act           – Attempt to stabilise
Sense      – Failures or successes
Respond – Decide what to do next

Eg. A medical emergency situation.

Note: It is possible for a problem to fall into more than one domain simultaneously. I will show an example of this at the end of the post.

 

5. The Domain of Disorder

This domain includes the state of not knowing what type of causality exists or what space you are in. The problem here is that we interpret and assess the situation we are in based on our personal preference for action, reverting to our own comfort zones.

For the sake of completeness

Transitions can occur from the Simple to the Chaotic domains. Here you ‘fall over the edge’ and any recovery is extremely expensive. For this reason, we should attempt to manage things in the complicated and complex domains.

Using Cynefin

Cynefin has been used for analysing policymaking within the George W Bush administration and the impact of religion in that process, the nature of response to bioterrorism, as well as aspects of measurement in the British National Health Services. It’s also been used for the retrospective study of emergency situations and to study the interaction between civilians and the military during disaster control.

That’s all great – you might be thinking – but how can I use it?
Consider this: – if you spend 2-3 years in a process based bureaucratic role, you’ll tend to see all problems as failure of process. If you’re an expert in a particular field, you’ll tend to see any problem as a failure to give you the necessary time or resources to do your expert analysis. We therefore have a natural tendency to categorise problems based on our own knowledge, skills and previous experiences.

Let’s take the subject of software quality as an example.

You might be forgiven for thinking that by applying best practice techniques such as BDD, TDD, Pair Programming, Code Analysis (cyclomatic complexity, etc), Automated Integration Testing, Automated Regression Testing, that you will be able to build a near bug free software product. However, what if for example, your business logic is contained in your database layer’s code in stored procedures? If you could unit test the stored procedures would you still need your 90+% unit test coverage in your application code? Would you still need as many automated integration tests? Or would you even perhaps decide to put even more effort into the automated integration testing and not unit testing? Software quality has elements in all the Cynefin domains. There are best practices and good practices that we should make use of. However, in context of the discussion here; in my opinion, the complex parts require us to create safe to fail experiments, trying different approaches, observing their results, and then dampening or amplifying elements of your experiments along the way to see what works best in your context.

Conclusions

When you’re next faced with a problem, question your immediate problem solving approach. See if the problem can indeed be tackled with best or good practice or whether you need to do a little probing, sensing and responding. Finally, we probably all agree that the incremental delivery of software with frequent short feedback loops is the approach we should use; releasing small bits of high value software, receiving feedback, reflecting, adapting, and repeating. Does this not sound complex to you?

Written by: Mark Nilsen of Derivco