Single Point of Contact: David Moskowitz

HDI’s SPOCcast is your single point of contact podcast for service management and technical support insights. For Episode 26, I interviewed David Moskowitz about Systems Thinking. What follows is excerpted; for the full impact, I encourage you to listen to the entire podcast.

Roy: Today we're going to talk about systems thinking, and I’d love for you to define that for us and just talk a little bit about it and, and then we'll get into some of the details about why it might be important. So, can you give us a definition?

David: Well, there are lots of single or sentence definitions, but I like something that I got from Dr. Russ Ackoff who was a professor at Penn, and I'm in the Philadelphia area so it was easy to listen to an audit some of his lectures, and I like his approach better than most of the others that I've seen. Now, having said that; before I get into what he said, there are so many different aspects of systems thinking that I don't know that there is a single, accepted, absolute unifying definition for the term. I think it means different things to different people and obviously if you talk to somebody in IT, and talk about systems thinking, the first thing they're likely to think about is an operating system or something related to it. But from that perspective, systems thinking is a way of understanding a whole that consists of parts where each part affects the behavior or the properties of the whole itself. If you think about it, a car is a system for transportation and pressing on the accelerator changes the fuel flow which changes the engine speed which changes the car. But the…direction of the car can also be changed by turning the steering wheel, so that each individual part of the car impacts the properties of the whole.

So, each part of the system has an impact on the system, but you can't look at the system as a collection of independent parts, because each part in the system is dependent upon some other part for that particular system to operate. Again, if you look at a car, you can't make a wheel go without the drive shaft, and the motor, and the whole fuel system, so that in fact, if you take the car apart, and then say that you're going to construct a car from all of the best of breed pieces from every car that's ever been made, and you put that together with the best engine, the best wheels, the best tires, the best steering wheel, the best paint job, the best cylinder heads, the best spark plugs, and put it all together, you probably wouldn't be surprised to discover that it's not likely to work, because the parts weren't made to fit together. They weren't made to operate together; they weren't made to work together.

And that's the other thing about a system is that no part of a system, or even a collection of parts of a system, has an independent effect. You can't take the motor out of a car and go anywhere. It's no longer a transportation system. So that the system has to be viewed as a whole. And that's part of the challenge, because a lot of people don't see the whole, they see a hole, h-o-l-e, so that in some cases they look at the world through a straw, as opposed to seeing everything that's there. Because you can't divide the system into independent parts and get the same results. So, the essential or defining properties of any system are not properties of the parts; they're properties of the whole.

None of the individual parts have the properties of the whole. So, what that leads to is that—and this again comes from Dr. Ackoff, and I think it's a brilliant encapsulation—the system is not the sum of its parts; it's the product of their interactions.

That gets back to stuff that Deming was talking about. You can't fix a system by fixing a part of the system. You have to consider the whole, not look at it—again, if you will—through a straw. You can't improve the parts of a system separately. The performance of the system depends upon how the parts interact, not how they fit together or how they're taken separately.

What's different about systems thinking than traditional thinking? In traditional thinking we analyze a problem. In fact, the very definition of the word analysis has inherent in the definition this breaking this thing into parts. In an analysis, it's the examination of the parts that matter.

Think about the idea of things like root cause analysis for a moment. Forgetting for a moment that there's rarely a pinpoint single root cause, the analysis…tries to take things apart and figure out which part is the issue of or which part of causing a failure. If we do that for availability, we do a component failure impact analysis. What is it that we're looking for? The part that can cause a problem. So, we try and isolate small parts of the system under study, we examine the parts, we don't examine the whole. And what happens? How often have you seen that you have a “fix” for a problem. But that fix exposes some additional errors or vulnerabilities.

Roy: But that's what we call playing “Whac-A-Mole,” right? If something pops up and you go fix that and something else pops up.

Systems act exactly as they're designed, right? A system functions according to its design. Is that something that we need to look at a little bit differently? Because sometimes, obviously, the outputs that we get and the outcomes that we get are not as intended. And therefore, we tend to look for the part that's causing the problem, when in fact, the system is functioning exactly as it's designed. What are some of the ways we can avoid that?

David: Well, there is some confusion about the origins of the statement that suggests that any system is perfectly designed to get the results or outcomes that it's currently delivering. And it's often attributed to Deming, and I can't argue with it. But I've seen others get credited with variants of the same thing. But what that says—and it goes back to something I said a few moments ago—and that is, you can't fix the system by fixing the parts.

And that gets into something by the way that, and I hope I'm pronouncing his name correctly, Peter Senge, who wrote the book The Fifth Discipline, talks about building a learning organization. And from his perspective, the learning organization has to learn to think differently, and he uses a phrase or word that has its origins in Greek, metanoia, that is really what it comes down to is an intentioned paradigm shift—an intentioned change in thinking—and it's difficult to go from traditional analysis to an analysis of the system as a whole. We're used to looking at parts.

This secondary effect, the Whac-A-Mole as you refer to it, occurs because we're so used to deconstructing this thing that we don't necessarily look at it from the perspective of the whole, and in fact, an example just popped into my head. There's podiatrists, there's cardiologists, there's people who deal with ear, nose, and throat. Internal medicine, and orthopods, and people who look at eyes. And how many of them are looking at the whole?

Why does your pharmacist sometimes have a better view of what's going on with you than your doctor? Because the pharmacist knows everything that you're taking and can deal with drug interactions; because the doctor sees their specialty within limits. And I'm not trying to impugn the medical profession. But it comes back to the idea of the golden hammer. If this is your perspective, and all you have is a hammer, then every problem that you try to solve looks like a nail.

Roy: That's an issue that pops up again and again and again in our world, IT, in the general sense, right? [Let] technology fix it, or we've got software that will do that. It seems to be our first response to almost anything that we get asked to do or fix or accomplish. And so, we're looking at our hammer, which is the IT environment, to fix issues which are perhaps grounded elsewhere, and often are as we know.

And let me go back to something you said a couple of minutes ago. You brought up the word organization, and I was thinking that one of the biggest systems that we need to consider is the organization in which we work, or that we're trying to help, and so forth. So, in what ways can we use systems thinking when we look at organizations, and try to assess what improvements need to be made in order to accomplish what it is that we're trying to do?

David: And now we get into the area of organizational change management. How many times have we tried to deal with a technical solution, or we're going to do things this way. And over some period of time the rubber band snaps and we're right back where we were before. The idea of…a silver bullet approach.

One of the things that started me down the path of thinking differently was the realization that every single technical problem that I've ever been asked to solve…had at its core people, not technology,…at the root of the problem. People either created the problem, or the need for a solution.

Every single technical problem that I've ever been asked to solve had at its core people, not technology, at the root of the problem.

And that made me look at things a little bit differently, to the point where I was dealing with one company where I was an employee, and they were looking at building some new hardware. And in the senior design meeting I asked did anybody check with the customer to find out whether or not this is something that the customer wants. And I realized that I was working at the wrong place when the answer I got back was, “The customer doesn't know. That's our job.” And that, combined with people at the core, but it also… it's not just the organization that we have to fix, that's a part of the system. It's the organization and all of its stakeholders, which include—potentially—shareholders if it's publicly traded, customers, partners, suppliers and employees. But it all starts at the level of people and understanding expectations and outcomes.

Instead of looking at it through the lens of “It has to be a technical problem” is looking at it through a different lens that says, “What's the real system that I'm trying to understand?” and then we have to look at three different flows—How does work flow? How does communication flow? How does improvement flow?—with the understanding that the structure and behavior of a system are inexorably linked. You can't change or impact one without changing the other.

I find it sometimes simpler in my own consulting practice to look at how work actually flows, not how they say it flows. How does communication actually flow, not how they say it does, or not what the reporting channel is, and how are improvements handled? How do they flow through the organization? How much of it is reactive how much of it is proactive? And the same thing is true, that same filter applied to communication and work, how much of it is wasted work? How much of it is productive work?

And how does that contribute to the overall enterprise experience and the outcomes that are expected by stakeholders. So, it's a different point of view but that gets back to this idea of metanoia that Peter Senge is talking about.

Roy: One of the things that you discover if you do a little investigation into any organization is what they think is going on and what's actually going on may be quite a bit different from each other, you know, and the way things actually happen is more the literal culture of the organization than the way things are said to happen. And therein there are many problems in talking about organizational change. We're not utilizing elements of organizational change to make it happen, and I think that's fairly common in our world, right. So it goes in, and the processes might be changed but there's no effort to make sure that people, parts of that organization, the behaviors of the people involved are not going to fall right back to the way they were doing things before, and not leveraging the new technologies. In many cases they're not even being trained on the new technologies, right? Or don't even know that they're coming.

One of my favorite phrases that came out of an HDI local chapter meeting. A woman from an insurance company, we're talking about major projects for the organization that year, whatever year that was, as she said she had somebody call the service Desk and said after this specific software was updated, “Yesterday I knew how to do my job; today I don't.”

David: I'm not surprised, but the other issue—and you touched on it, and I did too—so let me sort of bring this home a minute. You said how do we use this to deal with impacting organizations. What it means is that we have to expand our view, beyond the parts or the components of a system. We have to look at the interactions within that system. That's what I was talking about when I said you have to examine the flows; those are the interactions.

Actions produce results. Results shape future actions.

Roy: It can't be the syndrome we were talking about a little bit earlier, right? It actually has to be real change.

David: And if you have to understand this notion that real change has to impact both the structure of the system and the behaviors within the system, because the system is not what we say it is, but how things flow. What are the interactions of the parts? How do they interact on each other? Not, “What are the parts?”

About David Moskowitz

David Moskowitz started his formal career as an operating systems programmer and systems architect which required that he look at not just the code he had written, but also how the resulting operating system might impact the applications that would run on the computer. Later, while serving in the US Army he was tasked to apply that approach to looking at different forms of systems and complexity regarding where and how US Armed Forces were engaged. This required working within the integration of the staff functions (personnel, intelligence, operations, logistics and later civilian-military operations and planning). After his military service, he continued to apply a systems approach to his job and later as a consultant. He is recognized (and certified) as an ITIL Expert applying the approach that ITSM represents a management system. Since mid-2018, he has worked with clients to help them integrate their ITSM activities with the critical need to include better cybersecurity hygiene.

Roy Atkinson is one of the top influencers in the service and support industry. His blogs, presentations, research reports, white papers, keynotes, and webinars have gained him an international reputation. In his role as Group Principal Analyst, he acts as HDI's in-house subject matter expert, bringing his years of experience to the community. He holds a master’s certificate in advanced management strategy from Tulane University’s Freeman School of Business, and he is a certified HDI Support Center Manager. Follow him on Twitter @RoyAtkinson.