Our team, led by a baby faced brand new 2nd lieutenant, delivered on schedule the annual software release of a critical national defense early warning system. This on time delivery was a first in memory of the organization and required no fancy project management tools beyond our own initiative.

What We Did Differently

1. Looked around and found people who were working on lower priority efforts and asked them if they would like to help. This project was the marquee effort of our unit. I always received an enthusiastic and somewhat surprised “yes!”

2. Assumed that these folks would obviously do a decent job. Many had just successfully finished college or had just completed Air Force software training. I saw this as positive where others saw it as inexperience.

3. Sat down with each and gave them a large logical “chunk” of the effort. I laid out the process for them to use. Since most were new and trying to learn the system, they were readily open to whatever method or approach I recommended. I did tell them to do it the way I laid it out – no shortcuts, do a good job.

4. Did not check their work. I asked them how they were doing when I ran into them. I called no meetings. I answered questions when they asked them. Often I pointed them to a manual or other source even when I knew the answer. At least one frustrated fellow exclaimed, “why don’t you just tell me the answer, I know you know it!” I wanted them to learn more than I knew.

5. Never told anyone what hours they had to work. I was not anyone’s official supervisor. I even often suggested people go home, usually because I wanted to work undisturbed for a while in the evening.

6. Often ignored the “advice” I was getting from the contractors who normally would guide the technical aspects of the effort. I also regularly ignored my boss who relied heavily on these same contractors to also manage the effort for him. I did this in large part because they were telling me NOT to do those things mentioned above.

I lived on the job. I loved the work. I was always there. I had no life outside of work. I learned a lot.

Why It Worked

1. While I was technically pretty good at that time, it turned out it was not my technical knowledge but my willingness to share that knowledge and get a core team up and going that made the difference. Past efforts used what I called a “superman” concept. One key technical person would be loaded down and managed. Everyone else would support this person. The supermen who did the job before me received some of the highest awards for technical achievement one can get in the Air Force. They also never delivered on time and had a very buggy product. The bugs we did find in our release were almost all left over from the previous years’ releases.

2. I got away with it because the commander of the unit had designated me the new “superman” when the last one moved on to his next assignment. I was supposed to be the person doing everything. Just not this way.

3. I was a bit more experienced than the average 2nd lieutenant. I had spent some years programming before college even as far back as high school. Back then, it was not common for high schools to have access to computers.

4. I believe we simply got more folks working on the problem then they had used in the past. We had a good solid quality approach to doing the job. Both parts were essential. Previously, it had been normal, for example, to check someone’s work. If a problem was found someone else would be assigned to fix it. Also, work was previously doled out as unrelated tasks (“here, change this code”) and not as logical areas of responsibility.

5, People worked hard, were successful when given a challenge and when allowed to do a good job.

6. We didn’t do anything radical or too unusual. In large part I believe this organization had just settled into a way of doing business and just couldn’t see how inefficient the approach was. They had been doing it this way for many years. Being “late and buggy” was normal and not considered a realistically solvable problem. Delivering on time, however, was always the stated highest priority goal.

What The Real Surprise Was

1. One manager confided: “they liked what you did but not how you did it!”

2. Essentially, I believe we upset the established order of who was in charge, who knew what was going on and how we went about it. It was clearly a higher priority to many managers to maintain that order than it was to deliver the system on schedule.

What We Learned

1. Throughout my career I discovered that most organizations did not require huge changes to move them up to the next level of performance. It did require someone to pay close attention to how the organization performed and to then make smart but rarely radical changes.

2. I would later conclude that this approach was not much different than what was to be found in techniques such as the Air Force’s Total Quality Management, Motorola’s Six Sigma or the Software Engineering Institute’s Capability Maturity Model. I would come to understand, appreciate and use these models in the future.

3. I needed to be aware of the personal impact of change on people. Change by itself is very unsettling and very stressful to many people and has to be taken into account.

4. I came to realize that doing things “differently” and succeeding had a peculiar effect on many people. This is well summarized by a quote from John Maynard Keynes in The General Theory of Employment, Interest, and Money:

“Worldly wisdom teaches that it is better for reputation to fail conventionally than to succeed unconventionally.”

Success at finally achieving an avowed goal was often strangely unpopular.