Systems thinking doesn't have to be hard

Lately I've been reading John Seddon's Beyond Command and Control. Seddon is explicit about urging managers to think of their organizations as systems, so I thought this would follow logically on my reading Donella Meadows, as I discussed here. But I was also a bit worried. Meadows, after all, was a systems scientist trained at MIT; while her book is written engagingly for nonspecialists, she casually discusses problems of immense complexity in ecology or economics. If Seddon encourages us to take a systems approach to our businesses, how many formulas will we have to use? Will I have to remember how to solve partial differential equations? That was a long, long time ago .... 

The good news is that no, Seddon's book doesn't require us to master any technical formulas. What he asks for is far simpler, although plenty challenging on its own. He says the most important first step to improving everything about the way you work is simply to study what is actually going on in your business day-to-day. Just look at it, until you really understand what it takes to get things done. When he says you have to see your business as a system, he is fighting against the natural tendency (natural, at any rate, in large organizations) to see your business as a collection of departments that are more or less unrelated to each other.

The point is this: as long as you think of the business broken up into a bunch of departments, the next natural step is to think about how each department can optimize their work, on the assumption that if you can optimize each department you have optimized the whole business. But Seddon points out that your customer doesn't see all the internal departments, and certainly doesn't care about them. What your customer cares about is getting his needs met: finding the right product or arranging for the right service, and doing it all simply and easily and at a fair price.

You'd think that should be the same thing, but too often you'd be wrong. Seddon says that his first step when working with a new client* is to send top management out to the front office to watch a single order come in, and then to track that order through its whole life-cycle. Invariably, he writes, that order winds its way through a dozen departments. Each department is furiously busy, and finishes their work very efficiently so they can pass on the order to the next department in line—among other things, this means that each department's metrics are always green. But the whole path is so complicated that it takes way longer than you could ever imagine possible, and with every additional step there's one more chance for error. At the micro level, the work is efficient and expeditious; but at the macro level, the whole life-cycle of an order looks to have been designed by a madman.

That's what Seddon means by taking a systems view: he's not asking us to become population biologists or experts in computer modeling, but simply to see things whole. And his point is that once you can see things this way, once the blinders of departmental structure have fallen from your eyes, then it usually becomes obvious how to improve. Stop asking twenty people in different departments to do the work that could be done by one—done faster, done with fewer errors (because of all the information lost in hand-offs), and therefore (in case you are keeping track) done a whole lot cheaper. Usually this also means not micromanaging your employees by requiring them to follow scripts or by planning out their every move; for that reason Seddon urges managers to stop monitoring or regulating employee activities, and to start monitoring their results as seen by the external customer. This isn't just about "trusting your people," although there's surely some of that; more importantly, it's about measuring the right things, and not just the things that it's easy to measure.

Seddon is famous as an opponent of the ISO 9001 standard, but I see nothing in his approach that is actually incompatible with ISO 9001. Much of what he says is incompatible with the way some folks choose to implement ISO 9001, but that's a different matter. That just shows that many people don't understand what the standard really means, and therefore implement it in foolish ways. But that last point is hardly news. I've written about it before.

Meanwhile I'll let you know what else I learn from this book. 

__________

* He heads Vanguard Consulting, who offer as a service to work with you to improve your business.

      

Systems thinking in the workplace

Last week I posted about dipping my toe into systems thinking, and I wondered aloud how far a systems approach could find a practical application in the workplace. By a curious synchronicity, that very day a LinkedIn post led me to an article in the Harvard Business Review on this very subject.

The article (by Ludmila Praslova) is titled "Today’s Most Critical Workplace Challenges Are About Systems," and it argues that too often we blame errors or nonconformities on individual failure when the real problem lies with the design of some system. Of course this is a commonplace in the Quality business, but I was thrilled to see the point made by someone coming from another area of specialization. What particularly caught my eye, though, was that Dr. Praslova explains exactly why this is so hard to do.

Her article starts by reviewing several distinct cognitive biases that make it easy for us to see the trees but hard to see the forest. And in fact this problem is something that Donella Meadows says is true of systems in general: it is always easier to look at individuals and events than to look at stocks and flows and long-term behavior.*

Praslova's next step is to identify several techniques which we can use during a problem-solving exercise to help us see past the trees to the forest. These techniques include:

"Diversify the collective cognition in leadership." Praslova argues that the true value of diverse leadership is very specifically to appoint members to leadership who think differently. If everyone thinks exactly alike, the chances of seeing anything more than a superficial view of things are dramatically reduced.**

"Integrate contextual thinking into forms and procedures." This should be straightforward. Since it is easy to forget about context or the impact of systems, it helps to build reminders into the forms and procedures you use. If Question 3 specifically asks about the context in which a failure occurs, you'll remember to check the context. Likewise if your 2 x 2 x 5 Why analysis requires you to ask how a problem could have been caught or prevented, you'll take those topics into account during your root cause analysis.

"Address the stress." Praslova points out something we all know but forget too quickly: too much stress makes you take shortcuts in your thinking, and one of these shortcuts is regularly to stop looking at context or systems.

"Invite broad input." This makes the same point as the advice about diverse leadership. When you bring in people who see a problem from different angles or perspectives, you necessarily get a better and more complete view of what is going on. And the more complete your understanding, the greater the likelihood that you are incorporating a critical systems perspective.

"Appoint a systems champion." And of course, if you want to make sure to take a systems perspective into account, make sure that someone on the problem-solving team has the specific task to ask system-related questions.

Will these techniques guarantee perfect problem-solving? Obviously there is no such thing as a perfect process. But each of them addresses one way that a systems perspective can slip past us. Taken together, they are bound to help.

I still want to invite readers to contribute any further insights they have about how to apply systems thinking to the design and implementation of management systems. But I was delighted to discover this article just as I was writing last week's post.   

__________

* See for example her Thinking in Systems, pp 2-4, 87-91, or 147-149.  

** One logical consequence of this insight is that it is more helpful to look for diversity of thought than to check a list of demographic categories or to look good to external parties. To be clear, this does not mean that demography is never relevant. But if your leadership is demographically diverse and nonetheless all think exactly alike, it won't help you much. 

     

Are management systems really systems?

This last week I've been reading about basic systems theory—specifically, Donella H. Meadows's primer, Thinking in Systems. And I've started to wonder about the management systems that we work with in the Quality business. Do these qualify as "systems" in Meadows's terminology? And if so, can systems theory teach us anything useful about how to design or implement a QMS?

The answer to the first question is an easy Yes. Meadows defines a "system" as "a set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time." Since a management system is "a set of policies, processes and procedures used by an organization to ensure that it can fulfill the tasks required to achieve its objectives," it obviously qualifies. But the second question is more interesting, and I don't have a final answer yet.

What I have seen is just how well her basic list of the features of systems maps to our everyday experience. In Chapter Three ("Why Systems Work So Well") she lists three important features.

Resilience

Systems generally have feedback loops that allow them to self-correct when they go too far out of alignment in any direction. This doesn't necessarily mean that systems are static—quite the contrary! But it does mean that they respond and adapt to changing circumstances. And of course management systems are designed to do this too. 

• Organizations set goals, and then evaluate whether those goals have been met; in case the goals were missed, the organization has to make a decision how to react, and this typically means analyzing what went wrong and then correcting the goal (or the system) based on the analysis. 
• Formal management systems generally require internal (and sometimes external) audits, in order to find places where the system has broken down or is not effective; then the responsible functions have to take corrective action to repair the situation. 
• And formal management systems require some kind of regular management review, which again looks for areas that have to be improved. All of these methods involve providing a kind of feedback to the organization that allows it to adapt to circumstances.

What's more, Meadows's discussion of resilience also picks up some of the dysfunctions we have discussed when talking about bureaucracy. She recognizes that bureaucracy is how large organizations communicate internally, but when it gets too large the communication becomes too slow. 

Large organizations of all kinds, from corporations to governments, lose their resilience simply because the feedback mechanisms by which they sense and respond to their environment have to travel through too many layers of delay and distortion. [p. 78]

That was exactly the point of discussion between Scotlyn and me last spring.

Self-Organization

Normally when we ask about an organization's management system, we mean the part that is defined in the documentation, the part we can audit. But every organization displays regular, stable behaviors that are not covered in the documentation. All of these are the result of self-organization on the part of the people in the system, and they have an enormous impact on the way work gets done. 

Some of these behaviors can actively subvert the purpose of the management system, such as when people game their metrics to ensure they are always green.

Sometimes the behaviors don't affect the management system directly for good or for ill, but they define the spirit or culture of the organization.

And of course sometimes the unplanned (self-organized) actions of the people on the floor can be an enormous help. The whole reason that our profession now uses Quality Circles is that they are a formalization of what must originally have been a self-organized discussion among line workers who were trying to solve some production problem. Today we say that Quality Circles are part of the formal, documented system; but it is not possible that they started that way. We all know that informal methods always precede formal ones.

Hierarchy

Clearly every management system assumes the existence of some kind of hierarchy in its organization. The ISO 9001 standard, for example, has multiple references to "top management." (See clauses 5.1, 5.2, 5.3, and 9.3.) One of the first artifacts we auditors ask an organization for is an org chart, so we can understand the hierarchy and the associated responsibilities. Even in cases where a group of people are working together without any hierarchy at all—at first—Meadows says you can watch one grow spontaneously (as a result of self-organization!) in order to reduce chaos and confusion by imposing some kind of organization. (The German sociologist Robert Michels once stated, "Who says organization, says oligarchy.")

What fascinates me is a remark Meadows makes about how hierarchies develop:

Hierarchies evolve from the lowest level up—from the pieces to the whole, from cell to organ to organism, from individual to team, from actual production to management of production. Early farmers decided to come together and form cities for self-protection and for making trade more efficient. Life started with single-cell bacteria, not with elephants. The original purpose of a hierarchy is always to help its originating subsystems do their jobs better. [p. 84. Emphasis added.]

This means the next time I do an audit, I should be able to ask the top management, "How do you help the people on the production line do their jobs better?" I want to remember that!

So management systems are indeed "systems" in the technical sense, and the common features of systems are things we all know from long experience working with management systems. I haven't decided yet whether there are other lessons to be derived from systems theory that might help us in the Quality business to do our jobs better. But I am continuing to think about it. If you know more than I do about this, please say so in the comments.

     

The deep source of Quality

Image by lovelyheewon from Pixabay

The other day I read the most encouraging article I have seen in a long time. Bookstores are coming back.

More precisely, Barnes & Noble is profitable and growing again.

Is this a Quality story? Yes it is. Remember that Quality means getting what you want. For a long time, Barnes & Noble failed to give customers what they wanted, and the company suffered as a result. The article describes a long string of bad decisions by Barnes & Noble management that made the stores "crucifyingly boring" and that made the company catastrophically unprofitable. In many ways it was just hanging on waiting for Amazon to kill it outright.

And then Barnes & Noble brought on a new CEO, named James Daunt. Daunt made changes to the Barnes & Noble stores that made customers want to go there ... and, once there, to buy books. He made the stores interesting, and he got them to sell interesting books. In other words, he improved the whole Quality experience for customers, and customers responded to the higher Quality with their wallets.

If you want to build a checklist of Quality tricks and tools from Daunt's success, you might find a few in the article. One important change was that he gave each store a lot of autonomy in deciding what to stock and sell. He trusted the local employees to know better than anyone else what would sell in that location. And he accepted the consequence that each store would look different—even unique. This by itself was huge. The article lists some other measures that he implemented. Doubtless a full study of his turnaround would uncover even more.

But the article also makes it very clear that the heart of Daunt's success doesn't lie in tricks and tools. The heart of his success isn't about methods. The author explains the point, rather, as follows:

"This is James Daunt’s super power: He loves books."

It's as simple—and radical—as that. Because Daunt loves books, he knew immediately and intuitively what things matter to people who buy books. He knew which decisions would make book-buyers happier, and which decisions would make them miserable. And so he also knew—immediately and intuitively—what practices to abandon, regardless how strongly they were championed by management experts or executives. 

Some of these practices that he abandoned had formerly seemed fundamental to the bookselling industry; and when you describe them on a whiteboard or in a boardroom they sound like they make sense. But they alienate people who love books, and of course those people are the target market for a bookseller. Alienating them is by definition bad Quality! The problem that had trapped Barnes & Noble in the past was that these bad decisions were made because they sounded like they made sense. And since the people who made the decisions were not themselves booklovers, they couldn't see that the decisions were wrong.

In other words, the deepest source or spring of Quality is love: love for the work or love for the product. If you don't fundamentally care about what you are doing, no collection of tricks and tools will be enough to make the difference.* And when you do care, that caring prompts you to look ever more deeply ... and looking deeply helps you see what to do.

Of course the methods and techniques all help. But the love, the caring, the deep looking—all these come first. Only afterwards can the methods and techniques find their place.

__________

* Robert Pirsig makes the same point in Zen and the Art of Motorcycle Maintenance:

"Maybe it's just the usual late afternoon letdown, but after all I've said about all these things today I just have a feeling that I've somehow talked around the point. Some could ask, 'Well, if I get around all those gumption traps, then will I have the thing licked?'

"The answer, of course, is no, you still haven't got anything licked. You've got to live right too. It's the way you live that predisposes you to avoid the traps and see the right facts." [p. 324]