“Putting the cart before the horse” is an idiom expression that’s been around seemingly forever–couldn’t find its original source on the internet. By definition it means to do things, or tasks, in the wrong order, or with the wrong priority. It also means that one has confused cause and effect. It can also mean to slow down and take things as they come, not to try to rush to finish something. Obviously, the meaning of the phrase is based on an assumption that it is usually easier to pull than to push–not just when using a horse. From a workplace perspective it is also better to pull than to push work through a system. Exactly what that means is the subject of another post, so I won’t get into that here, but suffice to say that “pull” systems are the cornerstone of efficient manufacturing.
The basis for the phrase comes from the Greek term, “Hysteron Proteron” which means: “latter before.” A hysteron proteron occurs when the first key word of an idea, or phrase, refers to something that happens temporally later than the second key word. One would purposely do this if the goal is to call attention to the more important idea by placing it first. An example of hysteron proteron encountered in everyday life is the common reference to putting on one’s “shoes and socks,” rather than “socks and shoes.”
Thus the phrase, “putting the cart before the horse,” probably came from someone wanting to make a point using the hysteron proteron concept. There’s no record of exactly who that someone was, or is, however I’ll bet it was born in the world of business. From a workplace perspective it means that you should not execute a step of an operational plan before the preceding steps are completed. In other words, keep the steps in order (unless they can truly be done concurrently or at any time in the overall sequence of steps) and don’t jump ahead. Of course that implies that, in fact, you actually have a plan, which is part of the problem many organizations face–they fail to plan accurately or appropriately.
Many organizations actually suffer what’s called the “Cart before the Horse Syndrome.” How does this syndrome manifest itself? The Cart before the Horse Syndrome most often means that someone is focusing too many resources on a stage of a project out of its sequence. The sad thing is that many bosses, high and low, are so busy giving direction and orders that they fail to realize whether they are putting the cart before the horse. Many times they will pressure for a task to be done before needed in the belief that that means making progress, not realizing that there may, in fact, be a negative cause-effect relationship between the task and other tasks. Once they get to the other tasks the dependency becomes obvious and the first task needs to be redone or modified.
Add to this the learned helplessness talked about in last week’s post where the employees decide to leave their brainpower at the door as they enter the workplace and you have the recipe for an organization that is “running around in circles’ (another common idiom probably born in the workplace).
Many management teams fall prey to the “putting the cart before the horse syndrome” because they have a record of practicing what’s called “anti-patterns” in how they react to everything from normal everyday operation , to solving problems, meeting tight schedules, or reacting to anything that threatens their grip on power. An anti-pattern is a common response to a situation that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by Andrew Koenig, was inspired by a book, Design Patterns, in which the authors highlighted a number of design patterns in software development that they considered to be highly reliable and effective. According to the authors of Design Patterns, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea.
According to Koenig, for an anti-pattern to exist you first must have a commonly used process, structure or pattern of action that despite initially appearing to be an appropriate and effective response to a problem typically has more bad consequences than beneficial results. And second, a good alternative solution exists that is documented, repeatable and proven to be effective. This makes sense from my experience. Many organizations think that they are approaching a problem correctly only to find that their solution has more negative effects than they anticipated.
The second reason is an interesting one as it implies that this “documented, repeatable and proven” method is known to management at the time they decide to follow the pattern of action that has bad consequences. This explains why many organizations “do the same things over and over somehow expecting a different result.” Doing the same things over and over somehow expecting a different result is also called the “Golden Hammer Solution.” Every organization has their “golden hammer” which is a favorite solution that they feel is universally applicable to all problems. An example may be organizational reorganization as a repeated solution to bad management–but that’s the subject of another post.
I found an example on the web using software development: “in object-oriented programming, the idea is to separate the software into small pieces called objects. An anti-pattern in object-oriented programming is a large object which performs a lot of functions which would be better separated into different objects.”
Thus “real design patterns” are common approaches to common problems which have been formalized, and are generally considered a good development practice, and “anti-patterns” are the opposite and are undesirable.
Anti-patterns can also be understood through what’s called ‘The Second System Syndrome.” A second-system effect refers to the tendency of small, elegant, and successful systems (or projects) to become elephantine, feature-laden monstrosities due to inflated expectations. The Second System Syndrome was first used by Fred Brooks in his classic book The Mythical Man-Month. It refers to a condition where despite the fact that a first system can be successfully implemented which works well enough, designers turn their attention to a more elaborate second system, which is often bloated and grandiose and fails due to its over-ambitious design. This is also an example of the “polish the cannonball syndrome” that I described in an earlier post.
When The Second System Syndrome sets in projects go into what’s called “The Death March.” A project in its death march is one that everyone in the organization knows will be a disaster–except management. Thus the truth is hidden to prevent immediate cancellation of the project. Since the truth remains hidden the project is artificially kept alive until the final reckoning day comes and the stuff hits the fan.
When supporting the status quo (keeping the project alive) is cherished before truth telling (letting the project die it’s deserved ignominious death) we have a perfect example of a hysteron proteron. Status quo should be based on truth, not truth on the status quo.
Leave a Reply