Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 7 Issue 2, Spring, 2003
Litt's Process Hypothesis
Copyright (C) 2003 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist and Rapid Learning: Secret Weapon of the Successful Technologist.

[ Troubleshooters.Com | Back Issues | Linux Productivity Magazine ]

There's a way to do it better...find it -- Thomas Edison


Editor's Desk

By Steve Litt
What makes us successful? Is it inborn ability? Is it intelligence? Is it knowledge?

I'm proof that it's none of the above. I went from the worst Troubleshooter to one of the best in a year. My inborn ability didn't change, nor did my intelligence. Did my knowledge change? Yes, but which knowledge?

My knowledge of electronics improved, but not all that much. What changed completely was my knowledge of the process of troubleshooting. In August I knew nothing of process, and was #38 of the 40 technicians in the region. The following August I consistently used a divide and conquer process to troubleshoot, and I was #4 out of 40. As the years went by I expanded that simple divide and conquer process into the Universal Troubleshooting Process, a process capable of quickly solving any problem in a well defined system.

A few years later I developed a process to obtain programming contracts, and a few years after that I expanded that process into what I now call theRapid Learning Process, which I've repeatedly used to learn new technology in days instead of weeks.

Based on my experiences, I'm ready to state Litt's Process Hypothesis:

Litt's Process Hypothesis
If you consistently use an effective process for a given activity, you will be consistently successful at that activity.

Stated like that, it sounds obvious. But it were really obvious, everyone would use a process every time. In fact, most people go year after year "winging it" rather than using process. Some succeed, some do OK but not up to their potential, and some fail.

This issue of Troubleshooting Professional Magazine discusses this hypothesis, from many different angles, in order that you can optimally apply it to your life. So kick back, relax, and remember -- if you're a Troubleshooter, this is your magazine.
Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Necessary or Sufficient?

By Steve Litt
Let's take another look at the hypothesis:

Litt's Process Hypothesis
If you consistently use an effective process for a given activity, you will be consistently successful at that activity.

Does this hypothesis state that you need an effective process to succeed? No it does not. Effective process is not necessary.

Does it state that if you consistantly use an effective process you will not fail? Yes it does. Effective process is sufficient.

Now we see why this piece of common sense is not so common, nor is it obvious. Many people succeed through prodigious intelligence or other natural gifts -- no process needed. If you don't separate success factors into sufficient and necessary, finding the factors of a success formula would seem like finding a needle in a haystack.

If process were both necessary and sufficient, this hypothesis would truly be obvious. But given the fact that may people succeed without process, because process is not necessary, most people miss the connection. How many times do you hear phrases like these:
  1. Either you can troubleshoot or you can't.
  2. Troubleshooting ability is something you're born with.
  3. You can't teach troubleshooting.
  4. We need a great troubleshooter, so let's get a TCP/IP guru.
The preceding phrases result from observation of people achieving success from natural abilities, rather than process. What they overlook is the fact that because process is sufficient, it's a guarantee of success.
Steve Litt is the creator of the Universal Troubleshooting Process.  Steve can be reached at Steve Litt's email address.

The Secret of Awareness

By Steve Litt
In the preceding article I said that process is not necessary for success. Perhaps I was hasty making that statement.

I think if you watch any consistently successful person, you'll see them consistently performing similar tasks, in a similar order, over and over again. These successful people might tell you they're working "by instinct", or "by gut feeling", or "you just have to do it", but in fact, if you watch them enough, you'll see many repetitive patterns. Could it be that these people are succeeding through process, but aren't aware of that fact? I think it could.

The successful person might believe each desired outcome is different, and therefore he is operating differently each time. But observe this successful person, and you're bound to notice the same action sequences repeating themselves. What's going on is that this person has deduced which parts of the job at hand are common to previous jobs, and for those parts he or she has used known-good processes.

For instance, Thomas Edison invented the lightbulb, the electric motor, the motion picture camera, and a rock crusher for obtaining ore. On the surface, these have nothing in common except that they all worked with electricity. But look a little deeper and you see that Edison had processes for invention itself. Look at some of these Edison quotes:

Genius is one percent inspiration, and ninety-nine percent perspiration.
I'll try anything...I'll even try Limburger cheese!
Everything comes to him who hustles while he waits
There's a way to do it better...find it
Opportunity is missed by most people because it is dressed in overalls and it looks like work.
Nearly every man who develops an idea works it up to the point where it looks impossible, and then he gets discouraged. That's not the place to become discouraged.

Read these quotes, and we can almost feel Edison's process. He's not too proud or analytic to try anything, even Limberger cheese. His genius is 1% inspiration, and 99% process (he calls it perspiration, but it's the repetitive stuff). When stopped on one project or task, he hustles on another project or task while he waits for the first. He regularly asks the question, "what's the better way?". And when he hits a brick wall (it looks impossible), he's been there before, he knows there's something beyond the brick wall, he doesn't get discouraged, but instead finds a way to bust through that brick wall.

These quotes tell us something else. Edison was aware of his process. Ask a typical successful person how he's successful, and he'll tell you he's smart, or he just follows his gut, or he works hard, or he's lucky. Or maybe he'll tell you a couple tips that, by themselves, would not result in success. Most successful people aren't aware of how they create success.

Interestingly, our society respect those who instinctively succeed. In other words, those who are unaware of their success formulae. "He's a natural". "He's a born leader". The aware among us encounter fainter praise: "He's has book knowledge". "90 day wonder".

And why not. Instinct is faster than logic. If you need an immediate decision, there's no time for process.

In fact, modern human potential wisdom states there are four stages of competance, listed below, in increasing order of true competance:
  1. Unconscious incompetance
  2. Conscious incompetance
  3. Conscious competance
  4. Unconscious competance
Indeed, unconscious competance is what's needed to instantly do the right thing. But it's a two edged sword.

What happens when the job or the environment changes? Suddenly, those long practiced and perfected "moves" don't work. The person drops all the way back to conscious incompetance, or possibly even unconscious incompetance if the "moves" still work, but not well enough. There's a necessity to achieve conscious competance through analytical thought, but the "natural" long accustomed to reflexive success has little recent practice at such self-evaluation. The result is often a precipitous slide from success, often accompanied by bitterness (that object oriented programming is stupid).

Even without a change in environment or job, all too often unconscious competance allows bad habits to creep in unchallenged, resulting in a slump. Whether the activity is sales, or baseball, or troubleshooting, all too often the stage that follows unconscious competance is a slump.

To take care of the conscious part of competance, professional athletes have a coach. When they start to slump, their coach points out the cause of their declining performance, quickly getting them on track. But you and I have no such coach -- if we don't take care of the conscious part of competance, we doom ourselves to endless cycles of slumps, excess analysis, and success.

The hot tip is to perform familiar tasks reflexively, and yet be aware of what makes our performance superb, so that when something changes, we can get back on track. No matter how good we are, we need to be aware. Aware of our goals. Aware of our tools. Aware of our environment. And most important, aware of our habits and processes.

The Universal Troubleshooting Process is an excellent example. Most successful troubleshooters use it, to a degree, whether they know it or not. Those who use the UTP unconsciously usually perform as well as those who consciously use it. But give them a really nasty problem to solve, and the performance difference between the aware and unaware UTP user becomes painfully obvious. While the unaware UTP user goes in circles, gets mad and panics, the aware UTP user asks "how can I narrow this down just one more time", finds a way, and solves the problem.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist . He can be reached atSteve Litt's email address.

Process Questions

By Steve Litt
When confronted with a job you don't know how to do, or don't do well, I suggest you ask yourself two questions:
  1. Do I really need to do this?
  2. How do I develop an efficient process for performing this job?
The first question is obvious. Nobody's good at everything. Sometimes the best way to get a job done is to have an expert do it. Other times the job isn't important enough to do at all, given the cost of doing it. In such cases, you don't need to do the job, so you don't need a process to do that job. Obviously, if your employer assigns you to do the job, you really need to do it, so you might as well make it as easy as possible.

Assuming you really need to do the job, you need an efficient process by which to do it. Efficient processes don't appear out of thin air, so it's not enough to ask what is the proper process. You are responsible for finding or developing the process, so you must ask yourself how to develop it. Read on...
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

Developing an Effective Process

By Steve Litt
Diagram of the process development process

Developing an efficient process is incredibly difficult -- much more difficult than improving an existing efficient process. For that reason you should try to find a ready-made process that fits the bill. Sure, that ready-made process might not be totally optimized, and it might not fit your personality or situation perfectly, but it's a much better starting point than no process at all. Some places you can find ready-made efficient processes include:
The concept is simple, but the devil is in the details. Deep thought is often necessary. To succeed, just keep a constant awareness of your process and that of others you see, and be ready to make a change when you find something better.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist . He can be reached atSteve Litt's email address.

Maintaining and Improving Your Process

By Steve Litt
After you find a process, what now? Is it the optimal process? Probably not. And even if it is optimal, changes in the marketplace or environment will quickly render it suboptimal. Processes must be maintained and improved.

There are two kinds of process improvement:
  1. Refinement
  2. Redesign
In the quality world, refinement would be called "constant improvement". It's an iterative incremental process of tiny improvements. Here's the flowchart:
Flowchart of process refinement

Refinement is easy because there are many small steps with lots of feedback. The results are typically easy to measure. Refinement requires little mental effort -- it's usually reasonably obvious.

Refinement is wonderful when the current process is reasonably close to optimal, and the current process is stable and well understood. However, if the current process is "seat of the pants", or not well understood, refinement becomes much more difficult. If the current process is seriously suboptimal, it's very likely that no amount of "tweaking" would make it optimal. In such cases, you might need to redesign.

In the quality world, redesign would be called "reengineering". You completely replace the process or a substantial portion of the process with a completely different process. At least three different methods could be employed to redesign:
  1. Rigorous design
  2. Inspiration
  3. Emulation
Rigorous design means designing the process much like you would a computer program, an electronic circuit, or a project. The design process itself requires a process. So you have two levels of process abstraction. Redesign is not for the feight of heart.

Inspiration is a "Eureka" type experience. Once you've recognized that the process needs improvement, your subconscious mind starts to work on the problem. Sometimes your subconscious mind finds a solution.

Emulation is occurs when you seek out others to see what processes they use, and when you see a great process or subprocess, you adapt it to your own needs. This is certainly easier than redesign, and is more likely to succeed than either redesign or inspiration.

Redesign carries a heavy risk of failure -- even to the point where the new process is worse than the old. Don't abandon refinement unless refinement's hopeless.


The previous section mentioned emulation as a tool in redesign. In fact emulation can also be used in refinement. In both refinement and redesign, emulation is an extremely powerful tool. For best results, emulate early and proactively.

Watch people work. Observe what they do, and try to understand the process they're using. Silently critique their efficiency, and if their efficiency is high ask yourself how you could use similar techniques in your own work. As I'll discuss later in this article, techniques might be transferrable even though your work is totally different from theirs.

Sometimes the steps you want to emulate are tiny. For instance, you might lose lots of time by dropping screws. You then might observer a technician with a tub of quake wax right on his bench, dipping his screwdriver into the quake wax just before affixing a screw. This tiny distinction could save you 5 minutes per repair.

Watch others work, and really think about what you're seeing. I guarantee you'll find ways to improve your own work.

An Emulation Example

During the recession of the early 1990's I saw a street artist make $80.00/hr. As a dense crowd looked on, he painted a custom painting every 15 minutes and sold it for $20.00. The women in the crowd raved about his artistry and the men loudly proclaimed they'd gone into the wrong line of work. I watched intently, trying to understand his process. After 2 hours I understood his 3 step process:
  1. Figure out the goal
  2. Use tools
  3. Employ riffs to maximize efficncy of those tools
He spent a couple minutes interviewing the customer to find out what was wanted, and adapt that to what his tools and riffs could quickly accommodate. Interestingly enough, although his paintings were custom, they were all nature paintings with stars, water and fish. He didn't begin to paint until he understood what was needed. The goal.

His use of tools was artistry in itself. A stencil for a school of fish, another stencil for highlights on those fish. Lots of spray paint, rags, and brushes. He knew where every tool was, and he cleaned and put away every tool after every use. He never spent time looking for a tool.

Riffs are quick reflex actions. To paint the sun he'd spray a blob of yellow, cover it with the bottom of a spray can, spray blue sky all around, and then smudge the edges slightly with a rag. Ellapsed time: 10 seconds. To make a comet he'd spray a blob of white and then streak it with a rag to make the comet's tail. 5 seconds.

In hindsight it sounds easy to synthesize his process to the three step generality, but in fact it took me two hours. As far as I know, no other spectator suspected they could use The Artist's methods in their own work. Hence the covetous remarks about his income.

I went home, and within a week I had used Goal, Tools and Riffs to double the speed of my technical writing. A couple years later when I started Troubleshooters.Com, I consistently used The Artist's 3 step process to quickly crank out web content.

Be on the Lookout

The most important advice I can give you is be on the lookout. Whenever you see anyone working, watch them. See what they do efficiently, and think about how you could use their methods in your work. See what they do inefficiently, and ask yourself how it could be made more efficient.

If appropriate, talk to people about their work. Ask them to explain how they do it. They might have insights you can't deduce just by watching. On the other hand, many people work very efficiently but don't have the slightest idea as to the process they're using. In those cases you might want to reveal to them how they're working miracles. Expect an interesting discussion.

Modes of Improvement

What are the modes by which you can improve a process? For all I know there are hundreds, but I can think of three right off the bat:
  1. Speed up a task
  2. Increase concurrency
  3. Reduce rework
Speeding up a task is straightforward. Referring to the example of The Artist, instead of using a paintbrush to paint individual fish, he used two stencils to paint an entire school of fish. Always be on the lookout for ways to speed up a task, especially when that task is the bottleneck of the process.

How can one person do the work of many? By doing several things at once. If a computer process requires an hour to run, arrange other tasks so they can be done during that hour. Better yet, run several such programs at once.

Observe the critical path. The critical path is those tasks that stop the whole process. In other words, if you need Fred's report before you can start your own, Fred's report is on the critical path. Perhaps instead of waiting for Fred's report, you could use Fred's raw data to generate your report, freeing yourself from waiting for Fred.

It's amazing how much time is consumed by rework (correcting mistakes). When you make a mistake, you must first do the "wrong" work, then diagnose what went wrong, then do the "right" work. Rework also often costs money due to wasted materials or occasionally broken machines. In data type environments, it can cost money by leading others to make wrong decisions or bad cost estimates. Affirmatively look for situations conducive to mistakes, and change those situations so that mistakes are much easier to avoid. Even if these "safety barriers" take extra time, you'll save huge time and expense by eliminating rework.
Steve Litt is the author of Samba Unleashed.   Steve can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Troubleshooting Professional Magazine must be licensed with the Open Publication License, which you can view at At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Troubleshooting Professional Magazine, you must decline the option to prohibit commercial use, because Troubleshooting Professional Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2001 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at (wordwrapped for readability at The latest version is presently available at

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version.


All trademarks are the property of their respective owners. Troubleshooters.Com (R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue