When Metaphors Backfire – Ackoff’s 4 Types of Systems

As a learning aid, metaphors are extremely useful. They help us understand something that’s new and unfamiliar by using something that’s familiar and better understood as a model.

But metaphors can also backfire. When they over-simply the system they intend to describe, they can lead to the wrong conclusion as to what would be an effective intervention in improving the system’s behavior.

This is exactly the point the Russell Ackoff and Jamshid Gharajedaghi made in their essay:

On the Mismatch Between Systems and Their Models

They first define what a system is:

  1. It’s defined by its function(s) in one or more containing systems
  2. It contains at least two essential parts that:
    1. Can affect (change) their own behavior / properties
    2. The way they affect the behavior /  properties of the whole depends on the behavior of other parts in the system
    3. They way groups of essential parts (subsystems) affect the behavior / properties of the whole  depends on the behavior of other subsystems

They then define four types of system based on whether the whole, and its parts can display choice and the purposeful behavior which derives from it:

  • Deterministic systems: neither the parts nor the whole can display choice. Example: a Clock – both parts and whole are completely mechanistic)
  • Ecological systems: the parts can display choice but the whole cannot. Example: Nature – some parts of it (the animate parts – like people) can display choice. We can affect our environment, but the way the environment reacts to our actions is determined (though not always fully understood).
  • Animate systems: the parts cannot display choice, but the whole can. Example: a Person – we can make choices, but our organs cannot – their behavior is determined in a similar way to the behavior of an engine in a car. They do not make choices.
  • Social systems: both the parts and the whole can display choice. Example: Organization – but the parts (people) and the whole (organization) make choices.

Metaphors backfire and lead to wrong conclusions when they use a model of one type of system to describe a different type of system.

A recent example that I covered in this blog is Holacracy. Holacracy often uses the “operating system” metaphor to describe the way it interacts/affects the organizations in which it is implemented. When this metaphor is taken too far, it models the organization (social system) as a computer (deterministic system). And this is when things start to fall apart / diverge from reality.


When Metaphors Backfire – Ackoff’s 4 Types of Systems

Strategy as Heuristic (excerpt)

“Corporate leaders are expected to be bold generals who forecast the future, devise grand strategies, lead their troops into glorious battle – and then are fired at the first lost skirmish. It takes a courageous executive to push back against this mindset, admit the inherent uncertainty of the future, and emphasize learning and adapting over predicting and planning” – Eric Beinhocker

<Begin excerpt>

“We may not be able to map the perfect route to the ideal future, but we can often ascertain some orienting principles for navigation. Without trying to predict exactly what forks in that road we will encounter, we can ask ourselves what will help us to make the best decisions when we do come to a fork. When we step back to look at the broader context and the general terrain and options in front of us, we can often come up with guidelines, such as “generally head east”, or “choose the easy roads even over the most direct roads”. A rule of thumb like this really helps when we’re confronted with a choice and want to benefit from wisdom generated when we had the luxury of pulling back and analyzing the bigger-picture context. When we distill that wisdom into memorable guidelines, we can apply them more easily and more regularly amidst the hustle and bustle of day-to-day execution.

This, then, is the form that strategy takes – an easy-to-remember rule of thumb that aids moment-to-moment decision making and prioritization (the technical term for such rule is a “heuristic”). I’ve found it useful to express these decision-support rules in the form of a simple phrase such as “emphasize X, even over Y”, in which X is one potentially valuable activity, emphasis, focus or goal, and Y is another potentially valuable activity, focus, emphasis or goal. Now, to make that useful, you can’t just have X be good and Y be bad. “Emphasize customer service, even over pissing off customers” is not helpful advice. Both X and Y need to be positives, so that the strategy gives you some sense of which one to privilege, for now, given your current context. For example, one of [my company’s] strategies earlier in our company’s development was “emphasized documenting and aligning to standards, even over developing and co-creating novelty”. Notice that both of those activities are positive things for an organization to engage in, but they are also polarities, in tension with each other. Our strategy is not a general, universal statement of value – in fact, if we tried to apply it forever it would undoubtedly cause serious harm eventually. There are times when it is essential to emphasize developing and co-creating novelty over documenting and aligning to standards. But for [us], given our context at the time, and the recent history before that, and the purpose we’re serving, that was our best sense of what to privilege, at least for a while: standardization, even at the expense of pursuing new and exciting opportunities.

Of course, no one was against the creation of novelty – for me, it often feels like the most natural way to operate. For the first few years of our growth, every event or training we did was unique and special, co-created on the fly with various partners who offered to host us and help market. This helped us to explore the new landscapes we were moving into, and it generated a lot of movement and some important relationships. But soon, our penchant for creating new and exciting offerings became unsustainable for that particular phase in our growth. It’s expensive when every new offering is a custom product and each partnership requires hammering out a unique deal. We arrived at the strategy I’ve cited so as to redress the balance, to stabilize the organization and make it more efficient and sustainable. It provided useful guidance and had a focusing effect as we navigated the daily decisions we each faced. And ultimately, the strategy became irrelevant – we had integrated these two poles pretty well and found the harmony between them, and it was time to focus elsewhere.
As an example of how the standardization-first strategy helped: [since I’m responsible for] Program Design in our Education [team], from time to time I’d get an email from someone who had heard about [us], gotten inspired, and now wanted to partner to create a new type of event for his particular business sector. I get excited by opportunities like that, but out strategy reminded me that at that moment in our development, I should instead invest my time and energy in standardizing our existing programs and events – even if it means missing this new opportunity. “

</End Excerpt>

After the tough criticism I gave Holacracy last week, I wanted to use this opportunity to share something about Holacracy from a “glass half-full” perspective. This 5-paragraph excerpt from the book, beautifully describes a rather radical and unique take on what strategy can be.

Strategy as Heuristic (excerpt)

Holacracy or Humacracy? (Book Review)

Holacracy has been on my radar for the last couple of years as an organizational paradigm that’s worth further exploration. I’ve covered some pieces of it on this blog as well.

I was thrilled to learn that Brian Robertson, Holacracy’s creator, has finally written a book about it, and was really looking forward to reading it:

Holacracy: The New Management System for a Rapidly Changing World

If you have no idea what Holacracy is, I won’t suggest jumping straight to the book, but starting with this short article instead:

Here’s Why You Should Care About Holacracy

The book provides the most holistic, yet still readable, description of what Holacracy is really all about (pun intended). Though it still leaves much to be desired (which we’ll get to in a second), it does a great job illustrating how governance and tactical meetings work and touching on some of the less known aspects of Holacracy such as its approach to strategy and to deadlines, both strongly resonating with me. The aspect that would have probably benefited the most from further exploration is the circle-based org structure. It doesn’t address some of the key org design challenges that exist in traditional hierarchical structures, like the need to alternate organization and focus by function, product/service and customer/region. It also enacts a meaningful organizational constraints that doesn’t get acknowledged: if each sub-circle is represented in governance and tactical meetings by both a lead-link and a rep-link, it puts the limit on the number of sub-circles within a circle at about 4-5. Otherwise the number of people attending the meeting quickly jumps to over 10 people, which makes them exponentially more challenging to run.

Sadly, my high level takeaway is that Holacracy is an exciting but incomplete paradigm. And there’s some reason for pessimism since this omission was made by design. Let me explain:

Many of the principles and concepts that Holacracy is based on and consists of strongly resonate with me: roles as living and evolving entities, the radical distribution of authority through the circles-based org structure, the unique and highly effective governance and tactical meeting structure, even thinking about strategy as a set of heuristics rather than a high-level, executable plan.

The one principle that Holacracy takes too far, in my opinion, is the decoupling of “role from soul”. Holacracy accurately observes that under the traditional paradigm, four “spaces” are too tightly coupled:  the person space, the role space, the tribe space and the organization space. A good example is the traditional manager’s job being simultaneously responsible for both for the business outcomes accomplished by her employee (role space) and her employee’s professional growth and development (person space). The solution that Holacracy prescribes is radical decoupling, ignoring the fact that in cases of extreme decoupling, misalignment will lead to chaos. Holacracy explicitly takes the “human spaces” (left column, person+tribe) out of scope:


Or, to use a more familiar diagram to the readers of this blog:


Dealing with “human spaces” problems such as hiring/firing, compensation, growth, etc. is not part of the Holacracy “operating systems” but mere “add-ons/apps” that each business should figure out on its own, once they adopt Holacracy. Yet at the same time, it’s been acknowledged that Holacracy is at odds with traditional “human spaces” solutions, and the friction between the two is a key cause for some companies attempting to adopt Holacracy but failing to successfully do so. To go back to our manager example, Holacracy offers clear guidance on what to do with half of her traditional responsibilities, but leaves practitioners completely on their own about the other half. To me, that sounds like a classic case of mistaking a bug for a feature.

A fix for this bug, would require viewing the organization as a sociotechnical system, acknowledging that it has a human component that cannot be fully decoupled. The human systems that align with the process components of Holacracy have to be an integral part of the Holacracy “operating system” rather than an add-on “app”.

Note that none of this invalidates any other principles and concepts that are already an integral part of Holacracy. I am confident that Holacracy is a superior organizational paradigm compared to the traditional one. I’m just disappointed that its creators decided to “call it done” and draw the operating system/apps line where they did. I fear that only addressing half of the problem space will have a substantial negative impact on its adoption (and success) rate. To use another software metaphor, they seem to be building the right product, I’m just not sure they have a Minimum Viable Product. Yet.

Holacracy or Humacracy? (Book Review)

Holacracy’s Integrative Decision Making process

I think I’m getting close to coming full-circle on Holacracy. At first I was totally psyched by how radically innovative it is; then the skeptic in me kicked in and it seemed more like an idealistic framework that can never work in a large scale organizations. But the more I study it and similar approaches, it resonates with me more and more. I’m not ready for a full “why is Holacracy awesome?” post, but I do want to focus on one aspect of it that can potentially stand on its own merits:

Holacracy’s Integrative Decision-Making Process

It’s a structured process for making decisions in a group that rings truer to me than both consensus and top-down decision making (the two extremes of the spectrum).

Here’s the gist of the process:

  1. Present Proposal – proposer describes the problem that she saw and the solution she proposes
  2. Clarifying Questions – anyone can ask clarifying questions. Proposer can answer. No reactions or dialog allowed.
  3. Reaction Round – each person can react to the proposal as they see fit. No discussion or responses.
  4. Amend & Clarify – proposer can optionally clarify the intent or amend the proposal based on reactions. No discussion allowed.
  5. Objection Round – The Facilitator asks each person in turn: ”Do you see any reasons why adopting this  proposal would cause harm or move us backwards?” (an “Objection”). Objections are stated, tested, and captured without discussion; the proposal is adopted if none surface.
  6. Integration – The goal is to craft an amended proposal that would not cause the Objection, but that would still address the proposer’s  problem. Focus on each Objection, one at a time. Once all are integrated, go through another Objection Round.

Beyond the meta-benefit of a repeatable, structured, decision-making process the two things that I like the most about this are:

  • Separating getting clarify on the proposal, giving everyone an opportunity to be heard (react) and dealing with material objections into three separate activities. They address three separate needs for the people who are engaging with the proposal and deal with each one separately.
  • Defining a valid objection as something that would “cause harm or move us backward”. This is typically where consensus-based decision making tends to fail.  And also somewhat related to Fred Wilson’s recent post on satisficing  – by setting an agreed-upon acceptable threshold for proposals, we can avoid some of the major pitfalls that cause important decision-making processes to stall.
Holacracy’s Integrative Decision Making process