Turning Vision into Reality

The Gordian Knot - How You Frame a Problem Influences the Solution

The Gordian Knot - How You Frame a Problem Influences the Solution

Back in the last millennium, when I was a contract programmer, my customer asked me how long it would take to write a custom program he outlined for me. As I was getting ready to estimate the number of man-months and dollars, I remembered my Greek mythology and asked him what he intended to do with the program once I finished it. After he described the underlying problem, I told him I’d have his solution just as soon as I could drive over to CompUSA and purchase a readymade solution for $250. (A fraction of what a custom solution would have cost.) 

The father of the gods had ordained that when it came time for the people to select a king, they must choose the first person to ride up to the temple of Zeus in a wagon. Gordius innocently fulfilled the oracle’s prophecy and was made king.

One of Gordius’ first acts was to dedicate his wagon to Zeus and to place it near the temple, the yoke tied to the pole by an intricate knot of cornel bark. The knot was a complex Turkish knot, having no ends exposed. Hundreds of tightly interwoven thongs of cornel-bark made the knot an impressive centerpiece for the shrine. There it remained as an important symbol for the Phrygians.

Month after month the bark hardened, people speculated as to its purpose, and eventually, an oracle foretold that whoever loosed the Gordian Knot would lord over the whole of Asia. The lore grew and grew.

Would-be rulers would make a pilgrimage to the temple to untie the knot. All failed until Alexander the Great. Big Al walked up to the yoke, took his sword and with one mighty stroke, cut the knot away, revealing the yoke underneath.

Why did so many smart and ambitious men fail? In part it was because the way the challenge was framed in their minds. Most were asking themselves how can I untie the knot. Alexander reframed the question as how can I reveal the yoke?

When I was in charge of product development I had a sign on my desk that read “Bring me problems, not solutions.” I’ve found that most people don’t come to you with a problem to solve. They come to you for help in implementing their approach to solving the underlying problem. Always drill down to what the underlying problem is. You have a greater chance of coming up with a solution that optimizes your products and skills if you can correctly identify the underlying problem and then define the implementation approach.

A Gordian knot approach is one that cuts to the core of the underlying problem. Employees can learn to become better problem solvers. (It was formal Wilson Learning sales training that opened my eyes. The training led me to shift my focus to identifying and solving the underlying problem.) Good coaching should be part of a your performance review process.

Related Articles

Why is the Status Quo so Hard to Change?

“It can’t be done.” so said Director of Operations, Wally as we discussed how to increase capacity in anticipation of the projected surge in demand in the next year. “Employees will never accept a fourth shift. They won’t be willing to change their schedules. They won’t. I asked them why and they told me.” 

Strategic goals are strategic because they change the status quo. Why is it so hard in practice to actually implement truly strategic goals? Any time you endeavor to change things there’s a risk involved and the potential for loss. Loss carries two to five times the impact as a gain. When there is fear of the unknown, people have a tendency to bunker down… hold their ground. That’s one reason why changing the status quo can’t be accomplished with the heroic effort of just one person. It takes the sustained effort of a team. 

Read More
A Startup Needs to Look Like a Startup.

From the writings of John Myrna

I joined Scientific Time Sharing Corporation (STSC) in December 1969 as a programming elf. I was in the Army, stationed in Northern Virginia, with excess time on my hands. In grad school I had adapted a prototype Fortran implementation of the programming language APL to run on the college’s new SDS Sigma 7 mainframe computer system. I fell in love with the language, so it was only natural to see if I could moonlight for one of the three startups that were commercializing the IBM version of the APL timesharing system. In school, my graduate advisor and fellow grad students were convinced that APL was the greatest invention since sliced bread but… “It’s a shame that it will never make it as a commercial success.” (The APL language was known for its extensive use of Greek and mathematical symbols, a major departure from “English-like” languages like Fortran and Basic.) 

Read More
Productivity Gains Can Come from Small, Simple Changes

From the writings of John Myrna

When Scientific Time Sharing Corporation was founded in 1969, it had a problem. It had nine locations and only six full-time employees. How could they communicate and coordinate when there were seldom more than two or three people in the same location or place? The obvious answer was email. The first primitive version went live in January 1970, followed by a fully functioned system built on our ground-breaking APL*Plus shared file system. That email system, written by Larry Breed, became STSC’s central communications technology. 

Read More