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.
[ Troubleshooters.Com
| Back Issues | Linux Productivity Magazine ]
|
There's a way to do it better...find
it -- Thomas Edison
|
CONTENTS
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.
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:
- Either you can troubleshoot or you can't.
- Troubleshooting ability is something you're born with.
- You can't teach troubleshooting.
- 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.
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:
- Unconscious incompetance
- Conscious incompetance
- Conscious competance
- 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.
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:
- Do I really need to do this?
- 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...
Developing an Effective
Process
By Steve Litt
x
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:
- Mentors
- Training
- Ask an authority
- Books
- Websites
- Ask an authority
- Observation of other people's work
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.
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:
- Refinement
- Redesign
In the quality world, refinement would be called "constant improvement".
It's an iterative incremental process of tiny improvements. Here's the flowchart:
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:
- Rigorous design
- Inspiration
- 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.
Emulation
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:
- Figure out the goal
- Use tools
- 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:
- Speed up a task
- Increase concurrency
- 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.
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 http://opencontent.org/openpub/.
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 http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability
at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version
is presently available at http://www.opencontent.org/openpub/).
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.
Trademarks
All trademarks are the property of their respective owners. Troubleshooters.Com
(R) is a registered trademark of Steve Litt.
URLs Mentioned in this Issue
- MISC URLs
- The Artist
- Process Tools