Why Few Organizations Adopt Systems Thinking (2006)

An error of omission occurs when an individual or organization fails to do something it should have done. For example, when Kodak failed to acquire Xerox when it could have, or when Xerox failed to develop the small computer produced by its employees. Of the two types of error, errors of omission are usually the more important. The deterioration and failure of organizations are almost always due to something they did not do.

...

Now for a key fact: Accounting systems in the Western world only take account of errors of commission, the less important of the two types of error. They take no account of errors of omission. Therefore, in an organization that frowns on mistakes and in which only errors of commission are identified, a manager only has to be concerned about doing something that should not have been done. Because errors of omission are not recorded, they often go unacknowledged. If acknowledged, accountability for them is seldom made explicit. In such a situation, a manager who wants to invoke as little disapproval as possible must try either to minimize errors of commission or transfer to others responsibility for those he or she makes.

And also this: Learning how to learn is probably the most important thing an organization or individual can learn.

Some companies will accrete rules after every mistake until it is impossible to do anything.

>For example, when Kodak failed to acquire Xerox when it could have ...

I don't think it has ever made sense to buy Xerox, as an investment their record has been dismal.

>Kodak is currently in a precarious position, because it did not press the development of digital photography.

Except Kodak was a pioneer in digital photography. Their problem wasn't that they let the transition sail by. It was that they didn't recognise that they were a chemicals company rather than imaging.

The key work in systems thinking is drawing causal loop diagrams to identify potential feedback loops, some of which tend to stability and some of which tend towards instability. The way you draw these has almost infinite degrees of freedom, and so while they can sometimes be helpful in eliciting your own ideas, the outcome is ultimately heavily grounded in your preconceptions of what's important and about the relevant scope of the exercise. In working with it, I never had a sudden realization that some neglected factor was the key to everything and would provide previously unexpected levels of leverage. I never identified a feedback loop which provided outsized control over the process that I couldn't identify and attempt to resolve with traditional tools. So, as an individual analytical tool, I don't think it added much to deep thought, an outliner and a notepad.

The case studies and the literature about the practice emphasize its importance as a tool for communication and collaboration. It seems to me that many of the practitioners are mostly trying to use it as a rhetorical tool to try to win arguments about which they've already decided their bottom-line opinion. But I think in the context of a business, it fails at this in lightweight terms (i.e. without a major top down organizational push) because the idea is so foreign to others. First you would have to teach them what a causal loop diagram is, which is itself a quite nuanced topic, then you'd have to convince them that your particular construction and emphasis is the one that's most relevant for a decision. The "success stories" here make a lot of money for the consultants that are able to go do training for 5 layers of management like this author, but no one ever adopts it and makes important decisions which they credit to the incredible causal loop diagrams they drew.

Two additional issues. Systems thinkers sometimes emphasize the importance of quantitatively modeling the feedback loops. For almost all the things I care about, that's impossible or admits to the same explosion of degrees of freedom as the loop structure. If you decide that code quality is a concern, or that a deteriorating dev experience could be impacting velocity, you could try to find metrics that capture those, but finding metrics that capture those AND act as inputs or outputs to further nodes of the causal loop is pretty much impossible. Qualitative aspects of a system are of critical importance, and you ignore them at your peril.

Second, systems thinkers are not very good at thinking about probability and risk. The causal models allow you to think about what happens assuming you know about the inflows and outflows of systems and processes, but they can't be readily combined with an understanding of your own limited knowledge, or risks that are ever present in every decision. Thinking about risks quantitatively, even in ballpark terms, I found way way way more useful to my decision-making than all the time I spent thinking about feedback loops. Knowing whether your confidence that an improvement will work is 30% or 70% is directly useful, even if its only your informal probability, assuming that you are reasonably well calibrated.

The Wharton School isn't what it it used to be..

I tell my kids this all of the time. For some reason, they haven't embraced this - I suspect it has to do with conditioning from peers, school, society at large.

> This was a typical organization, one in which the principal operating principle was “Cover your ass.”

Yep, sounds all too familiar.

I'm not going to quote every bit, this is a pretty insightful article.

The kind of systems thinking outlined in the article is a very rare thing in the world, and outright frowned upon as "not proper" by those entrenched in the more conservative approaches to leadership.

Case in point: Elon Musk.

Compare SpaceX to NASA. The development cost of Starship, including about a dozen test articles, is the cost of a single SLS launch. People love to go on about how SpaceX is "making mistakes" and that their "rocket blew up", while neglecting to mention that the first SLS test launch also failed to achieve the desired orbit.

Elon Musk is one of the few corporate CEOs that get that mistakes are necessary stepping stones on the way to success. He encourages experimentation and rapid iteration, and will fire idiots that push back against improvement. Remember the engineer that argued with him about Twitter's slow performance, where it takes tens of seconds for it to show less than 1 KB of text? That guy had no incentive to make changes and was happy to let things be.

Meanwhile, I've been to over 150 organisations as a consultant, and not one of them has this mindset at any level of management. Everything has to be perfect up front. Everything needs to be planned 6 months in advance. Nobody is ever allowed to flip a harmless switch "just to test" an idea, no-no-no! That's not proper. The switch flipping has to be documented. It has to have a test plan, a rollback plan, a UAT plan, and seventeen people need to have a hundred meetings over months instead of simply trying the thing to see if it works.

This is the inherent nature of self-organised bureaucracies. Everyone optimises for their own personal local optimum, which is never the organisation's optimum.

Only the CEO can force behaviour changes to redirect efforts towards the global optimum, but that requires forcing people out of their local optimum, which is unpleasant for those people.

That's why you need "asshole CEOs" like Bill Gates, Steve Jobs, or Elon Musk. These people can never rise to top organically, via ass kissing and "making nice". They have to be there from the beginning, holding the reins of power in a way that cannot be taken from them by people that are made uncomfortable.