Out of Overload

A Guide for Technical Managers

This is a pre-publication draft. Copyright © 1998 by James A. Davis. Permission is granted to copy sections as long as the source and author are cited.

On-line readers: Use the Quick Start Guide (Chapter 2) to identify your unique situation and get started immediately.

The Preface

Years ago, I set out to design a system that would get me out of overload. I needed help badly. My days were full of customer complaints, sales groups pushing for questionable technologies, and a jumble of missions from top management. I was coping by the thinnest of margins.

I had tried different organizational systems, and sometimes one would help for a while. But another crisis would hit, and my work would slip back to chaos.

I figured my background in learning theories would help me avoid overload. My first efforts focused on multiple missions and accelerated learning. As these areas came under control, other dimensions began to surface: rapid start-up projects, decision making, physical tracking, and opportunity management. It became clear that any overload program needed a more complex set of strategies.

Each new dimension added its own level of complexity. Technical projects, for example, increased overload with their intricate dependencies. At the project status level alone, the details from 10 projects and a dozen legacy efforts was overwhelming. Accelerated learning, on the other hand, was largely an issue of structure and consolidation.

Eventually, these strategies started blending into a larger system. They had to. Maintaining dozens of individual processes was overloading in its own right. Thatís not to say I wasnít foolish enough to try -- at one point I had twenty-two separate to-do and planning notebooks.

The suggestions presented here did not originate from some academic view. They came from trial and error, with the emphasis on error. In getting to each insight, I made every mistake possible.

My errors werenít from a lack of trying to educate myself. I read the time management books and listened to every tape. All too often, these ideas seemed to slow things down. Some bogged me down for weeks. I kept asking, "Why isnít this working?" The rate of technology change simply overwhelmed these systems. Most traditional systems are too focused and linear for today's mix of multiple operating systems, unreliable vendors, and "promise anything" business practices.

Each principle has been tested in a nasty, out-of-control, everyday technical setting. There were no mahogany lined corporate Beta sites. Every step was wrung out in under-staffed, under-budgeted, legacy laden environments by individuals in full overload. As a result, a good deal of conventional wisdom was discarded. Priority lists and value systems are out. Engagement time, indexes, and opportunity management took their place.

As my work stabilized, a strange insight surfaced. I wasnít getting anywhere. Being organized and completing projects on time wasnít enough.

Granted, I had a reasonable income and the bills were paid on time, but the big opportunities seemed to go to someone else. The same was true for the companies where I worked. Our technical teams ended up with the tough projects, while some less capable group would pick off the high profit, easy-to-do contracts. In one period, I missed out on a book deal in Japan; at the same time, the company lost a contract that would have quadrupled their size. Just being organized was not enough.

The real loss from overload isnít that a couple of projects are late. Itís the loss of opportunity -- the easy pickín, high margin, big time scores that slip by with no one noticing. What could have been, thatís the loss.

Getting out of overload is a big step, but itís possible to become efficient and still head in the wrong direction. Clearing your mind and structuring your situation in a way that surfaces opportunity, that is the ideal.

JAD 4/98

Go to: | AWSS Main | Next Chapter | Your feedback is important: Jim Davis jdavis@awss.com