Introducing Systems Thinking into Your Organization

 

So you’ve read The Fifth Discipline, attended the Pegasus “Systems Thinking in Action” Conference, bought simulation software, and created your first computer models. You’re excited—systemic thinking could solve so many of the problems you’ve experienced and offers so much potential to help your organization. But where do you start? How can you get your colleagues—and especially your boss—as excited as you are? How do you help your organization succeed over the long run? And where can you get dozens of brightly colored coffee mugs imprinted with “Systems Thinking” and a cute stock and flow diagram?

First, relax and take a deep breath. (You probably need it, if you think a stock and flow diagram is cute!) Then consider some lessons I’ve learned, as I’ve tried to advance the use of systems thinking in many different organizations over the past 15 or more years:

Lesson 1: Except in rare circumstances, don’t tell your managers that they must adopt systems thinking. Most senior managers are eminent pragmatists, focused on their goals (or the goals they’ve been given). To them, as good as it is, systems thinking is just a means to an end. Your bosses will be more likely to hear you if you help them achieve their goals than if you ask them to adopt your tools.

Listen to them, and discover what their problems and goals are in their words. Ask questions. Be curious. Don’t fake curiosity so they’ll open up; instead, really be curious (people can often tell the difference, and taking this approach also affects your levels of perception). When they’ve stated a clear problem that systems thinking can address, ask them if they’d be interested in finding a solution. Then show them the way forward, perhaps without ever mentioning the words “systems thinking.”

Your bosses will be more likely to hear you if you help them achieve their goals than if you ask them to adopt your tools.

As an analogy, think about the times you’ve called the help desk to solve a problem with your personal computer. You don’t want the technician to tell you all the gory details about the technology you’re using; you just want her to solve your problem now. That’s the way your manager will likely regard systems thinking.

If you work for an innovative manager who sees the strategic advantage in simulation, you may again be tempted to start talking about systems thinking. Careful! I had a manager like that when I was starting in organizational simulation, and the situation initially seemed great. What I forgot was that the other managers I was serving, his peers, didn’t share his enthusiasm, and I needed to work on solving their problems, not talking about my technology.

Lesson 2: Don’t do your work in a vacuum. When I first started out, I’d ask managers what their biggest problem was. They’d tell me, and then I’d head back to my desk and computer to start working on it. A week or so later, I’d drop by the managers’ offices again to get more data, only to hear that they had solved the problem two days earlier! When I would ask what they did, it was clear they had found an acceptable but often quite mediocre bandage to apply. That is, they fixed the problem well enough so that they could turn to another area of concern that was crying out for help, but they hadn’t necessarily fixed it for good.

It took me a few loops through this process before I discovered that, if I didn’t change my approach, I would always be working on a problem someone had declared was their biggest bugbear one day and that they had “solved” two days later—not a way to feel good about my contribution or to ensure my long-term job security!

If a manager presents you with a problem, work with him to solve it. Solicit the information you need while you’re sitting with him, and capture the key aspects of the situation on paper in front of him. Scribble down statements, data, and fragments of stock and flow diagrams. Accept the manager’s input about the diagram. If it’s the sort of issue and situation where it’s appropriate to pull together a group, do so and use any of the facilitation techniques created to help with such work, such as those described by George Richardson and David Andersen in “Teamwork in Group Model Building,” available at http://www.albany.edu/~gpr/ Teamwork.pdf.

You’ll probably need to do some of the more detailed modeling on your own, but don’t stray long from involving the others in giving you data or reviewing and guiding your progress. You’ll have to judge how long you can stay apart, but in most cases, you should be interacting several times a week.

To maintain that openness and pace, you’ll need to be good at modeling. If you don’t feel comfortable working in front of your managers or internal customers, and if you have to spend more time studying than doing, get some support, whether it means taking a course, bringing in outside consultants to help, or allying yourself with others in your company who can help you deliver the services your internal customers expect. You might find a consultant who will collaborate with you so that you deliver the value together while you simultaneously increase your skills.

Lesson 3: Respect the data. As I was listening to an explanation of a problem recently, I developed an intriguing hypothesis regarding the cause of the behavior being described. Back at the office, I started working on a simple model to explore that hypothesis. The harder I looked, the less I could find quantitative evidence that my theory was true. After a bit of struggle, I managed to let go of my intriguing idea, focused on the data, and ultimately discovered what I think is an even more important story.

Remember that data comes in many forms, not all of which are quantitative.

Lesson 4: Develop a knack for seeing patterns and recognizing likely underlying structures. One of the key mantras of systems thinking is that events are part of patterns, and patterns are created by structures. Most people look at events and see events. When you see a notable happening, see if it’s part of a pattern. If it is, think about the type of structure that might create such a pattern—such as exponential growth or cyclical behavior—and look at the organizational system to see if it has such a structure. Then think about modifications to the structure that might fix the recurring events. Finally, test your hypothesis by creating a simple simulation model.

This approach will help you offer effective services faster, and your managers will appreciate that you can help them solve their problems well and quickly. Of course, you get better at recognizing the structures that create specific patterns by doing lots of simulation.

Some years ago, I watched a manager talk about bouts of overspending followed by bouts of underspending. To him, it was an event of overspending that lasted several months, then a pause, then another event of several months of overspending. I saw this as a type of simple oscillation, and I began to look for a structure that could create this kind of behavior. Knowing what to look for expedited my search for a structure in the organization that could generate such a pattern. It wasn’t too far from discovering the structural problem to proposing the cure, and then testing it, submitting it for approval, and implementing it. Incidentally, out-of-control spending dropped by 95 percent when we installed the new process in the real world.

Lesson 5: Remember that systems thinking is ultimately about helping people. No matter how ironclad your model seems to be, you’re doing this to make the world (or your piece of it) better for people. Most of us don’t want to be told what to do; we prefer being involved in the process of deciding what to do. When you keep others involved and make it clear that your goal is to help them, not simply to create a technological marvel, people are more likely to provide insights you need and help the implementation succeed. Besides, it’s the right thing to do.

In the out-of-control spending case, I created a simulation model and persuaded the manager to try the approach. As we implemented the solution, we created a team that met weekly to discuss progress and to guide mid-course corrections. Even though I had created the model and implemented some necessary software, I made sure my influence was only equal to that of the others. To keep that message of equality in the forefront, we rotated responsibility for leading our meetings so no one appeared to be the de facto leader.

Involving the entire group was key to our success, for everyone involved knew that they had a say in the matter and that we’d do what worked in the real world, not just what worked in my model. Everyone, from the administrative assistants to the finance department representative to the managers, understood that this system was in place to help them do their work more effectively and to help the organization be more successful, and they knew by example that their insights could and would be adopted to further refine our process. I credit the project’s success half to the insights from modeling and half to the way we involved the people doing the work.

Lesson 6: Plan on course corrections; systems thinking doesn’t end when you’ve got a model. Your model was only a model; you’ll probably discover unforeseen problems as you implement the solution. Because models produce hard numbers, while life often seems messy, it’s sometimes tempting to hold on tightly to the lessons of the model when the two seem to diverge.

Remember that you’ve just sold your organization on the importance of a systems view and on the importance of understanding feedback. Now it’s your turn to deal with feedback—feedback from the real world. Listen, observe, and reflect, and be willing to incorporate what you learn into the implementation.

Now, take another deep breath, stand up, and go make your organization and the world better! Don’t sell systems thinking; be a systems thinker!

Sign up or sign in to bookmark this article.