Karl Weick’s Sensemaking is a powerful frame to understand how organisations work. It can help us better understand Failureship. Paraphrasing, he identifies four stages of understanding:

• Intra – How a person understands something inside their head.
• Inter – How two or more people understand something.
• Generic – How something can be understood generally, making it accessible to others.
• Extra – How something can exist in its own right outside of the relationship with the people (e.g. Maths).

Weick describes sensemaking in organisations as the process of moving things from “Inter” to “Generic” so that others can become part of the organisation and act using the thing.

The key part of sense making is to create “shared meaning”. Shared meaning indicates that the value of something is understood. As value is socially constructed, it means that the value of the thing is understood in the context of an individual’s social organisation. “That’s just Common Sense” means that something previously not encountered aligns with the values of the individual’s social organisations and should obviously be adopted. This understanding of Sensemaking is very aligned with social practice theory ( meaning, practice and material ) which forms part of Marc Burgauer and Chris McDermott’s Maturity Mapping.

Sensemaking is an activity, not a tool.

Luke Hohmann, creator of Innovation Games worked for Karl Weick. Once you understand that, you see Innovation Games in a whole new light. They are not tools to achieve a purpose, they are enabling constraints that structure Sensemaking. Consider one of the simplest games “20-20 Vision”. Compare items one at a time and build a strictly ordered list. The output is an ordered list but the outcome of the Sensemaking is a shared understanding among participants (Inter) of the relative value of the items including why they are valuable, that can be articulated and shared with others (Generic). 20-20 vision constrains the discussion so that it focuses on the value needed to order things rather than deep dive into the detail of the description or implementation of the things.

“Buy a feature” also acts as a Sensemaking enabling constraint, facilitating shared understanding of why users value features, rather than the details of features. Budget Games in San Jose have demonstrated that “Buy a feature” is a Sensemaking practice that scales and enables an entire City to created a shared understanding of the value of each product and service provided by the City to its people.

Sensemaking and Naming Things

Sometimes the act of Sensemaking will identify a new thing. In order to make it quicker and easier to refer to that thing, the community of practice will give the thing a name. The names of things are often chosen out of respect for the ideas that inspired the new thing. Agile is full of such names:

• Scrum – Inspired by the practice in rugby.
• Kanban – Inspired by Kanban systems in manufacturing.
• Feature Injection – Inspired by Dependency Injection.
• Stories – A group of developers sitting around the camp fire listening to the customer tell them a story about how they will use the thing they are creating.
• Epic – A big story that is too big and needs to be broken down.

The name is not important other than a search term. What is important is the shared understanding.

The meaning of the word “Jargon”

Members of the community of practice use the new names they have chosen for the new things to communicate effectively and efficiently. Outsiders are often confused by the language that is only understandable by learning what it means, by engaging in the shared understanding of the terms. Outsiders refer to the language used by the community of practice as Jargon, an indication that they consider the language to have no value… mainly because they do not understand it and it has no meaning to them. Calling something “Jargon” is the equivalent of referring to a foreign language as “noise”. Saying a computer programmer is speaking “noise” or that a person speaking a foreign language is speaking “Jargon” is normally a sign of cultural imperialism or cultural superiority, putting down the language of another group as unimportant and valueless.

Colonialism and Terraforming as an approach to Change

Cultural Colonialism and Terraforming are a popular approach to introducing change into organisations. Executives use consultants to impose new words and tools onto the organisation. They employ experts and high priests and priestesses to impose the use of the new words and tools as a mechanism to drive change. “Teams” are replaced by “Scrums”, “Squads” or “Feature Team”. Departments are renamed as “Tribes”, “Clusters”, “Release Trains”, “Value Streams” or “Chapters” with high priests rewiring the organisation into some new perfect delivery flow. Traditional measures of success are replaced with “Explorer”, “DORA”, and “OKRs” though someone forgot to specify how to use or calculate the new measures, after all does it matter whether the frequent releases refers to “releases of value to the customer” or “releases of software to shelf”. Voices of dissent are crushed. “We have 150 feature flags in production” is hailed as a victory and those that point out its a huge risk to the business are nudged towards the door by the high priests and priestesses.

These organisations with a failureship culture think that change is about adopting new words and tools with the blind faith that the benefits promised by the consultants will follow. Failureship executives are comforted that they have spent so much money with the consultants that the consultants will use their extended networks to get them a bigger job where they can spend even more money on the consultant’s words and tools.

Words are imposed. Tools are imposed. Practices that support the existing ways of working are outlawed. To retain control of the words and make it easier to spot deviants, the vocubulary is reduced. No more rich and diverse contextually appropriate approaches to delivery of value, going forward everyone will only use the words of newSpeak. Although similar sounding, the meanings of words in NewSpeak will change. A story will have a strict definition and format, rather than the deliberately vague definition that allowed each group to find its own way. Epics will not longer be large stories, but will now become a project full of features. Chapters will no longer be parts of a story, but will now be a community of practice, one which is controlled by a manager who will be authorised to stamp out variation and deviant words that they do not understand (Jargon). At the end of the transformation, the organisation will be confused and executives and workers will be further apart with a new language that devides and confuses. Using new language to drive change leads to a lack of shared understanding, it creates non sense,

Sensemaking as an approach to change

An alternatives to cultural colonialism is to engage in Weick’s Sensemaking with an organisation. Engage in a deep and respectful mutual understanding of the current organisation and its practices, understand why the practices are valuable so that that value is captured in any new approach. Discuss the new ideas that the organisation would like to introduce. In order to engage in this process, the people introducing the new ideas need deep experience of using those ideas. They need to be able to make sense of the existing organisation and how the new ideas might adapt. They cannot do this if they have a shallow knowledge of the ideas from reading books, a few training courses and one or two narrow experiences. They also need to engage in the dialogue as equals with the people who are changing their way of working.

This is not an approach that “Experts” consultants can do alone. It requires people who understand the current reality. More important that a detailed knowledge of the new approach, empathy and experience of actually using the new approach, and ideally experience helping others adopt it. What we do not need are certification, expert consultants with no experience and forced transformations via tool implementation.

Wise men once summed it up, we need people who are “doing it and helping others do it.”

Making Sense in the organisation

Any transformation from a risk averse culture to a risk managed culture requires sense making between the different layers and silos in an organisation. Sense making is the process that creates transparency. The different layers and silos in an organisation need to come together and “make sense” to create shared understanding and enable them to provide transparency.

Sensemaking is not something that one group can impose on another, it requires genuine collaboration between all those involved.

Understanding Sensemaking

I found these videos to be useful to understand “Sensemaking” and “The Social Psychology of Organising“. I strongly recommend Karl Wieck’s essay on “The Mann Gulch Disaster” and the book “Managing the Unexpected: Sustained Performance in a Complex World”.

Many of the agile techniques are effective risk management tools that make problems and risks transparent and leave the solution to be determined based on the context. It is common for people to use an agile technique to reveal a problem or risk, and then ignore it when they find it… reveal a serious issue in a retrospective and then simply put an item in the improvement backlog, or turn off a failing test rather than fix the bug that it reveals. It is so common that agile practitioners have a term for it “Agile Kabuki”, an elaborate process where people make extreme gestures but fundamentally they have no impact other than to entertain and give the appearance of action.

In a risk averse failureship culture, the most common and most damaging example of Agile Kabuki is the “Go/No Go” meeting. The “Go/No Go” meeting comes with many different names but if it looks like a duck, and it quacks like a duck…. whether it is called “Design Review Board”, “Architecture Review Board”, “Change Advisory Board”, its a “Duck”

All “Go/No Go” meeting follow the same pattern:

• The stated purpose and justification of the meeting is to protect the production environment.
• Rather than do anything practical and useful, it simply introduces random delay in the development release process. These random delays add to the risk of investments and make it harder for the business investors to plan.
• The “Go/No Go” meetings occur at a regular arbitrary cadence and duration based on the convenience and availability of the decision makers, they are not held on on demand in order to minimise delay.
• Decision makers do not need to have specific knowledge relevant to the system or release being discussed.
• Decisions made in the “Go/No Go” are final, requiring escalation to overturn.

Although the “Go/No Go” has the above stated purpose, the reality is as follows:

• The primary purpose of the “Go/No Go” meeting is to establish the power and importance of the decision makers that attend the meeting. This is multiplied when the decision makers are so important that they can send a delegate to represent them who also has no specific knowledge about the system or the change.
• A “Go/No Go” meeting is “successful” if a decision maker can justify the existence of the meeting, and thus reinforce their importance, by imposing a constraint that forces a delay of the release of an investment.
• “Go/No Go” meetings are vitally important in a risk averse failureship culture as they move the responsibility for a production failure to the process and away from the team making the change. Any failure is blamed on the process rather than the teams responsible for the system. A “Go/No Go” allows a team to focus on passing the “Go/No Go” meeting rather than focusing on the risk of damaging the existing business model. Given the information asymmetry, the team know more than the “Go/No Go” decision makers, it is entirely inappropriate for a distant team with generic knowledge to decide on the safety or otherwise of a release.
• “Go/No Go” meetings are an opportunity for people to increase their importance at the expense of the wider organisations. They are a final opportunity for people to raise issues that should have been mentioned much earlier in the process of developing an investment. An issue raised at the start of a development process is much easier to accommodate and so attracts little attention, whereas the same issue raised just prior to deployment can generate much praise and status for the individual who “saved” the organisation from a disaster. This late reveal is often justified because the individual was far too important and busy to engage at an earlier point. I once worked on an agile flagship project that took eighteen months to deliver the first business value. Nine months into the project, during the User Acceptance Test and just prior to go live, a key user looked at the solution for the first time and declared it would not work and would cause a disaster. They detailed the changes that were needed. Everyone revered them for it.… A home for Dragon Slayers was established.
• “Go/No Go” meetings often occur as a mechanism to demonstrate to industry regulators that the organisation are taking the risk associated with production stability seriously. If an organisation needs an industry regulator to tell them that they need to take their production stability seriously, the share holders of the organisation should change the management, and the customers should change their service provider to one that does take it seriously.
• “Go/No Go” meetings are an appallingly bad approach to managing the risk of preventing a production incident, and even worse approach to minimizing the impact of a production incident.
• Resolving a production incident will often require releasing a fix into production, something that is delayed and made more risky by a “Go/No Go” process.

A Risk Management culture’s alternative to the “Go/No Go” Meeting

In an organisation with a risk managed culture, the focus is on preventing a production incident, and in the event of a production incident returning the organisation and its customers to safety as soon as possible.

Instead of a “Go/No Go” meeting, a risk managed culture would do the following:

• Clearly state the controls and tests to be performed before an application or change can be released to production. Normally these are not a solution but a test that must be passed.
• Automate the controls and tests. Normally building them into the platform. See Jez Humble’s inspiring talk about the US Government from almost a decade ago.
• Automate testing.
• Specify the tests before the code so that the code is built in a way that is testable, and the tests do not break when the code is changed. Moving the creation of tests before the code means that the responsibility creating tested code shifts from the tester to the developer. It means that when the developer changes code and it fails the test, the get immediate feedback and can fix the issue.
• Architect the system so that it consists of smaller independent parts that can be quickly and more easily tested (For example, a micro-services architecture).
• Minimise the number and duration of feature flags and other latent code patterns in production.
• Lock down the build chain and test environments to prevent anyone from tampering with the system and potentially causing a discrepancy between what is tested and what is deployed.
• Use containers to ensure that the test environment is identical to the production environment.
• Use Green/Blue deployments to enable rapid roll back to the previous system in the event of an issue.
• Remove technical debt from parts of a system that is being changed to reduce the possibility of production incident in the event that a fast fix is needed.
• Perform a scenario analysis to identify as many things as might go wrong, and ensure that there is an option to address them.
• Identify fast routes to safety and establish authority to execute them.
• Build automated systems to detect anticipated and unanticipated issues.
• If individuals are given the ability to block the route to production, they should be instantly available to address any blockage, dropping all other work until the business value is unblocked.
• If a “Go/No Go” meeting is required, run a short one regularly, once or twice a day with the option to extended its duration. Releases of business value should not wait for meetings at times convenient to the attendees.
• Prioritise the business value being delivered rather than the status of the “Go/No Go” attendees.

The “Go/No Go” is just one example of Risk Management Theatre or “Agile Kabuki” that occur in organisation with a risk averse failureship culture. Other examples include:

• Risk registers that have a “Probability” or “Chance of it happening” column.
• Risk registers that only contain one type of risk (For example “Delivery risk” but no mention of “business case risk”, or “damage to the existing model risk”.
• PMO groups that obsess about cost but do not measure outcomes (Metrics).
• Outcomes that are not measured even though significant investments are made to improve them.
• Executives that introduce governance that is ignored.
• Retrospectives that generate improvement backlog items that are never executed.
• Automated tests that are switched off when they fail.
• Organisations that ignore complaints about toxic behaviour or whistle blowers.
• People who are promoted for failing.
• Leaders who are allowed to ignore change that is being introduced.

Leaders should understand whether the risk management practices in their organisation are effective or simply risk management theatre.