I was about to name this post “Pillars of TOC”, but after second thoughts I believe these pillars are equally useful outside of their immediate Theory of Constraints context.

Do you need to be able to think more clearly? Or maybe you know someone who would benefit from clearer thinking?

Goldratt asserts the pillars described below as foundational to “clear thinking”:

  • Inherent Simplicity
  • Every Conflict Can Be Removed
  • People Are Good
  • Never Say I Know

Pillar: Inherent Simplicity

This first pillar is a choice. An intention to look at situations as if they were always inherently simple. As if the nature of reality itself is simple (and harmonious).

“Reality is simple and harmonious.”

If we choose to proceed as if this were true, then we will be less likely to get trapped in looking for sophisticated explanations and complicated solutions. We will be less likely to channel our attention towards just those things we allow ourselves to see.

“The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?”

~ Goldratt, Eliyahu M.. The Choice, Revised Edition (Kindle Locations 213-215).

For clear thinking, we must choose to proceed as if we accept the idea of Inherent Simplicity, as a practical way of viewing reality, any reality. We may even go so far as to choose this as our approach to life in general.

“The biggest obstacle is that people grasp reality as complex when actually it is surprisingly simple.”

~ Goldratt, Eliyahu M.. The Choice, Revised Edition (Kindle Locations 219-220).

So what exactly do we mean by Inherent Simplicity? In a nutshell, Inherent Simplicity is the cornerstone of all modern science, as stated by Newton: “Natura valde simplex est et sibi consona.” We may translate this as “nature is exceedingly simple and harmonious with itself”.

Note: Goldratt states that with the Theory of Constraints, he takes a “Hard Science” perspective in all situations.

In practice, this means examining the cause-effect relationships within a given situation. And, contrary to our intuition, where we would expect some form of combinatorial explosion of complexity to result, Inherent Simplicity (and Newton) tells us that the system will converge, and common causes will inevitably appear as we drill down. If we drill down deep enough, we’ll find just a very few, or maybe even just one, root cause. So the result of systematically examining the cause-effect relationships in a situation leads us not to enormous complexity, but to wonderful simplicity.

If you doubt this, take a look at this article explaining the relative simplicity of two systems.

Hint: If I’m a scientist or a manager, I’m not so much interested in how difficult the system is to describe, but more in the difficulty of controlling and predicting its behaviour, especially when changes are introduced. The scientist or manager’s definition of complexity is: “the more degrees of freedom the system has the more complex it is.”

We’re not claiming that reality is not overwhelmingly complex; we acknowledge it in full. But what we are claiming that we can see things more clearly, think more clearly, when we choose to proceed on the basis that reality is exceedingly simple.

Note: We may begin to see how this perspective renders the idea of “complex adaptive systems” irrelevant.

Pillar: Every Conflict Can Be Removed

Let’s come back to the earlier proposition about Inherent Simplicity, that “Reality is simple and harmonious (with itself).”

We may choose to interpret “harmonious with itself” to mean that there are no contradictions in nature. In the material world. In “reality”.

“There are no conflicts in reality.”

For example, if we measure the length of a rod, by two different methods, and get two different answers, we don’t compromise. We don’t say “let’s split the difference and use the average between the two methods”. The contradiction between the two methods signals us that somewhere along the line we have made an erroneous assumption of some kind. And so we’ll go looking for that flawed assumption, and never accept a compromise. Such is the strength of our belief that there can be no contradictions in nature.

But this pillar is about conflicts, not contradictions. A conflict can occur any time we have opposing requirements, such as the need for an aircraft wing to be both strong and light. All undesirable effects (in the cause-effect relationships within a given situation) stem from such conflicts.

So this pillar is about choosing to proceed such that we treat every conflict like a scientist treats a contradiction. Which means, examining the conflict to uncover the inherent erroneous assumption(s), and refusing compromise as a way out.

“Don’t accept conflict as a given.”

Note: All forms of optimising and optimisation fall into the category of “compromising”. Such a waste of everyone’s time and talents.

Pillar: People Are Good

With this pillar, we come back again to the idea of harmony. This time we’re interested in another obstacle to thinking clearly: blaming others.

“Blaming another person is not a solution.”

In fact, in many cases, blaming others points us in the wrong direction, away from a solution. Even if the person we blame were to be fired, in most cases the problem will remain. Blaming is a sure-fire way to undermine the harmony in our personal relationships.

And we need that harmony, so that we can collaborate effectively with other people (our peers, our suppliers, our customers) in finding the solutions we seek.

So, we choose to proceed with the deep conviction that harmony exists in any relationship between people (even though in most cases, by default, we don’t bother to find and implement it). We choose to proceed on the basis that

“Win-Win is always possible.”

This perspective allows us to think more clearly, and find solutions that work for all parties involved, not just one side. Yes, it’s more work, but it gives our solutions much more stickability.

And, incidentally, for effective harmonious relationships, we have to care about the people involved. We have to invest the time and effort into knowing them and their true needs (cf. The Antimatter Principle).

Pillar: Never Say I Know

When we choose to proceed on the basis that we know about a situation, we’re unlikely to seek improvements, to check for holes in our logic or understanding, or to believe that the situation can be improved.

So, let’s always proceed as if we DON’T know. This choice can help us think more clearly, examine the situation afresh, and discover different, more effective ways of doing the things that need doing.

“Every situation can be substantially improved.”


You may see the above pillars as largely philosophical, as a way of looking at the world. Personally, I choose to see them as pragmatic, as a way of interacting with the world. And, returning to the notion of harmony, we may begin to see how all these pillars complement each other, harmoniously.

Harmony: “the quality of forming a pleasing and consistent whole.”

– Bob

Further Reading

The Choice ~ Eliyahu M. Goldratt and Efrat Goldratt-Ashlag


Innovation ALWAYS Demands We Change the Rules

How do you feel about the proposition:

“Innovation can bring benefits if and ONLY if it diminishes a limitation”

Let’s examine this proposition. Do you agree with it? Don’t be too hasty in coming to agree with it. Once we agree, you’re hooked! So, let me explain a little more, starting with some definitions:


We’re talking here about all kinds of innovations. Not just tech innovations (new materials, new languages and tools, new industrial processes, new scientific discoveries) but other innovations too (new ways of doing things, new ways of structuring and managing organisations, new ways of developing products and software, plus many others).


What do we mean by “limitation”? A limitation here is anything that restricts us from getting our needs met to the maximum possible extent. (And btw that maximum is, itself, a limitation).

Limitations can be “recognised” (for example, a speed limit on a motorway) or unrecognised (for example the physical speed limit for a given curve, with a given vehicle, in specific road conditions).

Examining the Proposition

So, back to the proposition: “Innovation can bring benefits if and ONLY if it diminishes a limitation.”

Do you agree?

We were alive and functioning even before the innovation became available. Correct? It must be, then, that long before the new innovation, we developed modes of operation, modes of behaviour, policies, rules, to accommodate the limitation. I’ll refer to all these as simply “rules”.

We were able to operate. Rather than run smack into the limitation and die. That’s obvious.

Before the innovation, we created certain rules to cope with the limitation (recognised or unrecognised, known to us or unknown).

Suppose, then that we make a very good job of implementing an innovation, and thereby diminish the associated limitation totally. Still, the question is:

What benefits will any innovation bring, if we neglect to change the rules? The rules that helped us to accommodate the limitation, before the innovation was available? What benefits will we see if we neglect to change the rules?

Do you start to see the answer?

The Old Rules Block Any Benefits

What benefits will we see if we neglect to change the rules? Basically, no benefits. None. Why? Because as long as we obey the old rules – the rules that were there to bypass the limitation – for as long as we obey these rules, for all practical purposes we will continue to behave as if the limitation is still there.

Can it be that we’re so stupid that we continue to adhere to our old rules, the rules we originally invented to bypass or cope with the limitation? You know the answer.

This is what is happening every day, for the vast majority of organisations, and for the vast majority of innovations they adopt. For a long time after adopting the innovation we still obey the old rules. And because of this, for a long time we don’t get any of the real benefits from our investment in the innovation.

Four Not So Frequently Asked Question

So, how might we proceed if we need to ensure that innovations really do bring us the promised bottom-line benefits? We might choose to ask ourselves the following sequence of four questions:

Q1: What is the POWER of the innovation? (Just ask the inventors, they’ll be more than glad to explain, and explain, and explain…).

Q2: What limitation does this innovation diminish? (We must find a specific and precise answer, here).

Q3: What existing rules served to help us accommodate that limitation (i.e. what obsoleted rules we must get rid of)? Here we can for the first time evaluate the tangible bottom-line benefits from removing those old rules). (Note: As long as the old rules remain in force, we will never see the promised benefits from the innovation). Ch1 11:10

Q4: What (new) rules must we use now (in place of the old rules which the innovation has obsoleted)?

Let me give you an example. Let’s take Agile Software Development as our innovation.

Q1: What is the POWER of Agile Software Development?
A1: Agile Software Development increases the likelihood that we’re developing software that meets our customers’ real needs.

Q2: What limitation does Agile Software Development diminish?
A2:  Risk of misunderstanding customers’ real needs, both now and as they evolve.

Q3: What existing rules served to help us accommodate that limitation?
A3: Contractual terms. Big up-front specifications. Rigorous plan-driven project management. Change control. Specific duration projects. Formal V&V.  One-off or infrequent release into production.

Q4: What (new) rules must we use now?
A4: Development and delivery as experiments. Short, tight feedback loops. Constant collaboration between customers and developers. Constantly evolving specifications and solutions. Multiple “stop/continue” checkpoints. Incremental and frequent release into production.

Try It For Yourself

Here’s some other innovations we see introduced in e.g. software development organisations. Try running through the above four questions for one or more items on this list:

  • Teams / team-based development.
  • Obeya (big-room).
  • TPDS (Toyota Product Development System).
  • Lean Product Development.
  • Cost of Delay.
  • Flow.
  • Pyton, ELM, or some other new language or tool you may be considering adopting.
  • Self-organisation / self-management.
  • Servant Leadership.
  • Holacracy.
  • Serious Play.
  • Continuous Improvement.
  • [Your own favourite innovation].

We Must Change the Rules

“Human beings cannot progress unless somehow they do things differently today from the way they did them yesterday.”

~ Shigeo Shingo

So now we can see that the real effort we must make is NOT in adopting new innovations, but in changing the rules. And these rules are manifest in the assumptions-in-action, the collective mindset, the culture, of an organisation. This, btw, is the central message of Rightshifting and the Marshall Model.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Reliability and Effectiveness

Many times when presenting either the Rightshifting curve:

or the Marshall Model:

I have been asked to define “Effectiveness” (i.e. the horizontal axis for both of these charts). I have never been entirely happy with my various answers. But I have recently discovered a definition for effectiveness, including a means to measure it, which I shall be using from now on. This definition is by Goldratt, as part of Theory of Constraints, and appears in his audiobook “Beyond the Goal”.


Measurements serve us in two ways:

  1. As indicators of where we are, so we know where to go. For example, the dials and gauges on a car’s dashboard.
  2. As means to induce positive behaviours.

We must always remember, though, that we are dealing with humans and human-based organisations:

“Tell you how you measure me and I’ll tell you how I behave.” ~ Goldratt

We must choose measurements to induce the parts to do what’s better for the company as a whole. If a measurement jeopardises the performance of the system as a whole, the measurement is wrong.

Companies already have one set of measurements which measure their performance as a whole: their Financial measurements: e.g. Net profit (P&L) and investment (Balance Sheet)

What about when we dive inside the company as a whole, though? We then have two areas in which we have to conduct measurements:

  1. Support for and evaluation of management decisions
  2. Oversight on execution (how well are we executing on the decisions we’ve made?)

We generally don’t have good measurements in terms of decisions, nor good measurements in terms of execution.

We have to remember we’re dealing with human beings. And as long as we’re dealing with human beings, we have to realise that by judging any person on more than five measure, we’re creating anarchy. Simply because, with more than five measurements, people can basically do whatever they like, and likely still score high on one of them. And their bosses can nail them on some measurement they fail to deliver against. More than five measurements is conceptually wrong.

Categories of Measurement

So, how to categorise thing so that human beings can grasp the situation? Can we do better than we do now? Theory of Constraints suggests we can.

What resources do we have to help us formulate measurements in each of the above two areas; management decision-making, and execution of those decisions?

  • For decision-related measurements – there are lots of resources available to help e.g. books on Throughput Accounting.
  • For execution-related measurements – there is next to nothing published anywhere.

Continuous Improvement

I’ll not make the case for continuous improvement here. But if we wish to induce people to continuously improve, where should we focus our measurements? On things that are done properly, or on things that are not done properly? Which of these two foci better drives action? Focussing on the things we’re doing properly tends not to drive improvement. So we must concentrate on things that are not done properly.

How many things are not done properly? Kaplan suggests that in most businesses, there are more than twenty categories of things that are not done properly. But for humans to grasp our measures, we have already decided we need at most five categories, categories that completely cover everything that is not done properly, with zero overlap or duplication. Finding a way to categorise things that meets our criteria here is a nontrivial challenge.

Goldratt says there are only two categories:

  1. Things that should have been done but were not.
  2. Things that should not have been done but nevertheless were done.

Just two categories, with zero overlap. Beautifully simple.

And each of the above two categories already have a word defining them:

  1. Things that should have been done but were not – unreliability.
  2. Things that should not have been done but nevertheless were done – ineffectiveness.

Let’s swap these around into positive terms: Reliability, and Effectiveness.


Reliability and Effectiveness

Can we find measures to quantify Reliability and Effectiveness? How can we put numbers on our reliability? How can we put numbers on our effectiveness? Because, without numbers, we’re not measuring.

Let’s consider what is the end result of being reliable, in terms of the system as a whole. And what is the end result of being effective, in terms of the system as a whole? Not in financial terms though, as reliability and effectiveness are not financial things. We know this intuitively.


Things that should have been done but were not.

The end result of being unreliable, in terms of the system as a whole, is that the company fails to fulfil its commitments to the external world. In other words, the company fails to ship on time. Do we already measure on-time shipment? Yes. We call it Due Date Performance. That’s a measure of how much we ship on time. “Our company Due Date Performance is 90%”. The unit of measure is almost always “percent”. What behaviour does this unit of measure trigger? Does it trigger behaviour that is good for the company? No. It encourages us to sacrifice on-time shipment of difficult, larger shipments in favour of smaller, easier shipments. So the dollar value of the sale must be part of any reliability measurement. We cannot ignore the dollar value. And neither is time is a factor in percent units. How late is each late shipment? We must include time, too. So, let’s change our “Reliability” units from “percent” to “Throughput dollar days” – the sales dollar value of each orders that is late, multiplied by the number of days it is late, summed across all late orders. The sum total is the measurement of our (un)reliability.

This is of course  a new unit of measure: Throughput-dollar-days. To infer trends, or to compare the performance of e.g. groups or companies, we will need time to train our intuition in the significance of this new unit of measure. As we begin to get to grips with this new unit of measure, it can help to present it as an indicator (a number in some fixed range, say 1-10, or as we use in Rightshifting, and the Marshall Model, 0-5) until we have adjusted to the Throughput-dollar-days measure.


Things that should not have been done but nevertheless were done.

If we do things that we should NOT have been doing, what is the end result? Inventory. Do we already measure inventory? Of course we do. But how do we presently measure inventory? Either in terms of a dollar value, for example “$6 million of finished good inventory”, or in terms of a number of days, for example “60 days of finished goods inventory”. But both dollars AND time are important. Existing units of measurement for inventory drive unhelpful local behaviours like over-production and poor flow. So, how to measure to induce helpful behaviours? For each item of inventory, let’s use the dollar value of the inventory multiplied by the number of days that we’re holding that inventory under our local authority. We’ll call this unit of measure “Inventory-dollar-days”.

And one more measure of effectiveness: local operating expense. (For example, scrap, or salaries – with a given subunit of the company).

Note: We can fold quality into these measures simply by not recognising a sale, or a reduction in inventory, until the customer accepts the items (i.e. until the items meet the customer’s quality standards).


Now we have means for defining effectiveness, (and reliability) in a way in which we can also measure it. I feel very comfortable with that.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Relevance Lost: Rise and Fall of Management Accounting ~ Kaplan & Johnson

The Goal ~ Eliyahu M. Goldratt

Throughput Accounting ~ Thomas Corbett

The Balanced Scorecard: Translating Strategy into Action ~ Kaplan & Norton

Strategies, Effective and Ineffective

[Tl;Dr: The effectiveness of any organisation is a function of the alignment between folks’ collective beliefs and assumptions about business, and the realities of business.]

I’m not sure this post is going to tell you anything new, but I did hear recently someone appear to misunderstand one of the the basic premises of the Marshall Model. So, for the benefit of clarity…

The Marshall Model – Recap

The Marshall Model asserts that there are four basic collective mindsets in organisations. For ease of reference, the model labels these collective mindsets, in order of increasing effectiveness: Ad-hoc, Analytic, Synergistic and Chaordic.

These various collective mindsets – and by “collective” I mean shared, more or less, by everyone within a given organisation – dictate the strategies in use in that organisation. And by “strategies in use” I mean, when making every kind of decision, from the most senior manager to the lowliest worker, the approaches used to make or inform those decisions.

Put another way, in any organisation, a multitude of decisions come up every day:

  • Which and what kind of business opportunities to pursue.
  • Who to please (and who to ignore or disappoint).
  • Which market segments to focus on.
  • How to serve those markets.
  • How to finance the business.
  • What kinds of people to hire (and fire).
  • Which trading partners to work with (and which to compete against).
  • HR policies.
  • Management policies.
  • Sales methods.
  • Engineering approaches.
  • Budgets.
  • And on and on.

How to decide? Most always, folks will approach making these decisions within the frame of their existing beliefs and assumptions. Existing beliefs and assumptions which have become the basis for their more or less automatic responses. Kahneman calls these “fast” or “system 1” responses.

And various psychological pressures conspire to ensure any one person’s beliefs and assumptions remain “congruent” with the collective assumptions and beliefs of the organisation as a whole (for example, nobody wants to be seen as an outsider).

The Effectiveness Lever

Any organisations where people work together are by, their nature, complex adaptive systems.

The Marshall Model implies that relative organisational effectiveness is a direct function of how closely the prevailing collective mindset matches the reality of organisations. If the prevailing collective mindset enables decision-makers to choose approaches and strategies well-suited to the realities of complex adaptive systems, those decisions will be more likely to be effective. If the prevailing collective mindset constrains decision-makers to approaches less well-suited to the realities of complex adaptive systems, those decisions will be more likely to be ineffective. Both as individual decisions, and in aggregate.

So, it’s not the organisations that are Ad-hoc, Analytic (a.k.a. mechanistic), Synergistic or Chaordic systems. It’s the collective thinking of the people within those organisations that conform to one of these four labels. The organisations themselves are always complex adaptive systems. And, for the clients I work with, collaborative knowledge work systems, too.

I hope this post has served to clarify. Would you be willing to let me know whether it’s achieved that aim? And for the sake of further clarity, I’m happy to address any and all questions that this post might bring to mind.

– Bob

Further Reading

Thinking, Fast and Slow ~ Daniel Kahneman

On Espoused Theory, Theory-in-Use, and “Effective Theory” ~ Mark Federman (blog post)

Antimatter Hiring

When we’re hiring, why not invite candidates to actively demonstrate the core capabilities that our organisation, group, or team, needs?

Asides: How often do hiring managers know what core capabilities the organisation, group or team needs? How often are they capable of recognising and assessing candidates on those capabilities? And how aware are they of the impact the prevailing system conditions (the way the work works) has on a candidate’s ability to apply their capabilities, should they be hired?

We Want to See Jugglers Juggle

When we’re hiring e.g. coders, we’ll generally ask to see them write some code. When we’re hiring analysts we may ask to see them analyse something. When we hire testers, we’ll likely ask to see them test something. Etc..

The Antimatter Principle proposes that the core capability in all collaborative knowledge work is the capability to attend to folks’ needs. Which, by the way, implies the capability to discuss and more-or-less clearly identify those needs, as well as the capability to subsequently find effective ways to address those needs.

Under this premise, the ideal candidate would open the interview conversation with

“Hi there, what would you like to have happen, here and now, today?”

Or more directly/explicitly (at the risk of alienating the uninitiated hiring manager),

“Hi there, what needs do you have of this interview, that I might be able to attend to, here and now, today?”

To which the cooperative hiring manager might reply,

“Well, as we’re hiring for [e.g.] coders at the moment, I need to understand how capable you would be in that role if you joined us. Can you suggest some ways in which you might be able to address that need, here and now, today?”

Prompting and Reframing

I guess you’d say that the preceding dialogue is, however, most unlikely. Most candidates will not be seeking to understand the hiring manager’s needs, nor will they know how acceptable – or unacceptable – such an opening gambit might be. Much more likely, they’ll play safe and let the hiring manager lead them through the interview conversation.

So, until the world changes and conversations of the kind I’ve illustrated become the norm, the hiring manager may have to prompt the candidate, and reframe the conversation at the beginning, to open the door, so to speak. Here’s a modified opening exploring this approach:

Hiring manager:

“We believe that attending to folks’ needs is a core capability we absolutely have to hire for in all our candidates. I’d like to experience you demonstrating your capability in that area.”

“As we’re hiring for [e.g.] coders at the moment, I have a need to understand how capable you would be in that role if you joined us. Can you suggest some ways in which you might be able help me understand your coding abilities, here and now, today?”


If we focus explicitly on the capability to attend to folks’ needs, we might improve our chances of actually making job offers to candidates that have this capability. Surely this is the outcome we seek?

Recap for New Readers

The Antimatter Principle is “the only principle we need for becoming wildly effective at collaborative knowledge work.”

Stated simply, the Antimatter Principle says:

“Attend to folks’ needs.”

Over the years, I’ve blogged about a wide variety of the deep implications, and impacts, stemming from the application of this principle.

– Bob

Further Reading

The Antimatter Principle ~ Think Different blog post

Wanna See Me Juggle? ~ Think Different blog post

Coaching, Scrum Mastering, and Expertise

[Tl;Dr: Is it more, or less, effective for coaches, etc. to have technical (non-coaching) abilities?]

Over the years I’ve heard every kind of opinion on whether technical expertise is an asset or liability for coaches, Scrum Masters, and the like. Some folks, mainly executives, have sworn they would never hire a Coach or Scrum Master with technical expertise. Others, mainly coaches and Scrum Masters, have held much the opposite opinion. Those being coached have rarely expressed an opinion (although I suspect that’s because they don’t get asked, or think it won’t count, and not because they’re indifferent on the subject).

Personally, I tend to the opinion that, if it were down to me, I’d look for folks with excellent and demonstrable coaching skills, and not worry about the presence or absence of technical abilities unless they seemed intrusive and likely to interfere with the coaching dynamic. I recognise the argument that technical people lend more credibility to like-minded (i.e. technically capable) coaches because they find it easier to respect and identify with such folks. I also believe this argument to be a red herring, at least in the case where the coach or Scrum Master is effective and capable in the Coaching or Scrum Mastering skill-sets.

This is probably a good place to mention the Inner Game, and the suggestion by one of its founders, Sir John Whitmore, that “technical” knowledge and experience is a decided handicap for coaches and the coached, alike. In his book “Coaching For Performance” he tells several stories about this phenomenon, in particular that of the tennis group who, deprived of their regular tennis coach (and tennis expert) improved much more quickly under a substitute coach (with much coaching and skiing experience but no tennis experience).

Given that opinions on this topic seem all over the map, and many (mainly fruitless) discussions continue, I wonder if you have any experiences you’d be willing to share here?

– Bob

Further Reading

Coaching For Performance ~ Sir John Whitmore

The One Perfect Way to Develop Software

[Tl;Dr: Being a Master of the perfect way to develop software is more of a handicap than an asset.]

Let’s imagine you’ve received a Matrix-style download of all the knowledge and skills necessary for Mastery of the perfect way to develop software. And you’ve applied this knowledge, and honed the skills, in several or many software development endeavours. And have the results to prove it.

Then you join a new-to-you organisation, and a new-to-you team, where of course you want to share your profound, highly valuable insights, capabilities, knowledge and skills with your peers, with a view to you all basking in the sweet success of the One Perfect Way.

Setting aside secondary issues such as the probability that there is no ONE perfect way, and that software development per se is maybe not what our customers are really interested in, what could possibly go wrong?

I’ll leave this question hanging. If I receive some expressions of interest, I propose to return to it in a future post.

– Bob

Further Reading

Characterizing people as non-linear, first-order components in software development ~ Alistair Cockburn


%d bloggers like this: