Category Archives: People and Systems

Getting the Finger Pointing Right. How to fix tech problems under pressure.

These ideas and suggestions are from my experience with IT incidents solving problems with complicated and interdependent systems. In most cases accurate, timely and safe finger pointing was the key to getting the problem sorted. There are a few thing that need to be in place before this can happen. I’ll cover what I’ve learned fixing issues with colleagues.

I’ll cover

  • some ideas for solutions to the problems we have working together
  • issues with experts and non experts
  •  a framework for a team to solve problems under pressure
  • a way to share and collaborate across knowledge silos

 

IT problems with complicated Systems

Hard to fix problems are usually the ones no-one expected. Problems we expect have planned and tested responses. Often we design them out. The problems that are left have fell down the gaps in our shared knowledge.

The way we build things

The way we build things can make them hard to fix.

For example, if there are three specialist teams building your application, you’ll get an application with three parts. You may design it this way, or you may get a mirror of whatever your organization structure is. This Conway’s Law in Action.

Due to Conway’s Law, the architecture of your IT system may be decided by the division of work between teams, due to knowledge silos or desire for clarity of management structure, rather than optimizing running the finished system.

Solutions to problems are often where two knowledge silos meet and the silo locations were there before any code was written.

Hey! We need silos!

We can say that knowledge silos are bad. We need to get rid of them. The frustration with some forms of silo behaviour is understandable. For complicated systems, knowledge silos are inevitable. No one can know how everything works. Unfortunately Fixing Silos by bridging them, or breaking them down them creates more problems. The bridges and new structures become the new problem sites. It’s inevitable we’re going to have silos where deep technical expertise is required. The best we can do choose where these silos are, why they exist and how we manage the boundaries.

Who is in the room

Things have gone wrong, and people are in a room looking for a solution. Some are Subject Matter Experts, others may be responsible for teams involved, for communication or as customer advocates. There is likely to be senior management who is being asked by the CIO how long until it’s fixed.

To fix the problem quickly, the composition of people in the room is vital. You need the people who designed the system, configured it, wrote the tests and those who run it. There may be knowledge silos across teams here.

You also need someone who understands the big picture but not the details. This role is vital to ask fresh and simple question that experts may not see.

You also need someone to get extra resources you’ll need, book rooms, write communications, and document the decisions that were made, and approve changes that are made to mitigate and investigate the problem.

More Silo Dangers

In a high pressure situation, a lack of psychological safety makes people avoid suggesting diagnosis if they risk their opinion and their past work being judged.

Even where safety exists in a team, it may not exist between silos.
It may be career limiting in an organization to be seen to be the cause of an issue where learning is not valued.

Under pressure people gravitate to general, rather than technical skills (http://bit.ly/AllspawThesis), and under pressure we may defend our silo territory before looking to solve the issue.

Group Problem Solving Anti Pattern #1 Beginner > Expert

from @swardley

The more you know about something, the more you know you don’t know. Simon Wardley joked about this and seemed to hit on some visceral truth. There seems to be more than a shred of truth in this, as beginners are often more certain than experts.
People like to save face. Without work, cross silo meetings are not a safe spaces, being wrong is bad, being responsible for the system at fault may be worse.

Group Problem Solving Anti Patterns #2 – Hippos

Perhaps someone senior (the Hippo, Highest Paid Person in the rOom) has heard about X. That’s what they heard broke last time. They’d really like you check that right now. Maybe the person responsible for X puts forward a strong case why it definitely isn’t X. The defense works but the barriers are now up, and there is a round of finger pointing until someone risks losing an eye.
Worse, someone technical, knowledgeable and dilligent may reply “well I suppose it could be X” (see Anti Pattern 1). And a group goes off to look at X. (Pro tip : It’s probably not X).

Group Problem Solving Anti Pattern #3 Experts are also not enough

A Bongard Problem. What is the difference between all the images on the left, and all the images on the right? This sort of problem has all the information you need. You’re looking for patterns.

Experts are rarely enough if the incident was caused by something unexpected. Experts know what to expect and what they have seen before. The problems of being an expert in an open system, where something new has gone wrong has been covered in my post about Bongard Problems. These problems, where you have two sets of information – before and after – are very similar to IT problems. You’ve got two situations, and you’re looking for the difference that makes a difference. If you’re pattern matching things you’ve seen before, and you’re the expert so you’re not expected to be wrong, new problems can be hard to find.

Someone is required who can ask questions and doesn’t let what they already think they know get in the way. Someone who doesn’t have expert knowledge will find this easiest.

We need a facilitated solution

Someone in the room needs to step up and facilitate the group. It may be that everyone takes one step back and you end up being in charge.

Whoever facilitates need to make sure there is

An Incident framework to follow

What should we do, who should do it, what we do next. This is what goes in the ITIL service management box ‘fix the broken thing’. Ideally there is someone who books room, arranges test areas and gets any hardware or software required for the team fixing the problem.

A example P1 incident process to follow. This can be improved.

A overall End to End systems map

Very Simple Mind Map of a Client Server Application. The detail is hidden, and would go left to right. Top to bottom goes from the client to datacenter, and into the components.

This is not the architecture model, or a solution design. Those won’t do what we want.
The purpose of this map is to help solve problems, so it’s different from the documents produced in architecture and design. It’s owned by the DevOps or IT Operations & Development teams. It is a map of how all the bits fit together in a journey to get your users needs met. You can point at it, and everyone one in the room knows what your talking about. It allows fora shared mental model.

The key to the map, is that everyone agrees that it is correct, and it’s changed to reflect any new information with information being added to the map in the correct place. When people talk about the problem they can point to the map to show the area they are talking about. This can save a load of time and misunderstanding. It also mean that large areas can be ruled out, meaning that Anti Pattern #2 can be avoided.

We can then ask better questions, and make better decisions as we’re talking about the same thing.

We’re pointing at this map, not at each other! We ask questions about the map, everyone has a shared model of the system. We make better decisions.

This map was used to pinpoint a very hard to find problem that would occur for users about once every few day of constant use – and would “fix itself” after less than 5 mins.

 

Observe, Orient, Decide, Act

“What we do next” to find the solution can be answered by John Boyd. OODA, the US Military Engagement Strategy for complex fast changing situations is also great for approaching IT problems.

For other problem solving methodologies see Brendan Greggs excellent site.

OODA is a fast decision making loop. If you need to have an Emergency Change Approval Board before each Act, decide who’s on this and make it happen quickly if you want things fixed. This is a feedback loop that can run really quickly. Have the right people in place.

Observe

What do we know? What is instrumented? Is there information from users? How much do we trust the data? This information will have been collected and added to your map. Show what information we know where.

Orient

As an Incident Team, discuss what does this data mean? Where does it suggest the problem may be? What do we now know, and with what certainty?
You’ve probably just run and test, and you should already know what the results mean, but it’s likely you also have new data from other sources too.

Decide

Decide what test to run next. Everyone needs to agree what the potential results of the test means. Ideally the next test will rule out the largest part of the End to End map possible.

Using the End to End diagram, understand what the data may be suggesting. When evaluating proposed actions as “What is ruled out if the results are X, what is rules out if the result are Y”. Ideally you’ll design tests that give X or Y.

You need to decide as a Team what the results mean before the test is done. What the results mean should be visible on the End to End diagram. For example a test should allow you to rule out parts of the system.

Every test goes through this. So if the Highest Paid Person in the rOom thinks you should find what is being tested on the End to end diagram, and the things that can be learned from the results are discusses.

Act

Run and document the test and results.

Where do the fingers point now?

Instead of pointing fingers at each other, the Incident Resolution Team are pointing fingers at the End to End Diagram, and asking questions like “what would reconfiguring this tell us” or “We could replace this component to rule out all of this part of the diagram”.

New ideas can be quickly evaluated, and extra detail is quick and easy to add where it is required.

We can ask better questions and make better decisions. When we are asked why, we can point at a map, rather than a person. That’s got to be better.

Clean Interviewing at Work

Photo by Alex on Unsplash

At work, I need to talk to people at work to understand their perspectives on how the organization functions. A large University is similar to a small town. We have lots of buildings and green space, a lake, car parks roads and buildings. And security guards. And lots of people trying to achieve their goals in different ways. We’ve campuses in the UK and Asia too, links to a large teaching hospital and our own Arts Theatre. We’re complex.

I’m collecting information for User Journeys for people working, studying teaching and researching. If we help these people reach their goals, the University reaches it’s goals too. We’re structurally coupled to their success. The success of students, staff, and faculty is the success of the University.

An example of a user journey is below. We can see how someone experiences traveling with Lego.

To collect information I’m talking to people using ideas from Clean Interviewing. My goal is to find out what people think using their own words. I’d like them to see the maps I build and recognize their journeys. By accurately reflecting their perspective I hope that they’ll advocate for the use of the maps.

In almost all aspects the conversations I have are normal. I’d not expect the person I’m talking to notice anything unusual. There really isn’t anything weird or unusual. Apart from the questions are usually of the following form, and use the exact words used. I don’t paraphrase.

A selection of the questions I use are:

  • What needs to happen here?
  • What is it called?
  • Is there anything else about <that>?
  • What happens before <that>?
  • Is there anything else that needs to be here, but isn’t?
  • What happens next?
  • Overall, is there anything missing?

What I’m doing is using a framework to develop a model of what things are, what they are called, and what needs to happen before and afterward. It’s a normal conversation, and every part doesn’t follow these rules. If there is something I’d need to find out, I’ll use a clean question.

These are really simple questions suitable for situations where I could assume that I knew what the words used meant, and what happened was the same as the other interviews I’d done. By removing the assumptions I believe I get better information.

Clean Interviewing is based on the work of David Grove, modeled by James Lawley and Penny Tomkins.  More details, including use in academic research settings, are on the Wikipedia entry. This blog post shows a very simple use of Clean Language Interviewing.

To learn more about Clean Interviewing there are events on https://cleanlearning.co.uk/events

Why would I care about Mikhail Bongard’s problems?

TL;DR It’s hard to solve problems that are open, experts won’t help, filter bubbles, why does it matter if you are angry reading all this, double loop learning Clean Feedback and anti-fragility.

Thanks to Chris Cupit, Tomasz Glazer and Richard Harris for the discussions around this topic, and to Andrew J. Baker for feedback and pointers.

What are Mikhail Bongards problems, and why should I even care?

Quick Overview

Mikhail Bongard invented a type of puzzle called a Bongard Problem. These problems are interesting because you get to see all the answers. You need to work out the question. Bongard problems have two sets of six images. The solution to the problem is the explanation of the difference between the two.

Concave vs Convex edges

These inductive reasoning problems help us understand how we think in the real world. The book Goedel Escher Bach provides a methodology for solving Bongard problems, with a slant towards using Artifical Intelligence. At first the AI community thought these problems would a straightforward path to implementing AI. They’re not. And they’re much simpler than the other two examples of real-world Bongard Problems I’ll use.

This post discusses how these problems can be seen in the real world, and how they are connected to learning, and our approach to life.

How to Solve Bongard Problems

An example of Hofstadter’s methodology from Goedel Esher Bach is below. Note that this methodology is wrong for the problem that is being solved. I’ll call Goedel Esher Bach GEB from now on.

 

The method involves having a vocabulary for the domain, and an understanding what Gregory Bateson calls “the difference that makes a difference”.

Ninety-Nine Problems

Mikhail Bongards book Pattern Matching has one hundred problems. Solving these we can keep adding to the “difference that makes a difference”. We can build a list of all the heuristics we need, becoming an expert in this set of Bongard Problems.

When this list exists we have a vocabulary that gives two different approaches available to someone new to the problems.

Approach One, an open problem

This first approach is when you don’t know what the potential rules are. For example, you don’t if there is a rule that “If the pictures were physical and upright, their center of gravity would make them unstable”.

If you don’t know what the potential rules are, the potential number of solutions is unlimited, and you’re going to invent some potential solutions that are not used. So you could make new never been seen Bongard problems from these guesses.

How may these problems be seen by an expert in the original 100 problems?

Approach Two, you know the rules

The second approach is solving the same set of problems, but you have the language of all the solutions. This doesn’t make the problems trivial, but it’s a different type of problem. You have expert knowledge in the domain, and you’re doing pattern matching. You can combine patterns, but you might not be looking for new ones.

The difference that makes a difference

I’ll use a distinction between knowing all the solutions in advance, and not know them in the following three examples. I’ll then add the extra case where you think you know all the answers, but there may be other answers. Or put another way, you have a consistent explanation for how the world around your problem works.

I’ll use three examples

  • Playing the tabletop game Zendo
  • Understanding Organizational Strategy
  • Investigating unlawful credit card harvesting from your website

Example 1: Zendo

Zendo is a board game based on Bongard problems, using inductive logic. It used 3 shapes in three colours, and the idea is that a particular configuration of coloured shapes is given on a card, and players need to create structures that follow the rule on the card, and then win by correctly guessing the rule. So the Bongard problem is a configuration of shapes that is correct, and one that is wrong. You get to offer new configurations and see if they match the pattern that is the difference that matters between the two shapes.

Example 2: Organizational Strategy

Consider the case when a company makes some strategic actions. What is their new strategy? How has it changed? There will be some visible action, so one half of your Bongard Problem is the organization running one strategy, the other is the organization with the current strategy.
If you can figure out their change of strategy you can react to it with your own. If you fail to understand their strategy or carry on regardless you may go out of business.

Examples 3: Computer Crime

In this article, David Gilbertson describes how he’s hidden some code to harvest credit card details in a website that the reader may either own or use. Many website use frameworks that have a load of code imported into the pages. The data theft is viable.

In this example one half of the Bongard problem is your unhacked site, the other is a potentially hacked version. The Bongard problem is to prove that there is a difference. i.e. You’ve been hacked.

Example 1: What happens when I play Zendo with the kids

When I first played Zendo with the family I chose not to look at the cards describing the patterns that we could look for, and I didn’t show the family. We started from scratch and didn’t have a vocabulary.

It was very frustrating to play, and we made some crazy guesses.

The vocabulary on the cards includes orientation, colour, number, and layout. Doorstop, cheesecake, and tower were in the solution vocabulary.

Cheesecake, Doorstop, and vertical orientation.

We could now attempt the easy questions. Having a vocabulary is a required part of solving the problem in GEB.

When my son decided to choose a medium difficulty question we started with the usual guesses, but when we didn’t seem to be getting close we started to get agitated. We didn’t know the rules of the problem domain. More precisely, we didn’t have the vocabulary for the potential patterns. The temptation to ask for a clue or to give up was huge, because this was a game, and games are supposed to be fun. We did, however, have loads of crazy guesses that were not on the game cards. Failure is frustrating, especially if you are not expecting it.

Zendo with work colleagues

I then played the game with the Systems Thinking group where I work. I didn’t give my colleagues any information about the vocabulary or patterns. They were quickly able to create new patterns that matched the rule but couldn’t describe the exact rule that was written on the card I was using.

“The yellow wedge is in the cheesecake orientation” said Francis

The problem they had was there were two potential orientations for one of the pieces but without knowing this it was not a difference they noticed. As the photo above shows, the wedge shape can be in the ‘cheesecake’ or ‘doorstop’ orientation. If we’d read the instructions this would have been obvious. If we don’t have a name for something we have a hard time spotting it. Even if it is the difference that makes a difference.

After this game, without looking at the potential Bongard problems Tomasz helpfully created a problem that wasn’t on any of the cards. He put together some clear blue and yellow pieces. His pattern rule was “structures that can look green”. He’d created a new type of problem, unconstrained by rules. (EDIT : Tomasz was unconstrained by ‘being an expert’)

Structures that look ‘green’, Tomasz Glazer.

How might an experienced player who is familiar with all the vocabulary and patterns on the cards go about solving this problem?

Example Two: Strategy

In business, our competitors’ strategies are unknown to us. They may be easy to spot, or they may confound us.(explained in Patterns of Strategy). There are examples of strategies on the web, that suggest a more complete list exists (here is a great list of Strategic Gameplay from Simon Wardley).

By Simon Wardley
@swardley

 

 

 

 

I’m not familiar with all the strategies listed above, but I can recognize a few of them in the wild.

We are unlikely to get a clue from our competitors, but we can ‘give up’ and have a strategy of just carrying on what we’re doing, head in the sand. We think our strategy is fine.
We know there are more strategic possibilities out there. It’s not clear to me if there is a definitive list of strategies available that is considered complete.

Is a new strategy possible? I think it should be. Does knowing all previous strategies help? I’m not sure. Is it possible to think up new strategies that are not covered by known ones? I don’t know enough to know. Is strategy an open or closed problem?

Example Three: Fighting Computer Crime

After describing how he would insert code to harvest credit card details on websites, David Gilbertson goes through the ways that the reader, who is likely to be knowledgeable on computer security, would use to discover the exploit code. These ways are the patterns and vocabulary to solve the problem.

David then systematically shows how each of our ways of finding the code is flawed and sows enough doubt that we may not find his code.

We thought we had a full set of tools, but it’s clear we don’t. We can’t choose whether to learn our knowledge is flawed, it’s forced upon us. It’s a painful read, and it probably makes people angry enough to prove him wrong!

What’s just happened?

Thanks to Andrew J Barker (@ajbkr) from Tech Nottingham Slack for pointing me in this direction, but any mistakes here are mine.
What is happening when we face an open inductive logic puzzle and we don’t know the full range of answers? I’d suggest that we’re not just learning the answer, but we are double loop learning (see wikipedia, by Chris Aygryis). Our current problem-solving skills are not enough. We’re recognizing this and by getting some new tools.

Double loop learning is not just realizing there is something to learn, like a new computer language, or musical instrument, and learning it. Double loop learning is finding that your old tools don’t work on the problem you’re facing, maybe never really did. Your old thinking probably got you into the mess you’re in. You need to make a fundamental change to the way you think, and can’t go back.

There is often an unavoidable event that triggers this sort of learning. Maybe your business fails, and you see how it was obvious there were problems if only you’d seen them. Or credit card details are stolen from your website. You can’t say it was someone else’s fault. Maybe your partner leaves you unexpectedly, and once you see the reason you kick yourself for not seeing it.

Once you’ve learned something like this, it’s hard to even imagine what it would be like not to know. The past is another country.

I think this sort of unavoidable situation that can’t be explained by your current knowledge is often the catalyst for double loop learning. But our brains don’t like the cognitive dissonance. They would rather explain events any other way.

This is why we get angry when playing Bongard games when we don’t know the range of answers, and why many companies strategy is to keep doing the same thing.

Anti Fragile People

Some event that could break a fragile version of ‘us’, or be endured by a robust ‘us’ actually makes us stronger when we learn from it.

The event needs to be capable of hurting us – or making us angry enough to put up defences.

So what is stopping us getting over the double loop learning wall and being Anti Fragile? And what can help us over the wall?

Single loop learning feels so much nicer than double loop learning. Double loop Learning required we get past the cognitive bias that says we have a consistent explanation for how the bits of the world we care about works.

What’s stopping us?

We’re stopping ourselves.

What can help us?

Unavoidable feedback from hard failures can make us stronger. The feedback can also be endured or can break us. Exposure to the thinking that comes from hard failure makes us uncomfortable.

In many circumstances, feedback structured in a way that helps us develop, by making it hard for us to ignore. The best example of this is Clean Feedback, by Caitlin Walker.
That’s another post.

Really, what’s stopping us?

There is a useful (but ultimately wrong) model of how our brains work, called the Triune Brain. This suggests that there are 3 areas, or thinking states that we use. The lowest brain is the Reptilian brain. This is the fight, flight or freeze response. Knowing we are physically safe keeps this brain quiet. Feeling unsafe activates this brain. A fight also can mean get angry…

If our Reptilian Brain is happy we can use the Mammalian Brain. This brain has higher functions and is kept happy by knowing the rules. This can be social rules, like where the loos are, if you can just go and get a drink, and what time lunch is. Not knowing the rules puts you in the Mammalian brain.

If you’re safe, and you know the rules, then you can use the Neo-Cortex, or learning brain. I’m going to suggests that this is more accurately called the Single Loop Learning Brain. You can learn a new Language, or how to use your current skills better. It’s mostly saying “Don’t worry, you know the answers. No dissonance here.

To put all this together

Example 1: Zendo

We’re playing a game. It’s supposed to be fun. But if we only know a few of the possible answers. We don’t know the rules. We’re in the Mammalian brain. We’re not happy. It’s not terrible, but it’s not exactly fun either. We want to be in our Neo Cortex, getting the answers right. Being an expert.

Before we play again we look at all the cards with the answers on. The game is now to remember these and pick the right one. You can do this, we’re an expert. It’s now more fun, but we’ve limited our creativity.

Example 2: Strategy

With our full list of potential strategies, we’re working in our neo-cortex. An expert doing pattern matching.
Is a complete list a barrier to your brain double loop leaning? During analysis do we come up with new strategies that are likely to be wrong in the particular example, or do we match what we know?

A Strategy Expert, yesterday.

Are strategy consultants experts? How would they see a brand new strategy if it presented itself?

Example 3 Credit Card Harvesting

This article is delicious. David sets up the reader with a situation that’s hard to dismiss out of hand. It’s a challenge to the expert. He then uses the experts’ heuristics and shows how they are wrong. I imagine there may be a few angry readers.

Has this article about double loop learning offered any specific examples of double loop learning to the readers? Will it change anyone’s mind? Does it make people angry? Why is this article wrong?

So what?

To wrap all this up

  • There are open and closed problems
  • These can be played using Zendo, and the differences can be seen
  • Being an expert has some potentially negative consequences
  • Knowing the language to describe your problem could mean you miss things you don’t have a name for
  • Is this a difference described by being an engineer, and a scientist?
  • Unless using something like Clean Feedback, you need to be uncomfortable to experience double loop learning – learning that challenges your current way of doing things.
  • If you avoid discomfort you’re unlikely to learn how to act in the world better
  • What else can we do to learn about our understanding of the world?
    • A colleague suggested Drugs…
  • Talking to people we disagree with and understanding how they are cognitively consistent (or right…). I guess this can also be combined with the drugs 😉
  • What does this mean for our facebook and twitter filter bubble?
    • When someone makes us angry is it a chance to learn?
    • Or do we block and unfriend?

Knowing if the problem you’re solving is likely to be open or closed is a great starting point.

So lastly there are the Strategy problems I mentioned. Are they an open problem where new strategies are being thought up, or a closed one where they are all in a big book of experts strategy?

This may be a good direction to look in the future.

The Problems of Mikhail Bongard

"The Men in the Moon: or, the 'Devil to pay.' With thirteen cuts [by George Cruikshank], etc. [A satirical poem-chiefly in reference to the proceedings of Messrs Cobbett, Hunt, and others.]"

This post is thinking in progress. I’d love feedback.

 

 

 

How we are educated to become problem solvers

We learn problem-solving by looking at problems that have solutions. This is how our success at problem-solving is measured in school. If we’re lucky we can look in the back of the textbook for the answers, and figure out how to work towards them. This cuts problems in half, like starting to dig a tunnel at each end and hoping to meet in the middle. Starting from a question and an answer we’re simply filling in a method to get between the two. If we do well at this we call ourselves ‘problem solvers’ on our CV..

What are Bongard problems?

Mikhail Bongard invented visual pattern matching problems that reverse the normal style of the problem to be solved. We usually have a question and the answer needs to be found.

Bongard problems give you the answers, and you need to figure out “what’s the question here?”, “What’s happening?”.

From Wikipedia

The idea of a Bongard problem is to present two sets of relatively simple diagrams, say A and B. All the diagrams from set A have a common factor or attribute, which is lacking in all the diagrams of set B. The problem is to find, or to formulate, convincingly, the common factor

An example Bongard problem, the common factor of the left set being convex shapes (the right set are instead all concave).

From Godel, Escher, Bach

When looking at Bongard problems, we can look at the solutions to previous problems and build a list of potential answers to search through, as in the example below.

 

How did we get here, and where are we going?

Bongard problems ask – how did we get here? This is a significant difference to normal problem solving, but it gets better.
Working in a complicated domain, such as fixing problems in IT systems, we’re often asking “what needed to happen for this problem to occur”? Knowing this, fixing the issue is relatively straightforward, but not always easy. Things can still get very complicated, but it’s all potentially knowable.

Working in a complex domain (listen to Dave Snowden talk about complexity), which means any time when people are involved, what happened last time we did X may not have the same results this time.

So in complex domains,  why do we even care how we got here? I’d suggest because understanding how we got here may help us understand how the system we’re looking at is disposed to behave and because the modelling will require us to think hard about the issues (I can’t find a source for this).

How do we think hard about Bongard problems?

Bongard problems obey Occam’s Razor – “among competing hypotheses, the one with the fewest assumptions should be selected or when you have two competing theories that make exactly the same predictions, the simpler one is the better.” (https://en.wikipedia.org/wiki/Occam%27s_razor)

Douglas R Hofstadter describes a process for solving Bogard problems in the epic book Godel, Escher, Bach. (Godel, Escher, Bach: An Eternal Golden Braid, Basic Books, Inc. New York, NY, USA ©1979 p646)

Bongard problem solving would have several stages in which raw data gradually gets converted to descriptions.

  • Raw data preprocessed
  • some salient features are detected
  •  The names constitute a mini vocabulary
  •  Drawn from a salient feature vocabulary
    •  line, segment, curve, horizontal, vertical, black, white, big, small, pointy, round.
  •  Second stage of preprocessing
    •  Triangle, circle, square, indentation, protrusion, right angle, vertex, cusp, arrow

 

  • Now the picture is ‘understood’ to some extent tentative descriptions are made
    • above, below, to the right of, to the left of, inside, outside, close to, far, parallel, perpendicular, in a row, scattered, evenly spaced, irregularly spaced
    •  Numerical descriptors
  • More complicated descriptors
    •  further to the right, less close to, almost parallel to

Hofstadter introduces an idea of a “description schema” or “templates” and the idea of “Sam” – a sameness director to help to solve Bongard Problems.

This is where I am. I think it’s possible to create a useful description schema or Sam for our real-life problems, using the systems approaches I’ve written about elsewhere on this blog.

Description schemas are types of weighted directed graphs, similar to the graphs used behind online recommendation engines. I’ve got a new job involving ontologies and graphs. Thanks for Ivo (@kvistgaard ) and Julian (@julianfej ‏)for help getting started with the ideas behind linked data. More work to come here.

Know Yourself with a User Manual for You

Title: "The Adventures of Sherlock Holmes", "Single Works" Author: Doyle, Arthur Conan - Sir Shelfmark: "British Library HMNTS 012634.m.7.", "British Library HMNTS Cup.410.g.93." Page: 275 Place of Publishing: London Date of Publishing: 1892 Publisher: G. Newnes Issuance: monographic Identifier: 000977457This post uses a set of questions, called “User Manual for Me“, by Cassie Robinson. (ht Mike Watson @herdimmunity)

Cassie’s idea is that answering a set of questions about how you prefer to work and interact with people lets people can help you work together better. In an ideal world, you’d know more about people around you, and they’d know more about you.

These questions seem ideal for framing as clean interviewing questions, with following clean questions that can help the client get deeper knowledge of themselves. They can choose to share these insights with colleagues of not.

In this post I answer these questions for myself, and then suggest contextually clean following questions that could be asked.

 

Warning Required?

I’ve had a mixed reaction when talking to friends and colleagues about Cassie’s questions, which all came down to safety. If you’re in a team and everyone wants to do this it would be great. If there is anything like hostility this soft of thing in the team then it’s not something people seem happy about. If you’re in charge, don’t force this on anyone.

Warnings aside, if you’re in a good team, or want to know this to share with a few colleagues then these questions are excellent in helping others understand you.

In this post I’ve suggested contextually clean versions of the questions, and contextually clean follow ups questions to my answers.

What are Contextually Clean Questions?

Clean Interviewing is a way of asking purposeful questions that contain a minimum amount of the questioners thoughts, ideas, opinions and suggestions. These questions are contextually clean.

Clean Interviewing allows the client to express their understanding with the minimum influence from the questioner, and can lead to unexpected insights.

More information is on the Clean Language Wikipedia page which has been recently updated by James Lawley.

The contextually clean versions of the questions pretty much wrote themselves. Cassie’s heading were pretty clean already. I’ve added some contextually clean follow-up questions to my own answers in green, as an example of how the User Manual questions could be followed up with contextually clean questions.

By Cassie Robinson

My Answers and some potential follow-up questions

Contextually Clean follow-up questions in green.

Conditions I like to work in.

(Contextually Clean Question: What are the conditions you like to work in?)

I need variety. I get ideas by talking to people and hearing their ideas and perspectives. The conversations don’t need to start with the goal of having an idea. I like face to face interaction.

Is there anything else about the ideas from face to face interaction?

If I’m reading detailed information, or doing technical problem solving then I work best alone, but I need to get feedback on my work if I’m not making progress. I can stubbornly bang my head against a problem for far too long. It’s effective, but perhaps not always efficient.

(There is already a contextually clean question about feedback later.)

I need to read and annotate paper copies. I don’t read or understand well off a screen. Sorry trees.

I move around to get unstuck, or if I’ve got something to think about. I work well on the move.

Are some ways of moving better than others?

Is there anything else about getting unstuck?

The times/hours I like to work

(Contextually Clean Question: What are the times and hours you like to work?)

I start thinking early, when I wake up. I re-run what I learned the day before, and plan for the day before getting out of bed. Cycling to work is time when I work through problems, so I arrive primed. I then really like to make progress. Meetings and major task switching here can really stop progress for the day.

What happens when you re-run what you learned the day before?

Is there anything else that needs to happen before you’re primed?

After lunch I’m better at discussing ideas and meetings, unless I already shared the ideas I had in the morning. Mid afternoon I get a second window to work well on technical problems.

Is there anything that needs to happen before the second window to work on technical problems.

I read and write well in the mornings and evening, from 9.30 till about 11.15pm.

If something is difficult and interesting enough I’ll be mentally working on it all the time…

What makes something interesting enough for you to be mentally working on it all the time?

The best way to communicate with me

(Contextually Clean Question: What way of communication is best for you?)

I like communication to be in person, followed by a written overview of any actions I have. I work best if I understand your purpose, and goals. I’ll figure out the best way I can help you reach them.

How do you like someone to express their purpose and goals?

How would you figure out the best way to help?

I’ll also tell you if I can’t make sense of your purpose and goals. I’m good at juggling multiple perspectives, so I like these perspectives to be in the open.

The ways I like to receive feedback

(Contextually Clean Question: How do you like to receive feedback?)

I like feedback to be quick, and to include context. Face to face feedback is best, as I can misunderstand written feedback easily.

I like feedback to focus on what I did, and ideally to  suggest areas for improvement, without being prescriptive. I’m continually increasing my understanding of how I work and learn. I need feedback for this.

Things I need

(Contextually Clean Question: What do you need to be at your best?)

I need to understand purpose. I’m not the best at following a process, without understanding why. I may need someone to listen if I have an idea for improving a process too. That’s what I’m good at.

Where do your ideas for improving a process come from?

I need to be trust to do the right thing. I sometimes express an idea that doesn’t seem to follow from the facts. I need people to ask me to fill in the gaps in my thinking and explanation.

Where do the ‘gaps’ in your thinking and explanation come from?

I need something to be curious about.

What’s that curiosity like?

I need reminders for things I may have forgotten, and for people to ask how it’s going.

Things I struggle with

(Contextually Clean Question: What do you find difficult? I think the difficult is cleaner than struggle..)

I struggle following a process, and using ‘we just followed the process’ as an excuse when we knew there were problems.

When following a process, what would you like to have happen?

I struggle with making sense of dense text when a diagram would work better. I may miss an important point if it’s hidden in lots of unimportant text.

My short term memory is almost non existent. it’s not a reflection on my intelligence.

Things I love

(Contextually Clean Question: What things do you love?)

I love

  • a challenge
  • designing and building things that other people find useful
  • learning and making useful connections between ideas
  • The ‘aha’ moment when something clicks
  • bullet points
  • helping people with the things above, and solving their problems

What happens before you build something people find useful?

Other things to know about me

(What would you like people to know about you?)

I need to draw something to explain it to you. Even if there is a perfectly good drawing in front of me, I need to draw it again while talking.

I like ideas. I can sometimes be a bit enthusiastic. I like to talk.

I can often quickly analyse a situation, and figure out a course of action, or the events that led up it. I can think this much quicker than I can articulate why. I quickly model situations, and run accurate scenarios against them.

Extra Question Suggestion

How I learn things

(Contextually Clean Questions: How do you learn things?)

I learn things best when they extend something I already know. It’s like a need a hook to hang new information on. I also need to learn the principles, context, and any constraints to the information or tools I’m using. When I learn things I’ll remember them by understanding the principles and context, rather than the facts and process.

How do you get hooks to hang new information on?

I’ll learn something new by relating it to the information I already have, and any similarity of context, patterns or constraints.

 

I hope to ask these questions with friends and colleagues soon.  Know Yourself is a popular phrase in philosophy and I think Cassie’s questions, followed up with Clean Interviewing questions is a great way to start knowing.

 

Northern Clean: 2017

There was a lot happening at “A Northern Taste of Clean”. This is what I learned:

I build models to feel in control. This means  I sometimes need to stop building models and get into the real world, and this may feel hard.

I’ve found a path, and I’m following it. I don’t know the destination, and that’s fine, since I trust myself to make good decisions where to go next. I also have great friends who help me.

What I do to find new things to learn is different from what I need to do to learn them. I need to develop a machine like process for learning specific things. This will stop me ‘spinning my wheels’ when I should be getting on with things.

My tapping foot is telling me I need to move to have ideas. I work best on the move, or when I am ‘somewhere’. (I did 3hrs reading/writing on the train home…)

I need to know when I’m on the Drama Triangle, were other people are, and understand what I can do.

I build models feel in control, and compensate for my lack of short term memory. I can feel really out of control when I don’t have an understanding of what is going on. (So I should get to places /events early,  have phone numbers / directions sorted, get written timetables.)

Learning and teaching Clean Language and Modelling enables anti-fragility.  Learning to model means you can grow, understand your patterns, be anti-fragile.

You can’t have outcomes faster than the speed of trust.

You may have multiple allegiances or reasons for questioning. Know why you are asking each question.

I make expensive decisions sometimes because for me, the alternative is to do nothing, not to plan how to do things cheaper.

I’ve got power and control, it can be used, and wasted.

I’m a novice at this.

The clean community are lovely. I’m happy to be a part. Thanks to everyone who made Northern Clean possible.

Thanks to David Grove for creating something amazing.

DevOps in a Nutshell. Treating Machines like machines and people like people.

Serviced by @buildcycleworks

A google search finds few posts called DevOps in a Nutshell. As far as I am aware this may be the only one that mentions nutshells and how metaphors can help us understand DevOps.

I’m going to use nutshells to start a conversation about how the language we use can affect how we think about how best to organise. Our hidden metaphorical understanding of how things work also informs how we think, limiting the ideas we have and bypassing our conscious thought and critical thinking.

 

The first way of DevOps is systems thinking, and the performance of the entire system. The entire system contains people and machines. The dominant organisation metaphor in use is machine based. I’ll show others, and how they help the DevOps First Way, and understanding the entire system.

Treating Machines like People and People like Machines

Before DevOps we treated machines like people – there was really no other way. They needed to be installed manually (pre Jumpstart and FAI, old people), it took about 9 months and when you’d finished you had an almost living thing that you gave a name. Installs were often path dependent. It mattered what order you installed things, and it was quite hard to get and keep multiple machines exactly in sync. The tools to work differently simply didn’t exist the way they do now.

There is also an old people management technique, called Scientific Management or Taylorism, after Frederick Taylor. Taylor invented and popularised scientific management at The Ford Motor Company. Taylorism took craftsmen & women (especially during WW2) and timed, measured, divided and controlled what they did until they were doing repetitive tasks on a production line, separated from the craft of what they were making.

Taylorism was popular with factory owners, much less popular with workers. Without it, we simply would not have the world of cars and technology we have today. Taylor also raised wages, so that Ford employees could afford Ford cars. It’s not all bad.

Scientific management treats people like machines.

Pre DevOps we had machines treated like people, by people treated like machines.

Now we have an abundance of approaches to treat people and computers differently.

We have automation, orchestration and monitoring tools for treating computers like machines, and the tools keep getting better.

Our approach to people is less mature. We still can often use the machine based metaphors and ideas. No one would have thought it unusual if I’d called the approaches to working with people ‘tools’. The machine metaphor goes deep.

If not machines then what?

It’s worth saying that it’s possible you may feel that people should be treated like machines. This is how Frederick Taylor saw the world and is dominant thinking in many areas.

Often I’ve found that those who feel people should be treated like machines usually mean other people. There is a difference between the thinkers and the doers.

If we think that other people should not be treated like machines, what are the alternatives? We could treat people like roads or books or gases. But I’ve not really thought these through…

Gareth Morgan wrote the seminal book Images of Organisation that contains a set of metaphors that cover most ways of treating people in our Organisations. Fortunately, he’s thought about the metaphors so I don’t have to.

Gareth Morgan’s Organisational Metaphors

Picture by Venkatesh Rao, ribbonfarm.com

Gareth Morgan’s Images of Organisation has eight metaphors; Machine, Organism, Brain, Culture, Political System, Psychic Prison, Change and Flux and Instrument of Domination.

All the metaphors can be true at the same time. Often people favour a dominant metaphor in their understanding of their organisation. This dominant metaphor may be colouring their thoughts and reaction and shaping the ideas they have. When I say their thoughts I mean our thoughts. Mine and yours.

The organisation that your DevOps team is part of will be working in ways they cannot see if they only think with one metaphor. Using a variety of lenses increases our understanding.

The metaphors shown in the diagram above are

  • Organisations as Machines
    • with a known input they should produce identical output
    • ‘well oiled’
    • People as machines are interchangeable cogs, once trained or certified
    • It’s about Input, process, output
    • We reduce variation (6 sigma)
    • A leads to B leads to C, always
  • Organisations as Brains
    • Who knows what
    • Information spreads through learning
    • Constant learning through feedback, and learning to learn
    • Management cybernetics
  • Organisations as Organisms
    • Adapting to the variety of a changing environment
    • Evolving from organisational DNA
    • Changing with a survival strategy
    • Looking for best fit with the environment
  • Organisations as Cultures
    • The way we do things here
    • What we value Systems
    • Behavioural Norms and Patterns of Behaviour
    • Dominant cultures and sub-cultures
  • Organisations as Political Systems
    • Influence
    • What’s in it for me?
    • Centres of Power
    • It’s not what you know, it’s who you know
  • Organisations as Psychic Prisons
    • Cognitive Biases
    • How else could I behave
    • We couldn’t do that here
  • Organisations as Flux and Change
    • Constant change
    • Less about boundaries
    • We’re connected and part of our environment
    • A system can’t change independently of its environment.
  • Organisations as Instruments of Domination
    • Prisons or Boarding School
    • Physical Punishment
    • Prison Industrial Complex

When using the DevOps first way to think about the whole system, the metaphors can help uncover and explain things that are happening. Viewing situation through the metaphorical lenses is revealing.

Conclusion

“In a Nutshell” not a great way to think about this topic. It suggests that “here is everything you need”, a complete explanation. When we’re working with people we need to be open to ideas and change.

I’ll use another post to discuss situations and responses through the lenses above.

Clean Scoping and Seeing Systems

instagram.com/bogdandadaOverview

In the post  ‘Listen carefully, it’s the System talking I wrote about Barry Oshry’s Seeing Systems model. This describes the conditions we are in when working with other people, and how we can choose to behave in the relationship. I called these choices balcony or basement behaviours. Barry has an excellent book too.

I recently heard Caitlin Walker describe her method of Clean Scoping at the Metaphorum 2017 conference. This is an approach to understand or scope potential work to see if a Clean Language approach is suitable and is likely to work. The rest of this post discusses how I see these two approaches adding value to each other. I recommend Caitlin’s book ‘From Contempt to Curiosity‘ for more details.


Seeing Systems

In the Seeing Systems model, if we are trying to build a relationship with someone in the CUSTOMER condition, we’d like balcony customers, rather than basement customers. As someone responsible for the overall delivery of whatever a customer needs, we can choose to act as balcony TOPS.  A quick overview is:

Balcony TOP’s want to create a systems that can meet the challenges that they face. They empower people in the system to use their unique knowledge to improve the outcomes.

Balcony CUSTOMER’s engage in the details of what they need, provide feedback on the delivery progress, suitability and timing. Reading a bit more into Barry’s work I feel balcony CUSTOMER’s also see the power they have in using and developing the solution. They are not just asking for the answer provided to them.

Clean Scoping

Clean Scoping is part of Caitlin Walkers Clean Language and Systemic Modelling ™ approach, that i feel is a practical way of seeing if the necessary balcony conditions exist. In Caitlins case Clean Scoping is used to decide if she wants to work with the client or not. If we can’t choose our customers then we may try to influence them to behave in a BALCONY way.

Using the two models together allows us to understand what we are trying to do, and have a practical guide to having the conversations.

Caitlin is explicitly trying to create a system that is able to solve the problems it is trying to face. This is done by ensuring she is working at a sufficiently high level in the organisation to make sure the changes stick, ensuring that balcony customer behaviour exists, and transferring the skills to the customer so they are self sufficient.

Customer Behaviour

At my work organisation there is a group interested in how to develop and encourage balcony CUSTOMER behaviour from CUSTOMERs we work with. Catilin looks for this behaviour in potential clients at a high level in the organisation before agreeing to work. Described in her book, ‘From Contempt to Curiosity‘ Caitlin looks to encourage this behaviour – called Quadrant 3 behaviour – at different hierarchical levels of the organisation once there’s buy in. At my work we don’t get to choose our customers.

Using Clean Scoping questions, the organisational behaviour we want to have happen are balcony TOP, Balcony BOTTOM, balcony CUSTOMER.

Clean Scoping Questions

The help achieve this organisational behaviour, Clean Scoping questions would be:

  • And what do we see and hear when <balcony behaviour>?
  • When do you naturally get the <balcony behaviour> you’re hoping to get more of?
  • What is happening at the moment?
  • What is working well?
  • What is not working well?
  • What needs to happen, so what you would like to have happen is automatic?
  • What would need to be true for people to naturally behave like this?
  • What is happening at the moment?
    • Often Uncomfortable patterns are happening. This is often the difference between what we ask of others and what we do ourselves.
    • For example when we behave as a basement TOP with heirarchy, and expect others to behave as balconies. Behaviours are coupled.
    • Acknowledge what is true is true
      • Worldviews and perspectives are important here, and metaphor models can help
    • What would need to be be true for people to naturally behave like this? – People working to their strengths and acknowledging others strengths and contribution.

Biased and basement Behaviour

Behaviour from biases ensure that the patterns from the past continue. These are often confirmation biases that form part of the coupled relations in the Seeing Systems model. The blind reflex response is precisely why the relationships are here, and not in a better place. If we expect or behave with basement behaviour from another, we’ll get it in return – especially if there is organisational hierarchy.

Why and how

This post has covered some of the how questions for the why questions in the previous “It’s the system talking” post. There is a bit more to this…

 

Listen carefully, it’s the System talking.

I’ve been interested in conversations, relationships and working together. How can we relate better at work and home. How is our behaviour affected by those around us, hierarchy, and our willingness to do emotional work – managing feelings and expressions to help a situation progress.

We often react to people  instinctively, pairing our response to their behaviour. Sometimes we choose to break a pattern of conversation, either with empathy for the other persons condition at the time, or to sabotage ourselves and the situation.

Barry Oshry has developed an incredibly useful model to discuss these situations, allowing us to see beyond the people, and to see the system talking. Of course all models are wrong , but some are useful (quote from George Box), and we’ve found Barry’s Seeing Systems model provides brilliant insights. There is a great introduction written by Barry, called Total Power Systems. Ignore the red cover and the words “total” and “power”. It’s not like that.

I worked with colleagues to develop and run workshops, asking ” could you work better with colleagues who had taken this workshop” and ” could you work better with colleagues who have not taken this workshop”. Responses are 100% positive for working better with others who have done the workshop. It seems to resonate.

Barry Oshry’s Seeing Systems Model

Barry’s Model has four conditions that we find ourselves in, in conversations and relationships

  • The conditions change regularly
  • They affect how we behave
  • They affect how others relate to us
  • The conditions are not roles, and do not imply hierarchy
  • But hierarchy is an ever preset overlay

None of the conditions is better or worse. They just are. And they are

  • Topoften overburdened and held accountable
    • Can create a system that thrives, where members are knowledgeable about the system and can use their full potential working in the system
    • When we are TOPS we often sabotage the situation by keeping responsibility to ourselves, away from others including BOTTOMS who can help
  • BottomHard done to
    • Are uniquely placed to see the problems that occur, and to identify and help correct issues
    • When we are BOTTOMS we sabotage the situation when we see problems we hold tops responsible. We don’t feedback suggestions. End of Story.
  • Middle stretched or torn 
    • Able to function as the organisations web, connecting parts and co-coordinating
    • We sabotage ourselves as MIDDLES by connecting primarily with one side or the other to the detriment  the relationship
  • Customerusually righteously screwed
    • Are in the best position to evaluate the delivery process and quality
    • We sabotage ourselves as CUSTOMERS when we hold delivery system solely responsible for delivery. We take no responsibility.

Each condition has two types of behaviour, we’ve called these balcony and basement. Balcony behaviours are positive, appropriate and “Using Yours Powers For Good”. Whereas, basement is the stuff we don’t like in others:  disruptive, argumentative, disengaged.

We move between the conditions often in conversations, and employ balcony or basement responses, usually re-actively without thinking. I’ll give examples later.

We do not act alone

The way we choose to communicate affects how people communicate with us. Hierarchy at work affects this, but we are not our role. Our unthinking reaction – called the “dance of the blind reflex” by Barry, is reinforced by  hierarchy.

  • Anyone who is responsible in a situation is a TOP in interactions
  • Anyone tasked with doing something is a BOTTOM in interactions
  • Negotiating between TOPs and BOTTOMS we are MIDDLES
  • Anyone getting something done for them is in the CUSTOMER condition

We can move between roles in the course of a conversation, meeting or day, often when walking down the corridor between conversations. The model helps us to have empathy for others in their condition. We can choose how to respond. It won’t always be easy or appropriate to respond with balcony response when we choose.


Example Situations

A tidy room.

As a parent you’d like your young child’s room tidying. You’re got hierarchy here. You can approach the conversation a number of ways.

You can tidy the room yourself. Your child is a CUSTOMER. If engaged to be a BALCONY CUSTOMER they could help, and tell you where everything goes, so all the toys are in the right place. You’re kind of both happy, but as a parent you’ve created yourself a job. If they’re not engaged, parental hierarchy may mean they don’t give you feedback, they could just wait until you’re finished, and then constantly ask where things are. If they can’t find anything, it’s your fault. Forever.

At worst, basement TOP behaviour, with hierarchy may have induced BASEMENT customer. At best it created work.

You can ask your child to tidy the room, giving instructions and guidance as the room gets tidier. You’re CUSTOMER/TOP, child is BOTTOM. They ask where things should go, and you’re there to tell them. You tell them what to keep, what to throw away and everything. They may learn after a few times to tidy the way you like it, assuming there is not too much new stuff. If anything changes they expect you to tell then what to do. Years later they may still expect to be told how to tidy their room.

By giving detailed instructions you’ve not created an autonomous system for keeping the room clean. You’ve helped  create a dependent basement BOTTOM behaviour.

As CUSTOMER/TOP you could create a system for keeping the room clean. You could encourage your child to be a BALCONY BOTTOM, by letting them tell you how the room works. What gets used the most, what they don’t like, and letting them work out how to tidy it all up, what to throw away etc. You’d need to check together  that everything looks OK, and check whats thrown out, but this feedback builds a better system, for example they learn they can’t throw out Christmas presents from Dad, no matter how uncool they are.

 


Example Holiday Advice from a Travel Agent

You want to go on holiday. Booking through an all inclusive agent you’re the CUSTOMER. You could walk in and just say “Here’s £1000. We want a family holiday where we’re all happy. Over to you. It better be good, or I’ll give you a terrible online review.” This sounds like basement CUSTOMER behaviour.

Or you could have a list of what your family like, for travel options, activities, temperature, food. You could work with the travel agent to get what you want. This may take more time, but you’ll probably get a better holiday.

From the travel agents perspective, they could behave as a basement TOP, and hold onto responsibility, or build a system that gets people the best holidays.

The travel agent may specialise in holidays for the over 50’s. When a group of young adults come in to book a wild holiday they could hold onto responsibility, and start figuring putting something together from scratch that they’re not familiar with. After all, they’re TOP and responsible. Or they could refer the group next door to the Student Travel Center. If the Student Travel Center refers groups of over 50’s back, then they’ve just created a system to get people the best holidays.

Interestingly, once on holiday, the agent is often a MIDDLE. Customers may complain about the standard of the food and accommodation. Hotels may complain about the lager louts that the travel agency send to the hotel, and the Travel agent is torn between the needs of both. Basement behaviour of reflexively siding with one or the other may not be good long term business sense. Balcony behaviour is a balance.

 


Example of Chief X Officer, working at boardroom level

A CxO is not always a TOP, despite being far up a companies hierarchical structure. For example the part of the organisation the CxO heads will provide service to the rest of the organisation. In meetings with the rest of the organisation, there could be two strategies.

When in meetings responsible for the delivery of their part of the organisation, a CxO would be BOTTOM. They need to deliver, and there is a choice of BALCONY or BASEMENT BOTTOM behaviour, that would have a different strategic outcome.

They can just do as they are told, and hold the next level up to be responsible for the outcome. This behaviour may be induced to be reflexive.

Or they may accept they are in the best place to recognise, diagnose, and get the resources to tackle the issues and work to rectify them using the knowledge and insights they have. If they are allowed. This behaviour is coupled with those in the TOP condition.

The CxO would soon leave the BOTTOM condition when making things happen, but may regularly be MIDDLE or CUSTOMER as well as TOP.


Example of calls to IT Service Desk

IT service desks staff receive calls from CUSTOMERS who often need things fixing. In the initial discussion they are TOPS responsible to the CUSTOMER. They can encourage BALCONY customer behavior where the CUSTOMER helps get their problem fixed, by providing information, feeding back on progress and being involved in the solution where required.

The service desk staff, in the TOP condition can hold responsibility for fixing the issue to themselves, when they need to involve others in the resolution. Involving others may involve moving into the MIDDLE condition to talk to others to get the problematic situation fixed, and be between the CUSTOMER, and the new BOTTOM.

The situation gets interesting if it turns out a 3rd party is involved. After being involved in a complicated problem, isn’t it just great when you can give the lot to someone else and say ‘you just fix this’. We’re in the basement CUSTOMER role here holding the 3rd party to be responsible, end of story. We’d act as MIDDLES between the Service Desk customer and the 3rd party. This is understandable, but maybe not helpful for getting the real customers problems fixed.

Silo Working

The above Service Desk shows an extreme example of Silo working – When we pass things between organisation silos we’re in the CUSTOMER condition, and it’s easy to fall into the basement. It’s often expected to behave as a basement CUSTOMER and hold the delivery system totally responsible. Helping them is not a good use of our limited time.

However we’ve all worked closely with others, times when we’ve temporarily removed barriers and worked together, as balcony CUSTOMERS, working with balcony TOPS, MIDDLES and BOTTOMS. It’s how we get important things done.


This is the goal of Barry Oshrys lifetime work, to help people understand how they relate to each other, and how their reactions can be conscious choices to work in a way that has the potential to induce positive behaviour in the people they are working with.

When we talk to other we should listen carefully, it’s often the system talking.


What can this help us with? When we hear “culture must come from the top”, we can understand “top” to mean hierarchy. ANY of the conditions that people at the hierarchical top of an organisation find themselves in, will be the basis of induced behaviour – effectively setting culture.

In this sense culture does come from the top. HOWEVER, if we apply Barry’s model to itself we find that if someone in the TOP condition and top in the hierarchy sets a direction, and “has the answer” then they may induce the basement BOTTOM behaviour of “I’ll just do what you say – and you’re responsible for the results.”

Any cultural change ideas, applied from the top/TOP down in a basement way are not likely to produce the desired change.

This induced behaviour has echos in the Theory X / Theory Y management styles. Barry Oshry’s work shows how we may induce Theory X behaviour reflexively when we may be wanting to develop relationships and create systems that utilise the resources and intelligence of the people in the system.

Systems Thinkers need a Posse

 

obeyAndre the Giant has a posse. Public Enemy have the S1Ws. Radicals throughout history had a crew, an entourage, a crew. The Misfit Economy by Alexa Clay and Kyra Maya Phillips details types of people who did things differently, from pirates to gangsters and hackers. And they all had a posse.

It’s hard to stand on your own, against the grain. People carry hammers to knock in any nails that dare to stick up. Sometime this is just a put down, a career blip. Maybe what you say means you can’t walk the streets without watching your back.

Clay and Phillips don’t mention systems thinkers in their book, but they are out there, from a voice in a dysfunctional organisation, to revealing the structural racism inherent in a dysfunctional society.

Some run towards the danger, up for a fight. Others see the danger and wait or give up. Seeing systems can be a hard, lonely place full of compromise and disillusionment. We need friendly people to talk to, who have been there, who can see the patterns that may be too close for us to focus on.

For a group who are arguably all about they way things connect, the systems community are a fractured bunch. Academia values novel research. Just connecting other people works doesn’t carry much weight. What should be a strong backbone of theory is a silo factory. Consultancy is as bad. There are people who attack others work as a way of promoting their own. Of course they need to pay the rent. The problem is structural as much as human.

We need a community, for support when it goes wrong, to build ideas, to talk, laugh and develop. Ideas are free, but alone I’m useless. I need to talk, how else do I know what I think? And sharing means more ideas, not spending my time defending what I have. We need safe spaces to think, grow and change. Safe from attack and ridicule, and safe from being used as a step to make someone feel taller.

What would a systems thinking community value, and how would our current interactions compare to an ideal that we can all theorize about, but we sometimes work to destroy.

Are we too fractured to have an identity?