Why the concept of “Constraint” is ill-defined in the “Theory of Constraints” community

12 April 2026

Embarassingly, the definition of the word “Constraint” is the subject of ongoing debate in the “Theory of Constraints” community.

This is embarrassing because, hey, it’s in the name! And because we are supposed to bring a scientific approach to management practice. Eli Goldratt was a physicist, after all.

I believe the lack of clarity stems from the difference between how Eli introduced the concept of Constraint in his runaway bestseller (The Goal) and how it is best applied in real-world environments.

This problem is amplified by the fact that the most active practitioners of TOC are not necessarily the most prominent voices in the online communities.

Two perspectives

In The Goal, the protagonist identified his factory’s Constraint as part of a process of discovery. Echoing this, most folks go looking for the Constraint in their organization after reading The Goal. And, much of the commentary in the TOC community centers around “How to find the Constraint?”, “What is the nature of the ultimate Constraint?”, and so on.

However, as someone who implements these ideas for a living, in a diverse range of organizations across many continents, and someone who is held accountable for results, I’d like to emphasise that I never, ever go looking for the Constraint in a client’s business.

I most certainly never participate in debates about exotic Constraint types (the market, policies, management attention, and the like).

And, I don’t think I’m alone (at least among practitioners)!

I define the “Constraint” as the one resource that, when fully loaded (or loaded to the maximum extent possible), will result in optimal profitability for the organization (relative to all other resources). This resource is always physical (it’s never a bad policy), and it’s always internal (it’s never the market).

The difference between these two perspectives is that the first is concerned with where the Constraint IS and the second, with where the Constraint SHOULD BE.

The pursuit of simplicity

As can be verified from a brief review of discussions across various TOC groups, the former approach leads to a descent into complexity and debates that are almost religious in nature.

The latter approach leads to simplicity.

I favor simplicity for a couple of reasons. The first is that Eli Goldratt’s mission was to show that business is inherently simple, and I’d like to honor that mission. The second is that simplicity is a critical attribute of the solutions that I (as a management consultant) deliver to clients. Sadly, our clients tend to be unprepared to pay a premium for complexity!

Brute force as a management approach

To truly appreciate the importance of simplicity, it’s important to recognize that a business is a complex system. Within all but the smallest of businesses, you have specialization, dependency, variability, and all manner of feedback loops.

Furthermore, businesses, by their nature, are goal-seeking systems. This means that management has a responsibility to take these complex systems and run them flat out (pedal to the metal)!

The combination of “complexity” and the “pursuit of maximum output” results in chaos being every business’s natural state. Because chaos is not good for business, management’s primary responsibility should be to try to maintain the business in an orderly state. But this is incredibly difficult, particularly given that the obvious (but devastatingly wrong) approach to profit maximization is to pursue peak efficiency in every department of the organization.

One of Eli Goldratt’s critical insights was that the fundamental difference between a chaotic and an orderly organization is that in the former, the bottleneck wanders from resource to resource, whereas in the latter, the rate-limiting resource is always the same.

This realization leads to a powerful two-step approach to performance improvement.

First, if a business is chaotic, restore it to an orderly state by ensuring that one resource is fully loaded and that all others have “protective” capacity. And second, to maximize profitability, ensure that the fully-loaded resource is the one that contributes the most to the organization’s profitability.

Now, here’s the thing. If a business has good fundamentals, it’s obvious, at a glance, which resource (out of the tens, or hundreds, of contenders) should be the one that’s fully loaded (or loaded to the maximum possible extent).

In an airline, for example, it’s the aircraft! In a restaurant, it’s the chairs. And, in a contract painting business (you’ll never guess this), it’s the painters.

The idea that you would encounter one of these businesses—or any business, for that matter—and embark on a quest to find the Constraint is frankly silly! It’s silly because it should be obvious. And it’s silly because if it’s not obvious, the business is almost certainly chaotic, meaning that the bottleneck is going to be a different resource each time you check.

So in my world, the Constraint is not a rate-limiting resource that you FIND. It’s the rate-limiting resource that you SELECT.

Identifying the Constraint (my definition) is, therefore, the easy part. The hard part is restoring the organization to an orderly state.

In the TOC world, we do this in three shockingly effective steps. We choke the release of work until the environment becomes non-chaotic. We then synchronize the release of new work with the rate at which the designated Constraint completes tasks. And then, if we discover that the environment is at risk of becoming chaotic again, we deploy massive action to add (or free up) capacity across all non-Constraint resources.

It offends some of the more sensitive souls in the TOC community when I say that we brute-force organizations into an orderly state, but I think Eli would have appreciated that characterization of his contribution (that brute force is the most elegant solution)!

Resolving the two world views

Now, I can anticipate a response to the brute-force approach I described above.

Some might (and almost certainly will) argue that my “massive action” step requires that the current bottleneck be found, exploited, and elevated multiple times before the system is migrated to its optimal state, with the Constraint established as the enduring bottleneck.

This is true. But my response is that one’s INTENT has a meaningful impact on exactly how one goes about maximizing a business’s performance.

Those who view the desired end state as the result of a journey of exploration and those who view the result as obvious and the journey as a necessary evil will almost certainly adopt a different mode of operation.

If you agree with this, then I would counsel you to choose your definition of “Constraint” very carefully. The definition, to a large extent, determines the mode of operation.

Here’s my definition again for your consideration.

If you’re tempted to remind me that mine is not the “official” definition of Constraint within the TOC community, I will respond, with customary deference, “Exactly, that indicates the magnitude of the problem!”