The Meta-Process: Getting Stuff Done© 2000, Alex Forbes
This is written for those young among us, of whatever age, who like the idea of getting a better rate of return on a given level of invested effort.
Who among us has never said, "Gee, I just never could do that"? We might have been talking about anything: flying a kite, balancing our checkbook, climbing a mountain, flying an airplane, or cooking. Skill levels are all relative to what we've done before.
Yet, haven't you ever surprised everyone, including yourself, by doing something you and your friends would never have suspected you could do at all?
This article won't tell you how to actually DO anything. Instead, we'll explore certain thinking and planning processes that will, and do necessarily occur (on some level), in order for us to accomplish anything. We'll illustrate and develop these ideas with modest concrete examples drawn from personal experience.
We're not interested just now in the nuts and bolts of how to balance a checkbook, fly an airplane, or fix a broken car engine (unless you are).
We want to find out how it happens that we acquire the sheer, unmitigated brass to tackle completely new projects in the first place. This "gumption", which only some of us assume so ready -- where does it come from?
Many of us who can radiate self-confidence and a "can-do" attitude have never thought seriously about what we're doing when we undertake a new project. The "natural" achiever may hide under a gee-shucks cloak of modesty. When pressed, the explanation is: "I just do it." There are "down sides" for the unexamined self-achiever to reflect upon: a higher potential for overconfidence; a lower potential for learning from experience or for teaching others.
Overconfidence is a happier flavor of lost potential. We already mentioned the self-fulfilling conviction that we "just can't". And, we'll also touch on bona-fide situations where we really can't do something, or, at least, need to give ourselves some extra help.
We can show that understanding how we actually manage our projects gives us an edge over those who appear intuitively to know "the right thing to do." Understanding project planning requires a grasp of two basic principles:
1. Little or big, every project
is a new project the first time we undertake it.
2. Big projects consist of little projects that have been planned and organized into a do-able sequence.This article isn't specifically about project planning. We're really more interested in the "front end" of project planning: what do we need to know to make that "go-no go" decision in the first place? What do we need to get going at all?
Turning Little Projects Into Big Hurdles
No one raises an eyebrow when told of a high-school graduate who can't balance a checkbook. Let this same youngster complete a course of flying instruction and solos an airplane halfway across the country and back, and we'll all notice. Yet who wants to touch a question such as: why are there veteran airline pilots who can't balance their checkbooks? Some questions seem imponderable.
How would you account for differing achievement levels in the same individual? There is definitely a process that needs to go on before we get the gumption to tackle a large or unfamiliar task or project. This would also help us to explain why we might neglect a simple but important task that we find distasteful.
3. If there is no process, it is unlikely there will ever be any successful action.
There must be other names for this "process", but the only ones I can think of have become specialized, or even institutionalized. Businesses have their pre-planning meetings and study groups. Universities and very large corporations have their "think tanks". Engineers and programmers have their flow charts and specification sheets. And NASA has - well, NASA has other divisions of NASA.
What it is that occasionally prompts individuals like you and I, so suddenly, to decide that we intend to learn to climb a mountain, fly an airplane, or embark on a self-study course on advanced computer programming?
We have colorful slang phrases for people's sudden "wild hair ..." energy, but no socially palatable names come to mind. Why is it that we have a phenomenon everybody knows about, but nobody can describe or name in polite company?
People in math and the sciences sometimes joke of problem solving by the "stroke of genius method." Palo Alto's own Thomas Edison wryly noted that his major accomplishments were "10% inspiration, and 90% perspiration."
It's easy to under-estimate the underlying work required for Edison to even make such a statement.
We're able to see some humor in such observations because we're aware, on some level, of the enormous skills and methods inventory already accumulated by these innovators.
They're wisely re-cycling their inventories. We should too.
But it's not necessarily innovation we're investigating here; rather, it's those attributes and processes vaguely ascribed to "initiative", "gumption", and "courage". The phrase "you just need to summon up some courage" is the classic cliche, a motivational catchphrase that totally begs the question of how to get there.
Innovation is the special instance of 'achievement' that deals with the discovery of new processes and methods. Climbing a mountain isn't innovation (unless we forge a completely new route) - but no one doubts that it can be a heroic achievement.
Most of us don't need to build our metaphoric mountain, just to climb it. Yet we've already seen one way the two processes of innovation and achievement can be the same. Another way is always that very first time we ever personally take on another new challenge.
Begin At The Beginning
Often enough, the problem isn't beginning the project or process, or even of accomplishing it. Mostly, the problem is simple enough: knowing how to begin at all.
Identifying how we need to approach a process at all: this is, by itself, a process. We can demonstrate very easily that it is indeed a separate and distinct process, apart from the process or project it launches: what if we successfully identify all of the elements we need to execute a task, and consequently decide not to do it?
A Name For The Process that Comes Before The Process
After considering all the names in use for pre-planning processes, some quite stuffy, I am sticking with my own stuffy, formal-sounding name. I call it the "metaprocess", because (large or small) it must come before the actual process, task or project itself. Sometimes we need to be able to distinguish between the process, and the general activity of preparing to undertake it. That's what this article is about learning to do.
"Metaprocess" covers the explanation for the balanced checkbook and the underlying procedures of the cross-country airplane flight with equal ease. Like any other process, it can be broken down into component parts or items on a list.
Merely recognizing this divisibility should encourage us to see how we could break the project up into manageable tasks. This gives us the gumption or "business plan" to proceed with the project itself.
The "metaprocess" in action will be part gut instinct and determination, and part calculated planning and estimating. It will always be important for us to know what "mix" of each might be appropriate for a given task. If we don't know how we know that, the notion that we can complete the task remains a theory or hope.
What's In It For Me?
If you can inventory your own skill levels, and adequately assess what else might be needed to accomplish your prospective project, you've successfully completed a basic metaprocess and are probably ready to start your project.
Or, if you know someone else you can lean on to help with your project, that's a form of metaprocess too, and you're well on your way to beginning. That's a variant of what we'll call the "default metaprocess". In the default case, you're not doing the essential initial planning work on your own. You're just allowing it to happen. We'll have more to say about default metaprocesses later.
If you're part of an established team, the team already has some sort of metaprocess working for it, allowing you to join it, coordinate, and pool your contributions. If you're established in an occupation or profession, you've already become comfortable with a whole variety of metaprocesses, many of which you'll use daily to avoid re-inventing the wheel.
But that doesn't mean we've learned to carry those work habits into other areas of our lives. The methodology is as old as mankind, but the idea of re-cycling it is born again every day.
Especially when starting out in life, understanding the usefulness of pre-planning is a tremendous edge, at a time when almost every challenge we encounter is new. Later, there's a bigger payoff in recognizing that there IS a metaprocess, whether we're acknowledging it or not. We can indeed grow it into a powerful tool from readily available components that fit each situation.
But, at that point, we need to know what the process is, and acknowledge it explicitly as a vital part of our planning.
If you're fascinated with ideas for their own sake, we're going to ask a lot of questions about how this works and how it fits in with what else we know about accomplishment.
If you're just interested in getting the job done, read this once, see how it explains what you've already experienced, and most of the rest of the pieces will fall into place by themselves.
Discovering the Process Already Within Our Own Lives
For the cynics in the crowd: in the final stages of editing of this article, I noticed that parts of my writing read suspiciously like a motivational tract or self-help primer. I know too much about these "inspirational" businesses, sales motivational seminars and personal training courses to have much use for jingoistic slogans and easy-to-memorize formulas.
We shouldn't be deterred by the fact that some people make a lot of money getting adherents and paying students to admit what they knew all along. We do waste a lot of our potential. Our premise here will be that achievement comes through understanding, and nothing lasting comes of pep talks and route memorization.
I hate route memorization anyway, and I was never any good at it. I need a process that guarantees I can accurately reconstruct that which I've forgotten, when I need it, on the fly.
It doesn't matter whether we need this process to build confidence, or to organize our project, because it does both. It can be done by the seat of our pants and on the fly (as when we were kids) or formally and deliberatively (as for work, or for some other big project or crisis).
It's the difference between saying, "I just can't do that ... no way!" and "I think I can see a way I could get this done. Let me work on it a little bit."
The metaprocess affects us in all ways, little and big. Regarding those of us who fall back on explanations like "I just never could balance a checkbook": aren't we actually making a statement about our ability to plan and organize?
On the other hand, somebody who has balanced their checkbook 10 times in a row, or rebuilt a car engine 3 times in a row, is entitled to forget that the metaprocess was originally quite distinct from the process itself.
Thus, we can already suggest that the metaprocess can be recycled, refined, institutionalized, cloned into new metaprocesses, and used as a model for parts of a much bigger project. This is what we do when we put tested code snippets together to form a new computer program. This is what you do when you climb a mountain. It all started with the preplanning and the confidence building exercises.
Some metaprocesses, like physical sports training, are heavy on skill and "gumption": motivation-critical activity. Good sportsmanship starts with an affinity for the task, a calculated willingness to take the risk, the confidence of experience that we can learn by trying, and a commitment to learn by observation how others who are successful do it.
Sports "metaprocess" is tightly integrated with the process itself. In team sports, it is also tightly integrated with the concept of a team. But it is still a metaprocess. Being aware of that supplies the answer to the gumption-trap question "how can I possibly do that?"
Try as they may, motivational speakers can't seem to get across a durable notion that activities other than sports are motivation-critical, too. Either all the good people are already taken in sports careers, or there's some other reason to account for why we seem to lose gumption in more abstract careers. Not only do we show up for work with lousy attitudes, we accept this as normal. We'll leave clues to account for the attitudinal discrepancy between sports and "the rest of the world", but it's up to you to figure it out.
Other metaprocesses are highly institutionalized, structured and formalized. Maybe they're ponderous: NASA is probably more than 50% metaprocess. There would be no space program without a highly developed metaprocess; it's not something we can do by the seat of our pants.
The "metaprocess" approach to learning already works for anybody who generally succeeds in the tasks they choose for themselves in life. But I originally got the idea while reading an excellent article on overcoming dyslexia, a learning disability.
Resources for People With Learning Disabilities
My good and incredibly talented friend Richard Wanderman provides a web site with resources for people with learning disabilities. The site is an excellent source of information, whether or not one has a learning disability, and I go there often. Richard wrote an article on his web site about how he learned to conquer written communications, rebuild a Volkswagen engine, climb mountains, and use a computer to help organize his work and thoughts. Richard, who himself has dyslexia, writes a fascinating and excellent article. I encourage you to read his article yourself at his LD Resources site; the article is "One Person's Path To Literacy". I hope you'll bookmark his site to review his frequent new and fascinating postings on subjects of interest to anybody who celebrates being and feeling alive.
In the back of my mind, as I read Richard's article, was this idea: my own meandering path to a qualified and undistinguished success didn't seem to be obstructed by any identifiable disability. Faced with such an additional hurdle, could someone like myself still have achieved a comparable level of accomplishment?
For better or for worse, we don't have to answer that. I became fascinated with the idea that there may be something - namely, the learning process we are now exploring - that Richard exploited, turning those lessons to his own advantage -- while most of the rest of us shrugged and said we just couldn't do it.
Possibly, I saw, I did the same sort of thing -- without realizing it. We all have a default metaprocess.
Whether or not we have a learning disability, those of us who are successful in our accomplishments have learned to automate learned work-arounds of our "weak points", so we can concentrate on exploiting our strengths. Who would cry "foul" when our "weak points" actually grow into strengths?
That's what I believe. I have no special training in psychology. I'm not qualified to give advice on what does or does not work in overcoming learning disabilities. I do think most of us would do well to treat our "weak points" (whatever we may think them to be) as if they were identifiable obstacles that we can overcome.
"I Just Never Could Do It!"
This brings us back, again, to those of us who "just never could do" math, balance a checkbook, fix the vacuum cleaner, or learn to operate a computer. Do you have "two left feet" on the dance floor? When someone suggests you repair something in the house or car, do you whine something about just not being "mechanically inclined"?
Parts of those sentences above are in quotes because we all know they really have become part of our vernacular. Even the word "just" is used in a universally understood way, to imply this is something you can't really help. It's always been that way, and there's nothing you can do about it. Notice that the word "just" also always serves as a friendly warning to others not to interfere.
Since learning disabilities are part of the gamut of human trials and challenges, it's important to recognize when an obstacle cannot be immediately overcome. We have nametags and labels for some of life's identifiable disabilities, whereas we are completely lacking in terminology for others. The fact that our own particular challenge may or may not have a "tag", may influence our ability to seek out knowledgeable others.
We should avoid using tags, or lack of them, to form broad-based conclusions about our ability to work around or overcome an area that has so far proved difficult for us. The tags help us define the difficult areas, but they don't grant a working solution to anyone.
Instead of focusing on perceived negatives, let's hope this article that can help reverse stumbling blocks back into positives, which we can then put to work for ourselves.
Zen And The Art Of Motorcycle Maintenance?
In writing this today, I am struck how much of my own thinking still parallels the 1970's classic, "Zen And The Art Of Motorcycle Maintenance", by Robert Pirsig. I was (and remain) a fan, and I'm pleased to note this book is still available at better bookstores. In a mixture of novel, discourse and philosophy treatise, Pirsig explores the processes of fixing our life's "right attitude" by discovering and applying concepts like "right thinking", "excellence", "gumption". If you want to really know how to fix your motorcycle, he writes, learn how to make your thinking follow what your motorcycle's needs are trying to tell you. If you were a set of ignition points, what would you need to do a really good job? "Become one with your motorcycle".
This book is outstanding in teaching new ways to visualize and solve problems of any kind or magnitude. It is also an excellent "chautauqua" of discourse, exemplary rhetoric, and discovery. It is a stirring novel, and a passionate indication of what we can see when we learn how to look. It encourages us to look in wonder at ourselves and the world we live in. I am indebted forever to the author and his novel for the inspiration and courage to press on with my own strange learning curve, but we're pursuing a different track here. I want to pursue a concept I think Pirsig skipped.
Other Kinds of Motorcycles
I enjoyed Richard's new article on his own experiences and accomplishments as he learned how to learn. Based on a comparison of his experience with my own, I realized that we could develop and unfold the process by which we decide how we are actually going to tackle projects like rebuilding car engines. I had never approached achievement from that angle before.
Why is it, after all, that these things we accomplish out of sheer necessity are "just things that had to be taken care of", whereas those other things, which we really would like to do, seem forever to remain impractical and just beyond our reach?
Rebuilding an engine should intimidate almost all of us. I was talked, kicking and screaming, into rebuilding a Mazda rotary engine in 1973. I had absolutely no prior experience.
There are a lot of questions we should be asking ourselves about how we psych ourselves into actually doing things like this successfully. I'd like to look at some of them in my own life.
Every major accomplishment of mine seems to have involved that same process whether I was consciously aware of it at the time or not. Learning more about how we do that, on an explicit level, seems like a valid way to discover how we get the gumption to do it at all.
After all, we don't just sit down one night and say out of the blue, "Hey, I think I'll rebuild my car engine."
Whenever interest or necessity drives us toward a bold new unexplored project like that, we have two choices. We either laugh at the idea, dismissing it out of hand (and that's the end of that), or we begin analyzing how we might actually go about doing it.
Me: The Old First Person Singular
I'd like to illustrate the concepts we develop by drawing on some examples of challenges from my own life. Talking from one's own experience is consistent with authenticity. If you're looking for inspirational motivation, you need a biography, perhaps, of John Glenn or Dr. Martin Luther King. Some of the things I did may seem pretty "neat", but that doesn't make them exceptional.
Thousands of others have done all of the things I have. More than a few of them have done it better, pushed the accomplishment to far greater limits, and told their stories with far better skill than I.
A problem with third-party biographical analysis is the tendency of the author to say, "See, my studies of Ben Franklin's kite flying experiment shows that you should go into Physics."
I'm not intimidated by the fact others have flown better kites than I. I am qualified to draw conclusions about my own personal life and experiences, as you are your own, and we are both free to disagree about what my experiences may mean, without getting entangled in historical significance disputes. So we'll use my experiences, and my mistakes, as examples.
Just on the off chance you end up deciding that I must be unique after all, let me compliment you by reminding you we're all pretty unique in some remarkably similar ways.
Trivial Pursuits: "Flow charts"
Soon enough, we'll get to look at some pretty dumb approaches I took in learning to do some things well. So I'd like to kick this off with a trivial example of something I have a really tough time with: spatial relations.
I've always admired good computer programming practice, and part of that practice is documenting the project with block diagrams and flow charts.
Flow charts make me dizzy. Literally. I feel disoriented when I try to trace the diagrams. I get lost easily, follow the wrong symbols and dotted lines, and often end up tracing the flow right back to where I started. Big flowcharts can make me break out in a cold sweat.
I can draw and illustrate fairly easily. I can explain and teach complex relationships in ordinary English. To diagram them, I need to see the big picture at a glance, and I need to relate constantly to big picture as a primary frame of reference. Flow charts only magnify small pieces of the logic at one time.
I have a workaround, and it works for me. When others drew the flowchart, I circle and label the parts I understand, and then study the parts I missed to see what they do. Sometimes, they don't do anything, and I get points for streamlining a process.
When I have to draw my own flow charts, I draw the small pieces I know, and then "connect the dots", If there are parts I know I've left out, I then know where they belong in the structure.
Beginning without a Foundation
Wouldn't it be nice if, when we decided to build a house, all we had to do is look around for where somebody has already poured a suitable foundation? Everybody starts with bare earth. I accomplished most of what we'll draw upon for examples, without the slightest hint of the preplanning we're today calling a metaprocess.
As with so many of us in our earlier years, there was still an underlying metaprocess. It was 100% "gut instinct", opportunism and gumption. That is our "default" metaprocess, but I, like most of my peers, was unaware of any of this at the time.
For me, the unexpected opportunity or shortcut always beat three of a kind. Life was always dealing wild cards, and I followed them wherever they took me. Who could plan these things?
I was almost always willing to take a "dare".
Rebuilding a Car Engine
"Me, Rebuild a Rotary Engine"? Sure enough, it started with a dare.
The 1973 rotary engines had a bad seal design, and mine was one of those. My dealer said it was out of warranty. They hadn't serviced the vehicle, and I could produce no adequate maintenance records. I was whining about this to a friend and mentor. He suggested I repair it myself.
I condescendingly whined that this was absurd. I had no experience with this, or particular mechanical training or abilities. Beyond changing my own oil (which I had been doing because I couldn't afford dealer service), the task was far beyond my abilities. This was a job for a master mechanic, so I announced that I had no business trying.
"It's just no use", I argued. I just can't do something like that myself."
He exploded with sarcasm and open incredulity. What was I, some kind of chicken? Come on, the engine didn't run now. Was I afraid the engine wouldn't run when I was done? He dared me.
Over many ice-frosted steamer glasses of beer, my first metaprocess was born. He outlined what must be done.
The car must be garaged where we could work on it and pull the engine. We would use his garage. Objections overcome. He could borrow a "come-along", a hoist to hang from the rafters, so I wouldn't have to spend money to rent one. Objections overcome.
And I'm thinking, "Yeah, like I'm Neil Armstrong, and here comes my first step on the Moon. Sure, now I'm taking apart the Lunar Rover, piece by piece, and fixing this escutcheon plate RIGHT HERE so we can all go home ..."
I think I actually laughed out loud. I'll never forget my embarrassing sense of the surreal, that he was telling me this, and that I was listening . I still didn't get the idea of a process.
It got more outlandish, like someone was smoking spiff. Here's this guy telling me I would unbolt and remove the transmission linkage and clutch housing, carburetor, distributor, and all the other spinach and plumbing. We would unbolt the engine. We would hoist the engine clear of the engine compartment, push the car out into the driveway, lower the engine to the floor, and "you will then take the sonabitch apart yourself." He had an aviation business to run. And it was finalized. Objections overcome.
I timidly suggested that maybe I should at least buy a shop manual. He laughed, saying I shouldn't need a silly manual. Take the parts out and lay them out in the order they were removed. Then reverse the process for assembly. Suggestion improved upon: I bought the manual anyway, my first tentative step at upgrading the metaprocess we just outlined.
Now you know why Richard's experience rebuilding the VW engine struck such a respondent chord with me.
Beginning Points of The Metaprocess
We need to interrupt my rotary engine story to compile a list of points we're developing about the metaprocess. These are the journalist's "who, what, when, where & why" questions that help us integrate the points in with our knowledge of our own past experiences.
So we can associate our points as and where we develop them, we'll keep these points in boldface to help us refer back to them.
We've already developed three of these points earlier in this article. Feel free to navigate back and forth through this article by reference to the points developed in it.
4. Just because we personally don't know how to do a thing, doesn't mean it can't be done. Seek out, and don't presume to reject out of hand, the advice of those who have already done it.
5. Break the project down into definable tasks. If we don't have a mentor to help define the task order, the mere act of listing the tasks should help the pieces fall into place. At this point, we have a plan and should have the courage to proceed.
6. Plan work methodically. Improvise, but secure additional help or resources as we feel we need them. It is always easier to interest others in our project if we have actually started it and have a plan.
7. If we don't have an explicit metaprocess, we get the default metaprocess instead.
As for the rotary engine, a month later I had the engine seals replaced, and the engine back together and under the hood, myself. It started up on the first try. Well, it was really the second try, after I got the spark plug wires attached correctly. It ran well for many more thousands of miles.
The Next Steps: Building On Experience
The chances of me doing something like that AGAIN would be about as likely as me flying an airplane, programming a computer, or climbing a mountain. In fact, I would be doing all of these things within a few short years.
I think we all start out with the fundamental faith that we can do anything we want to, if we only apply ourselves. Too often, the formative years seem to conspire to beat this out of us.
But it is we, ourselves, who end up arguing for or against this conviction.
After the rotary engine experience, I proved time and time again that this "can-do" belief, though praiseworthy, was naïve when taken by itself or out of context. It could also be dangerous to me.
The default metaprocess was clearly inadequate.
8. Just as there is no such thing as a "formula" for life, there is no such thing as a "formula" metaprocess. The thought processes must adapt to the nature and seriousness of the task at hand, and at times even the emotions must heed nature's warning signs when we are getting in over our head. To borrow a popular phrase, the metaprocess needs to embrace a "holistic" approach to the entire problem.
I wanted to prove myself. I made many dangerous mistakes (due to overconfidence and poor planning) in solo rock climbing and motorcycling, where only my own safety was involved. I made no serious or dangerous mistakes in flying lessons, because traditional structured flight instruction methods impress the student with the seriousness of the learning curve.
Metaprocess Building Blocks
What we are still interested in discovering here is what makes up the metaprocess. There is a mechanism, and it is a mechanism, which suddenly enables us to successfully engage in hard work with high stakes, to begin risk-taking with promise of future rewards.
I initially thought myself fundamentally incapable of any of the processes above. Something had to happen first to convince me it was worth the effort to try.
9. The success of the metaprocess depends on experience. If we have applicable experience, wrap it into the current project and project planning. If we have no experience, go out and get some. Start somewhere, and build on that. Experience is the fuel that builds confidence and success.
10. Pure gumption and seat-of-the-pants planning is not such a bad method if we have nothing else available. What we have here (again) is the default metaprocess: if we plan nothing, something will happen anyway so long as we keep moving.
One of many drawbacks of "flying" by default metaprocesses is that we're not very much in control of either planning or outcome. When it's all over, we credit our "intuition", connections, or lucky hunch. Alternately, perhaps we blame others or our "bad luck".
For some of us, especially when we're just starting out, the default is all we've got. A default metaprocess is better than doing nothing at all, because it gives us the impetus (rightly or unwisely) to commit to beginning.
Now, consider again my mentor in the engine rebuilding experiment. Clearly, he had experience that led him to instruct and proctor me through the engine project. His experience made him forget that it was not always so easy to take apart an engine, so he dismissed my idea of buying the shop manual.
11. Not everyone requires the same approach. This is both because each of us has differing strengths and weaknesses, and because the metaprocess can become automated once we've developed it for a particular project. Starting out fresh in life, every project requires an explicit metaprocess. Later, it's like money in the bank.
"Me, Flying Lessons"? I took flying lessons in the '70's. I didn't plan this either. I talked a friend into taking lessons, he got cold feet, and I bought him out from under the lessons contract.
The instructor was the same fellow who goaded me into taking apart the Mazda engine. After that experience, I just couldn't tell my mentor I really didn't think I could do this. But I had always loved airplanes. Because of a growing realization that I could still surprise myself, I gave it a try.
Very little of flying is left to the "seat of the pants", even in general aviation. Instruction breaks aviation skills down into very discrete, student-sized tasks.
We can save a whole page of text by skipping our enumeration of all the tasks in the Pilot's Checklist. It takes months or years to master each step, which covers everything from the moment you walk up to the aircraft, to the destination where you park and tie down the aircraft and walk away from it. Everyone, from student to instructor to commercial or NASA pilot, refers to the same basic written checklist. No one is permitted to try to execute it from memory.
The checklist is the accumulation of decades of experience and trial and error. In aviation, the checklist has become institutionalized. It is is part of an institutionalized metaprocess.
In actual flight instruction, each element of the checklist is a discrete task, which itself may be a metaprocess.
12. A larger metaprocess may be constructed of many subcomponent metaprocesses.
13. Larger projects require more complex metaprocesses.
14. Larger organizations, occupations and institutions formalize their metaprocesses and give them specialized names.
For the beginner, executing all the tasks sequentially that are required to fly from airport A to B are just too much to hold in one's head at once. The instruction process breaks this down, often along different lines, so that all the steps are mastered and automated.
Learning simple navigation with charts, and reading the weather maps, takes place over the entire course. Some steps must be learned in a sequence of lessons, such as the preflight check of the aircraft, starting the engine, and performing the instrument, controls, engine and systems checks.
Flying students never begin by learning how to fly airplanes. They learn how to perform one subtask at a time. Then they learn how to put those tasks together into a coordinated process or maneuver. It actually took me several days to get the hang of taxing the aircraft on the straight white line in the middle of the taxiway.
After soloing, we learn to make cross-country flight plans and execute them, first with instructor, later, without. The flight plan is another metaprocess. Students later learn simple aerobatic maneuvers, such as intentional stalls. These build flying skills, safety awareness, and confidence.
This is the point at which most students begin to learn the "feel" of the aircraft.
What is really happening is that the training is becoming automated for the student, who can then begin building more comprehensive learning tasks. Basic instrument navigation skills are built ("flying blind") to prepare the student for inadvertent emergencies, whether or not the student has any intention of going on for the Instrument rating.
In terms of our discussion, we're assembling newly acquired learning skills into more complex learning skills. Simultaneously, we are assembling smaller tasks (such as taxiing the aircraft) into larger processes. The metaprocess and the process are growing in parallel. We will observe this again and again.
We often read that the ranks of pilots include grandmothers, teenagers and physically handicapped persons. It's true. The notion that we need to be an astronaut, to have the "right stuff", is an unfortunate sensationalism.
Getting a pilot's license is a grand accomplishment, but it is mostly a reflection of the student's ability to build confidence in the metaprocess being developed, and to stick to it.
We will later have something to say about the metaprocess and championship skill levels, such as we might see at air show aerobatic demonstrations, or at the US Open.
I did complete my student training and received ratings for "airplane, single and multi-engine, land", meaning I could fly twins but not seaplanes. I took further training, but funds ran out before I could complete advanced ratings. The fun, the challenges I overcame, the confidence it built, and the love of flying are with me to this day.
Flight instruction is a good example of an institutional process that has evolved into codified and standardized training practice. Here, the educational institution IS 90% of the metaprocess. The student supplies the other 10% of the process in the form of gumption and enthusiasm for learning the subject.
Underlying this process, the process that we experience, are decades of others' experience, observation, teaching techniques and trial and error. While this doesn't guarantee a process that is best for everybody, we are usually in a better position to critique its effectiveness and relevance when we've completed the training.
Other degrees and certificates are also completed one course at a time.
If you had pursuit of some other goal in mind, such as an advanced degree in aerospace, or setting up your own machine shop, remind yourself of this: everybody else who ever attained these objectives had to go through the same process you'll have to. You can do it, but you need to acquire the plan and the process, and follow it.
Formal Training: Free-thinkers vs. Institutional "Sheep"?
I went through college with a chip on my shoulder. I took from each course exactly what I wanted, like the lemon picker who only picks the single biggest lemon from each tree. Many of my fellow students followed more conventional paths, memorizing and absorbing information they didn't understand, and which they couldn't relate to anything else they knew.
There needs to be a balance here. We should give the institutional process and our instructors credit here for knowing the field, and get used to the idea that all of the pieces may not fall into place until later. Some instructors in some fields may still push personal agendas, but we won't find many better places to become acquainted in detail with the opposite viewpoint, than a college or university. Prize intellectual independence, but don't pass over all but the trophy lemons.
15. Our internal metaprocesses need to accommodate a broad range of others' skills, disciplines and viewpoints. In order to forge a set of thinking tools that work for us, we need to be able to compare them competently to other methodologies.
16. Ohe metaprocess for a particular skill can be codified, certified, and passed on to generations of students by educational institutions. We should take advantage of this, insofar as possible, rather than fight it. Here, for the most part, the institution IS the metaprocess, the student supplying the motivation and energy level to learn.
17. Once again, the metaprocess breaks the process down into bite-sized learning chunks, and sequences the chunks into progressive lesson plans. Success consists of mastering one lesson at a time until the course or project has been completed. We can only fail the complete course if we skip, gloss over or stop at a single step. Plan our steps, but keep moving.
I don't want to say too much about this, because I'm not a real rock or mountain climber. (My friend Richard is; see his website for some interesting stories). My off-trail experiences did still help pave the way for other processes, and a better sense of increased independence.
I used to do some serious backpacking, and along the way I picked up some tips and instruction on basic rock scrambling from friends who actually were climbers. It is worth mentioning that this built a lot of confidence in my ability to work my way out of bad trail situations, and it saved my butt many times. I also climbed a few puny mountains, which was probably pretty foolish because I was solo, and got myself into some tight spots I had no business getting into.
But I got myself out of those situations, too. I was pretty proud of these rudimentary skills and I intentionally developed them with the idea in mind that they would enhance my ability to survive and enjoy the wilderness experience. And they did. At face value, there was precious little planning or metaprocess to it. I did understand that these skills were part of some sort of fall-back or default process I was adding to my inventory, and I was grateful to have them around.
Real climbers would need a real metaprocess.
If you're climbing a mountain, the outcropping that looked reachable from the valley floor may evolve into a fatal chain of events from the ledge up high. Here, the metaprocess not only mixes with the actual climbing process, it is inseparably concurrent. The route eventually taken may involve hundreds of small deviations from the original plan, depending on what the reality is when you first encounter it during the climb.
The first step is to become aware we do preplanning -- whether it's done intentionally or not. Making it intentional gives you a head start. It also gives you confidence that you can execute the plan successfully.
A failure to identify the difference between the metaprocess and the actual event is less likely if you have done adequate explicit thinking about the metaprocess beforehand. For pilots and rock climbers (just to name a couple of examples), not recognizing the metaprocess component can lead to fatal confusion over what the plan says -- compared to what the situation demands.
18. Success and survival may depend on being able to distinguish the metaprocess from the process, even when they seem the same.
19. "Grow" the metaprocess as we use it. Learn to put smaller metaprocesses together into larger ones, even "on the fly". Do temper changes to the original metaprocess with discipline based on our own prior experience, so that we don't dangerously over-reach existing skill levels.
Observe that the metaprocess is more explicit on the first climb, than on the second. We'll see this again and again: the metaprocess is always there, even after it's automated.
20. The metaprocess need not start with something complex, particularly when a simple intention will do. Part of the plan may include building on the simple metaprocess later.
A metaprocess is still a process, but it's an approach to planning the "actual" process. Why not take control of it at the formative stages?
I would like to say something about learning to write good computer programs, and then I would like to condense some of my other personal accomplishments into our wrap-up.
Not only is programming a practical challenge, it's fun, and it's an excellent example of how the metaprocess infiltrates the design and execution of the project itself. As with many other professions, programming has worked out an established methodology.
The programming code or language that we bang out on a keyboard is called "coding", not programming. Whether it's C++, COBOL or AppleScript, the overall program flow is usually remarkably similar. Good programming practice includes comprehensive design analysis, which is pretty independent of developer's chosen language or platform.
The programmer IS concerned with the quality of the code itself. It must be efficient, it must not contain "fatal" errors (ones which cause program execution to halt completely), and it must be readable by other programmers. The programmer is also concerned with overall considerations of system design, data flow and timing, input and output methods, and many other aspects of the "big picture".
The "big picture", by the way, had better include how the program presents itself to you, the user. Before the programmer begins "banging out the code", programming practice dictates putting together flow charts (my Achilles' heel), and perhaps specification sheets to show how each part of the program should operate, and how they should interact with each other, and with you.
This "spec" is the equivalent of both blueprint and roadmap for the completed project. How many metaprocesses can you isolate so far?
The study of good programming practice is an art in itself, and many complete courses and careers are dedicated to refining and standardizing programming practice. There are many different recognized "styles" of programming, and we are usually encouraged to settle on one of them and stick with it.
Small projects and programming departments, which don't benefit from a Quality Assurance department (my profession today), must incorporate quality testing and considerations into the project planning, design and execution. Even the largest programming departments must keep quality control a high priority in their methodologies.
As we've suggested, all of these individual programming disciplines are concerned with the metaprocess and the rules for forming them.
These considerations need to be decided and settled before the actual programming begins. Yet you can see that the metaprocess does not stop when the coding starts. It is more like our discussion of flying, where the metaprocess and the actual process begin to fuse together.
I can think of at least two reasons why pre-planning would seem to fuse with the actual process: accumulated experience levels, and the complexity of the process. We will shortly see where this idea leads us.
21. As the skill itself is mastered, or the project becomes very large, the metaprocess becomes an ongoing part of the process.
"Zen" author Robert Pirsig tells us of philosophers who argue endlessly whether method or process is more important. To a programmer, the question seems stupid and the answer is obvious: both.
Programming is a relatively new methodology and discipline. The profession, and most of the individuals in it, learned the rules the hard way.
I bought an Apple II computer in 1979 and taught myself Apple Basic. Nothing came of this directly, but I had a lot of fun, and wrote some complex programs. I bought a copy-protected commercial accounting program to run my small business, but the program had numerous annoying bugs and some "fatals".
I inquired to the vendor about these problems. This was the first (but not last) time I heard the reply, "We've never heard of anyone else having this problem; you must not be following our instructions."
I learned how the copy protection was written, disabled it permanently, and fixed the bugs and customized the program so it fit my needs.
My code was actually pretty awful; the lines referenced other lines halfway up the page. I found that even I couldn't follow my logic six months later. This is called "spaghetti code". I had not yet learned that there actually was a formalized discipline for writing good code.
Before trading in the Apple II, I forced myself to diagram all the changes I'd made so I could keep track of what my coding had been written to fix.
Something interesting happened here. I spent an enormous amount of time diagramming the programming flow. I restructured large parts of my code to conform to my diagram, because I couldn't see any other way to make all the pieces fit together. We already know diagramming doesn't come easy to me.
Can you think of another reason why the restructuring process took me an enormous amount of time?
In later years I bought a Macintosh and taught myself C. I had to un-teach myself many of the bad programming habits I built up in my old Apple II coding days. I also took an online C course in the early days of dialup modem. We've already observed that it pays not to be afraid to turn to those who are already experts. They can teach us the right process. They can teach us how to re-cycle the metaprocess.
I also learned that we can build and store the metaprocess in the code itself. I built up libraries of routines I developed myself, and learned how to write them so they could be re-cycled into other projects. With professional "comments" and clear logic flow, it is possible to remember, long after writing the code, how it works and what it's applicable for, by reading the code itself. Programmers call this kind of code "self-documenting".
I discovered how to tap into established code libraries developed by others to help ease the raw labor of programming. This frees the programmer to concentrate on larger issues: the metaprocess in action again.
I did all this mostly for fun. It taught me much about forming good work habits at a higher level than I had seen in myself before. I used C and several great scripting languages (HyperCard, AppleScript, Frontier for Windows) to write programs to perform tasks on my machines for which no commercial application existed. Later, I tackled other high-level languages and big projects for my own web pages and custom applications.
I still have a tough time with flow-charting, but always sit down with pencil and paper to do at least a rough map of how my programs are supposed to operate. On the small-scale projects I usually write, I'm experienced enough, now, that my sketch is usually adequate to keep me out of serious trouble. This only works because I can usually visualize the smaller flow-charts in my head, out of my past experience with them.
Like flying an airplane, programming a computer to make it do useful work was another thing I had never originally envisioned myself doing at all. Understanding how the metaprocess can be used like building blocks helped me attain a skill level I didn't originally expect. It's not complicated. It's not rocket science. Just tackle one building block at a time.
The Next Step: From Interest to Career
In 1992 I had an opportunity to join the Quality Assurance department of a mainframe software development company. I interviewed for the position, was offered the job, and accepted it. This was something I had dreamed of for over a decade. Honestly, I'd secretly hoped my self-training would pay off in this way some day, and it did.
But it was the toughest challenge I ever accepted. It wasn't anything at all like I thought. The programming language was COBOL, which struck me then as obsolete, primitive and weird. The software product itself wasn't object-oriented; it was terminal emulation (the old "green screen", 32 lines of 80 columns of block text display). The keyboard commands to operate the programs and user screens were cryptic, counterintuitive, difficult to memorize, and there were thousands of them.
I fought a new, worst realization of all: I decided that I hated it.
Our growing firm had almost no support or training infrastructure. After six weeks of on the job hands-on training, I was pretty much left to figure everything out by myself.
I got cold feet. I was in over my head this time. I didn't think I could do it, and considered just walking off the job several times. But I got through this crisis.
One thing I did right away was to develop peer-to-peer networking skills. Gone were my luxurious "I should be able to figure this out on my own" days.
I later took advanced outside training courses whenever available, and learned from some of the masters of the industry. (I don't know it all, and never will). Today, I'm a Senior QA person involved with product evaluation and improvement. Some of my contribution is assisting more junior people to reason their way through many of the same obstacles and "gumption traps" that I overcame.
And I enjoy my company, our product, and the people I work with.
My hard lesson: No matter how complex, intimidating and unfriendly our product appeared to me to be at first, thousands of users liked it, and millions of people relied upon it. Every part of my development focused on the fact that our product was still, at heart, a suite of computer programs. My metaprocess helped me focus on learning methods of making our product friendlier and even more reliable.
The training I forced on myself in earlier projects and crises helped me organize this learning curve, as well as others to come. Even if the challenge isn't always exactly fun, it becomes exciting, and subject to your eventual control.
Motivational trainers call this turning of a problem into an opportunity. I'll agree with them there, but most of the trainers I've observed sell short the benefits of preplanning and methodical execution. They tend to focus on peddling immediate gratification, and let someone else worry about the consequences. Thank you for letting me vent.
Putting it All Together
I'd originally planned to tackle new topics on multiple careers and motorcycle racing, in some detail, based on my experiences in each. But you can see what has been happening. The number of new points we pick up in each new discussion has dwindled from several at once, early on, to just one additional point in our last topic.
We'll instead extract a point or two from the new topics, and then move on.
"Metaprocess" teaches the practical benefits of building an inventory of processes and skills into newer, larger projects. Implied in all this is a continuity of endeavor, the old-fashioned idea of sticking to a single avocation or career and getting really, really good at it.
While the power of accumulated experience sounds desirable, circumstances don't always accommodate our objective of sticking with what we're really good at. Obsolescence aside, many industries evidence a throwaway attitude toward their investment in human resources. We live in an era where career hopping actually looks good on the resume.
22. Building our metaprocesses inventory helps us become flexible, adaptable, and more willing and able to try new things.
Of course you can see that's recursive. Trying new things is what builds the metaprocesses inventory. Is is an inventory, too, but you can reinvest it without depleting the supply.
I never developed in team sports, and only enjoy a few solo physical sports. After an unpromising start into grammar school baseball after school, I was grounded with a false diagnosis of a juvenile heart condition. This pushed me toward books instead, and we got another doctor.
So we haven't expanded our exploration into the world of physical achievement very far, and it's a critical part of our metaprocesses discussion. For me, motorcycles were a break from my pattern. Backpacking enhances survival skills; airplanes extend mobility. How do you justify risking your neck to push a motorcycle flat-out?
In order for me to learn to push a machine like my old Kawasaki KZ-1000 to its physical limits, I did quite a bit of upfront thinking, preplanning and calculated guesswork. We'd expect progressively more difficult riding exercises, but what's with all the mental preparation?
When the risks are so high, we need to be careful of how we define "too much preparation". Pushing a bike to the limit also pushes the rider to the limit, and this can be brutal. Boldness alone only produces broken riders and motorcycles. The metaprocess is nearly everything, because the process itself is so fast...
In its heyday, the KZ-1000 was the fastest street motorcycle in the world. When you are putting the machine through its paces, there is no time for reflection and what-if thought exercises.
If you haven't already done the thinking, and can't tap learned experience, it's too late. The metaprocess here consists of building progressively more challenging exercises. You try to learn as much as you can from each exercise, because you'll need it the next time. There is always a very real possibility that the next mistake will be the fatal one.
Here, accelerating around a compound mountain curve, scraping foot pegs and tailpipes on the macadam in a rooster tail of sparks, the metaprocess and the actual process really ARE the same. While you need to think the exercises out carefully, the real lesson plan is by direct experience, perception and feel of the road, the machine and your body. In a totally different sense than Pirsig ever addressed, you really must become one with your machine.
It was a thrilling experience. No, I wouldn't ever do it again. Having enjoyed the thrill myself, I no longer endorse that kind of risk-taking. I do appreciate having survived personal body contact with the far side of the envelope.
While I wrote the original draft for this article in June 2000, Tiger Woods had just completed a spectacular win in the US Open. They said his achievement permanently "raised the bar" for all players of golf.
Who could doubt that Tiger Woods might have some astonishing things to say about the "metaprocess", which he leveraged into such a winning formula? He would surely have different names for the concepts involved, but he supplied the motivation, the practice, the frustration, the self-discipline, and the mental reserve to keep raising his own standards until he achieved the "impossible" objective.
The public knows that Tiger has a lot of other things going for him too. He won the advice, teaching and experience of some of the best in the game. Equally important, he was able to listen to and learn from those teachers.
We've discussed all of these concepts separately, but we haven't put them all together to look at championship-level skills.
What is the competitive spirit, and its potentially positive effect on achievement?
A conventional world instills in us a conventional view of success: in all things, we are competing against "the others". From the viewpoint of those shopping for our goods and services, this may seem true.
When we are putting golf balls through miniature revolving wooden windmills on the "Pee Wee Golf" circuit with our friends, any notion that we're "competing with" Tiger Woods is laughable.
In that same game, I am 5 under par, and my friend is 6 under par. So why should we now assume we are competing against each other?
From our own viewpoint, measured against the standard of goal-directed self-achievement, we're really competing against ourselves. The standard here is our previous best achievement level. We ourselves are our own most objective competition.
I cannot directly control whether my "competition" will have the skill, on this hole, to sink the putt from this distance. Nor am I the best person to assess my friend's ability to pull it all together here. If you watch carefully, you will see how much of casual sport is throw-away mental energy. "I hope he misses this putt" is the very worst kind of concentration, and it's actually very self-damning. We need to be concentrating on marshalling our own resources here.
The world saw on TV how Tiger Woods, in a field of internationally known pros, managed to differentiate his own standards from those of his competitors. In order to beat "good enough", it's necessary for each and every one of us to invent or re-invent "better" in a highly personalized way that works for us, and maybe even only for us.
Never mind what the rest of them are doing now. Let's get our own poop in a pile first.
The Right Stuff
Countless others have examined the question of "what it takes" in biographies, motivational courses, movies, and lectures. We won't go there.
I can add context to that body of speculation, but only with a few personal observations.
Those speculative works are, in themselves, personal observations. We need to examine them critically before drawing conclusions about what we ourselves should or should not do.
It's truly unlikely there are any universal "formulas for success" which really tell us much more than we could deduce by observation and common sense. The main advantage in these might be that they could help save us the time of re-discovering each new task for the first time.
If we do not do the work to apply them to our own situation and circumstances, the best "formulas" fail.
Principles and values are vital to successful living, but they are still the lighthouses, not the road itself.
There really is a lot of hokum out there. The popular and now quaintly ancient movie "The Right Stuff" promoted itself as an insider view of what it takes to become a top combat flying ace:
"I want to swagger and strut, and to sport a hangover every morning, and to horse around a $50 million piece of self-propelled artillery, and to show others who really has the 'right stuff'. I want people to boast to others that they watched me fly."
We may rightly say this is not quite a winner's motivation or approach. We might be amazed at how often this film is still used in motivational training, and how many folks subscribe to its "lessons" as a formula for success.
I've tapped my own personal experience only to illustrate achievement in diverse areas: flying, motorcycle racing, and computer programming. These subjects aren't important in themselves. If someone else had written this, the actual examples would have been different, and, perhaps, have illustrated achievement via a more positive role model.
The examples I spoke to personally have illustrated not only what to do, but what not to do. It is up to the reader to decide if negative reinforcement is a necessary part of positive achievement. I rarely learned from my own mistakes until far past the time when I needed to have the knowledge.
We have shown that the approach to each endeavor is quite different in many ways. We've also shown how there is a part of the process that we've called the "metaprocess", which is common to all these challenges.
This process gets us going; it motivates us. It allows us to formulate an outline that says: "this can be done". It guides us along the way. It helps us see the project through to a successful conclusion.
None of my own examples are championship grade. That shouldn't deter me from writing this, nor deter us from thinking about what we've explored. To feel that we are unqualified to assess the traits of success, because we aren't yet a champion, would be like saying "I won't start learning golf until Tiger Woods admits I can beat him."
We start with what we've got, and work from there in all things.
Personal Flight Envelopes
When aviators speak of "pushing the flight envelope" (from which was born yet another very popular phrase), they mean something very specific. Physically, it is a graph of all of the parameters or flight characteristics of the aircraft: it defines the limits of the possible.
Stay within the envelope, and you're flying safely. Push airspeed or rate of turn beyond the envelope, and you're in an area of instability, airframe failure or worse. Most of us have been exposed to this concept.
We humans also have our own performance envelopes. Our own boundaries are based on what we've accomplished before. Synchronizing the human mind with the airplane, or the athlete's body with the entirety of previous goal-directed training, is more complicated than graphing the performance envelope. It is more complicated than the preprocessing we are calling the "metaprocess". It is more complicated than the training, the discipline and the striving to achieve.
It is all of these things at once.
To a greater degree than the aircraft frame and power plant, the human mind and the human body can be stretched by training and exercise - by all of the disciplines we've discussed - to define new performance envelopes that exceed the old.
23. When the human components reach a controlled edge of the personal performance envelope, and stretch the boundaries to a new limit, we've defined a point at which both the metaprocess element and the process element of the achievement become unified - "as one".
This can only happen with any predictability when both elements have become highly automated. The automation can't be faked; it can be attained only by training, experience and practice.
To illustrate our very last point, I'd like to go back to a lesson I very nearly grasped in high school, then dropped, then spent years and years re-learning the hard way.
In high school I joined the ROTC rifle team. In most ways, my contribution to the team was average. But I had a more troublesome problem.
When I had concentration, I really had it. Once in a while I would get into some kind of "groove" and shoot incredible scores:
"The other problem, on the high school rifle range, was that I'd somehow still learned to define a window much smaller than anything we'd been taught in class, essentially, how to squeeze off the perfect shot -- but I didn't know how it worked, or how to control it." (Shot Groups Ramble, April 2000)
Early one morning, I scored a verified 997 out of a possible 1,000 points in a practice match. I never came close to that school record again. I'd convinced myself I could never do it again, so I didn't bother to analyze what I'd done right. Years later, I worked on it again at the municipal target ranges, and taught many others the exercises they could practice to go way beyond "plinking". At my best, I developed a reputation I was justly proud of, but few ever knew how many years of practice and discipline went into it.
Shooting today is an unpalatable topic for most people, and then I don't have much time for it, and my interests and challenges have changed too. Golf, on the other hand, has soared in popularity, a sport that I never took up even though it requires much of the same concentration and discipline as target shooting. When the commentators remark in hushed voices over a pro golfer's technique, I know what they're talking about. For some uncanny reason, as a non-golfer I'm still better than many on the putting green. I do know why, but I usually don't have a lot to say about it.
No matter what the task or endeavor, it's still all about narrowing the window, or stretching the boundaries of the envelope, or whatever metaphor we want to choose. Practice brings all of the skill envelopes together, superimposing each of them until they become "one". I know what it feels like, but I don't know any other way to explain it.
This isn't one of those essays about personal greatness. It could be, but that's up to you. I know this much: for those times in our life when we shoot a 997 out of 1,000, or whatever else in life we keep at until we're demonstrably better than just exceptionally good, we're walking the same fairway with Tiger Woods.
24. Start somewhere, but start. Keep moving ahead. Don't cry when you lose ground; concentrate on gaining back more than you lost. Build on what you've learned, and don't forget the resources you built.
To the extent that you can, plan your successes, but always leave yourself the pilot's "three outs": part of the successful plan always includes backup strategies when things go wrong.
Reserve fuel and an alternate airport beat a parachute, nine times out of ten.
Most of all, build confidence from your successes, lessons from your failures, and learn to enjoy life for its own sake.
In a new endeavor, most of us benefit from the extra edge of having mapped out a plan in advance, most of the details of which come from past experience. That past experience should help us keep the new parts of the plan on track.
25. The process is the execution of the plan, but the metaprocess is the planning of the process. Equally important, the metaprocess is also the monitoring and mid-course correction of that execution, which we need to prevent the plan from failing through inflexibility after an unfortunate launch.
26. In summary, a plan with a metaprocess is an action with an in-flight guidance system.
What To Do in Case of Rain
A comprehensive plan map is important in mission-critical and life support systems, but entirely inappropriate for organizing a beach party. The plan detail should be fitting to the stakes involved, but seldom more.
The "Process" Is Getting There, Not Mapping The Route
Create a plan that incorporates a built-in guidance system, but don't get caught up in confusing the plan with the process. Guard against becoming infatuated with the beauty of the plan, thereby avoiding involvement in the very actions that launch the plan and create the success. Every failed dot.com is an impressive business plan that never developed a viable product.
If you have a mentor and a proven formula, adopt it -- and adapt it to your needs. If you are on your own, shape your own formula. But do it. What makes the difference is that you can do it, but only when you have a method of getting there. Whether we're aware of it or not, there is always a "process" to getting there. It helps immeasurably if we're aware of it, so we can evaluate and guide the process into a chosen and actual accomplishment.
So there's a metaprocess, but how important is it? It's there, and it guides our every action and outcome, whether we control it or not.
What are we supposed to do with all this information?
Don't look for miracle insights and inspirational testimonials here. Each of us has to decide what we can accomplish, and what we would like to accomplish, and how to build that bridge from here to there.
Every boldfaced point in this article is a recipe for hard work. We haven't addressed the hard work itself, directly; we've addressed the deliberative process of making it pay off.
No matter which category of planner best describes our approach to life, or how we choose to view what we've examined, I know this much is true: the components of the metaprocess, whatever these may be for us, are like muscles. The more we exercise them, the better they work for us. When they're working together, we know it, and it feels good. We show the difference in the spring and confidence in our metaphoric stride.
27. Finally, don't burn yourself out on planning and control issues. Remember to save some energy to celebrate the ride.