main | about us | download | faq | readings | blogs | support | tutorial | *

Let’s look at the situation

© Donald V. Steward 2005

In the past a boss could usually tell a subordinate not only what to do but also how to do it. Today it is likely that it’s not the boss, but the subordinate who knows better how to do it. This has upset our old notions of command and control and led us to look at how these people with greater knowledge can be empowered to use it in the interest of the organization and how groups can be more self-governing. We have received a great deal of advice from leading lights as to how to make this transition. But much of this advice, which was initially highly hyped, eventually flamed out. Why?

I would like to suggest that all this advice has still not addressed a vital issue that is necessary to make these proposals all work properly so they bear the fruits that have been promised. That issue is: How are empowered people to be directed and made accountable so their contributions are aligned with the goals of the organization?

I wish to suggest that the solution lies in ‘situation visibility’. When there is situation is visible, with very little guidance, people can see what they need to do and be held accountable by their peers for doing it. It would hardly be worth looking at the issue of situation visibility if it were not possible to use this concept to bring about constructive changes in management. But in addressing this problem we will have to overcome some barriers that existed in our earlier thinking that caused us to miss this point.

There are many examples of companies using teams that to some extent are self managing in order to solve particular problems. They blossom here and they blossom there, but they don’t yet form a garden. They still operate as small islands immersed in a hierarchy.

To make my point, let me start with a few stories.

Two brothers ran a bicycle shop. When one was patching a tire but needed to talk to a customer, the other could finish the job. Each had the visibility to see what needed to be done and what the other brother was doing. Each could hold the other accountable. They also built airplanes and ran aeronautical experiments. And all is done without any hierarchy.

An airframe manufacture today has thousands of employees whose work needs to be coordinated and who need to be accountable for what they do. They too have to have visibility to understand what they are doing. But they work in a hierarchy where they are provided with just that visibility their bosses believe is needed for them to do their work. But when it’s the subordinate who knows better how to solve the problem, how is the boss to anticipate what visibility the subordinate needs?

Many companies in the Silicon Valley started out as small where everyone could see directly what was happening. They were very creative because they had the visibility that allowed them to develop new ideas. But when these organizations grew, they became hierarchical and less innovative. It was no longer possible for them to keep track of what everyone else was doing. So they live with the peek-a-boo visibility provided by the hierarchy, with all its well known evils and limitations.

Linus Torvalds had an idea for an improved operating system. He put his code on the Internet so that anyone who thought they could contribute could volunteer to do so. Linus, and eventually just a very few assistants, reviewed the submitted code and integrated it into the final product. Linux is now a major challenger to the Microsoft’s Windows operating system.

Each person contributed their time and thinking because they felt good about making a contribution to something that everyone held in high regard. But they also realized that they could use the product themselves. Their motto was: "Give a little, take a lot". Large corporations such as IBM and Intel eventually began to donate their paid programmers to the project. All these volunteers worked together, but not through a hierarchy.

In the Linux case, everyone could share a common visibility of the product because the product was in the form of text that could easily be posted on the Internet. It was also possible to share the visibility of the product when the product is something physical that we can see, like an airplane on the assembly line. What’s harder to see is the information that was developed to design and instruct the building of the plane. Now we have entered an age where the product is likely to be information. However, where we cannot share the ‘visibility of the product’, we can usually share the ‘visibility of the problem’, as we will explain below.

First, I consider that the business of business is solving problems. A business solves its own problem of making revenue by providing products and services that others use to help in some way to solve their problems. (I hasten to point out that the way I treat the word problem concerns the desire to make a transformation from one situation to another more favorable one. The problem is to work out how to make this transition. Thus, it includes both the concept of resolving existing difficulties and achieving future opportunities.)

Now we will see and then explain why:

If when we define the problem, we establish how the information is connected, then during the solution of the problem, we will know how the information flows. And if as we solve the problem we then keep track of what information is known and what is as yet unknown, the situation becomes visible. And when the situation is visible, the work can be coordinated.

Solving problems involves using information. Every problem has its own individual structure of how the various items of information must relate in order to solve it. To see the structure of a problem, one first lists all the information items that need to be determined before the problem can be declared solved. These items will depend upon each other. For example, to figure the price we will ask for a product one needs to know the value to the customer. But this depends on the capabilities of the product, which depend on the design, and so on. We can describe these dependencies with a matrix that looks much like a spreadsheet. (See sidebar.)

Now, there is a difficulty. Naturally we would like to order the items so that as we prepare to determine each item, all the items it depends upon have already been determined. If we could do that, a hierarchy would be quite suitable organizational structure for solving the problem by divide-and-conquer. But unfortunately, with most of the complex problems we face in business today, such an ordering is impossible. There will usually be some items that depend of other items that cannot be determined until after this item has been determined. Thus, there are circuits in these problem structures that have to be dealt with somehow. For example: Number Sold depends on Price, which depends on Costs, which depends on Manufacturing Cost, which depends on Number Sold. This can be dealt with by first assuming the number sold, then working around the circuit to return to where the assumption was made so the adequacy of the assumption can be reviewed.

We notice that when there are circuits, hierarchies don’t lend themselves very well to solving these problems. The structures of these problems are not the nice trees you get from the hierarchical divide-and-conquer approach.

To deal with circuits we must break each and every circuit with an assumption. We can make the break anywhere around the circuit. And one assumption may simultaneously break several circuits. Once we have broken a circuit we use an assumption for the first information after the break, then work our way around the circuit until we get back to that assumption again so we can have a review to establish whether the assumption was appropriate. If so, we continue. If not, we make other assumptions and go around again.

There are many sets of assumptions that we might make to break all the circuits. Choosing such a set defines our ‘approach’ to solving the problem. Thankfully, computer software can help make that choice. Once we have an approach, we know what assumptions we are making. That’s no trivial matter. Assumptions cause risks that these assumptions might not be correct. Note that when we lay out a plan without first doing this information analysis, we also make assumptions; but we might not recognize what they are or recognize that there are better places to make them.

Many problem solving projects nearly reach the end of their allotted time and money only to find that some assumption that had been overlooked now turns out to be wrong. So some work then has to be redone with new assumptions. But with no time and money left to do so, the project is delayed and runs over budget, leaving many red faces to explain to the customer why this happened. Obviously, a lot of this sort of embarrassment can be saved by doing the problem structure analysis before laying out the plan. (A sidebar shows such a matrix and guides you through how to interpret it.)

Given the structure of the problem and our approach to solving it, if we add the status of each information item as we are solving the problem, we can see the situation. This can be displayed on a computer screen or we can use the computer to ask questions of it. Not only do we see what information is and is not available, but we can also see whether that supposedly available information may still depend on assumptions that have not yet been reviewed and determined to be correct, and thus might have to be done over with new assumptions. This gives us a far better measure of true progress.

But most importantly, at any point in the project we have a view of what assumptions are still unresolved and everything that depends on them. Assumptions expose us to the risk that they may be wrong. But knowing what those assumptions are, their status, and what depends on them, we can manage these risks, and plan to drive them out as quickly as possible.

Then what does this situation visibility buy us? Every participant can now see whatever aspect of the situation they decide they need to do their work. Thus:

  1. They can see what they need to do.
  2. They are motivated by seeing why they must do it.
  3. They are also motivated by seeing how their work affects the whole process.
  4. They can see who they depend on and who depends on them.
  5. They can see how the information they will need is progressing and when it will likely be available.
  6. They can see when others are having trouble and offer to help or see to it that they get help.
  7. They can work as a team where everyone can see what everyone else is doing.
  8. Everyone is accountable to everyone else on the team because no one’s work is of value unless the problem is solved.
  9. Being able to choose what visibility they have rather than having it chosen for them allows people to seek out the ingredients they think they may need to create new ideas.
  10. One can see and learn from what others are doing.

When the people who will be involved in the work have the opportunity to participate in defining the structure of the problem, they have a better understanding of where their work fits in relation to the work done by others. They are more likely to discuss a problem with those on the other side of the wall rather than just throw it over the wall to them and walk away.

Much time can often be saved by reviewing an assumption as soon as the information is available to assess it rather than holding it up waiting for other assumptions to be reviewed at the same time. That way not only is time saved, but some risks can be evaluated and resolved sooner.

There are many additional advantages to having developed the structure of the problem:

  • When considering a change, one can see who and what will be affected.
  • When wishing something to be changed, one can see what it depends on, thus suggesting how to achieve the change.
  • The structure of the problem is a basis for discussion and collaboration.
  • It can be used for accommodating different groups during mergers and acquisitions.
  • Etc.

The concept of situation visibility is not new. It was proposed by Mary Parker Follett sometime before she died in 1933. She recognized that industry, even in her day, was becoming too complex to be managed from the top alone. She proposed that for management to be more widely distributed, each of those managers had to have a common visibility of the situation they were dealing with. Unfortunately, in her day she did not have the capability for providing and distributing that visibility. Today we have the computer networks to distribute that visibility, and now the means to represent that situation on the computer screen by the method we just discussed.


This sidebar shows how the situation might be presented so it would be visible to everyone involved.

The information items are listed on the left. The columns represent the same information items in the same order. The mark in row 2 column 1 says that ‘Projected Trends in Customer Needs’ depends on ‘Projected New Technologies’.

Here the rows and their corresponding columns have been reordered so that the marks above the diagonal represent where we plan to use assumptions. The blocks on the diagonal enclose where an assumption is used and where it can be verified. Thus it is shows what may have to be redone given a new value for an assumption. The numbers are artifacts of the process used to find the blocks. However, the higher numbers are associated with the their association with larger blocks.

The rows and their corresponding columns have been reordered so that the marks above the diagonal represent where assumptions will be used. The column shows what is assumed. The row shows where that assumption is used.

Those items that have been determined and are not subject to any outstanding assumptions are shown with a dark green background. The items that have been determined but still depend on unresolved assumptions are shown in light green. And those items that have the necessary information so they are ready to be determined are shown in dark blue.

Problematics Ideas!
© 1995-2015 Problematics

Contact us via email at: