On Leadership

Pollyanna Pixton Asked me how my thoughts on leadership came to be. Here's a quick braindump:

>How did your thoughts evolve?

Now _that_ is an interesting question!

I spent seven years as a Civil Air Patrol Cadet while also reading the military science and science fiction success literature - especially Robert Heinlein.

You can learn a bit about that part of my life by checking out my amazon listmania lists:

https://www.amazon.com/gp/pdp/profile/A1MQIGB1G0X1ZA/103-6394374-2847053

During my time as a cadet, I mostly sought leadership ("command") positions; I desired power and position. We used to have these summer encampments where we "beat down" the first year cadets and then "built them back up in our image" - I never agreed with that model. Instead of summer encampment, the summer I was seventeen I went through real US Army Basic Training (In the Reserve), and realized there was a lot more too it than that. It's something between naive and just plain wrong to assume that a bunch of teenagers can do in a week what takes professional, trained drill sergeants do in two months.

Oh, and fear is a crappy motivator.

The following summer in staff training, I stood up and said "I think we're doing this wrong. Shouldn't our goal be to inspire cheerful and willing obedience to orders?"

Yes, it was a cliche, but that was good - half the room had heard the term before. The attitude of that encampment was split about 50/50, but I'm proud of what we did that year.

At 20 I became a professional programmer, and at 22 accepted a commission as an officer in the Civil Air Patrol. As an adult, my role changed from executive to advisor, coach, and mentor to cadets. About this time I realized that command was no test of leadership; people were expected to obey orders. Instead of seeking command positions where people had to listen to me, I sought staff positions where people had the option of ignoring me. That way, I had to develop my influence skills.

Professionally, I graduated with a Math degree and a concentration in Computer Science, not a CS degree, so I felt insecure about my skills, so I read every book I could find on development and methodology to "catch up." Eventually, I found that I knew more than the guy next to me, but I was still "Wrong" because I didn't get it; I kept going for this simple, elegant solutions instead of developing robust, reusable frameworks. I kept arguing for developing features in slices and saying that our crystal ball was wrong; every time we spent 6 months developing an extensible framework, the customer would request a new feature and we'd say "Gee, we never thought of that. THAT possibility isn't in our extensible framework ..."

Clearly, I didn't get it, so I went back to school at night and earned an MS in Computer Information Systems. About this time, I was studying Eli Goldratt, Alfhie Kohn, John P. Kotter, Michael Porter, Ed Yourdon, Steve McConnell, and Ron Jeffries. When I found extreme programming I about blew a gasket. :-)

Oh, I read Fred Taylor and Peter Drucker, and realized that the command and control structures in the typical North American company are based on an out-moded, anti-intellectual-for-workers approach that Taylor developed for European Immigrants in the early 1900's. The typical employee of his first study had, on average, a 3rd Grade Education - typically in German. Just like Drucker said, today's white collar worker is better educated and has a larger scope of responsibility than the 2nd-level supervisor of 1910.

After that, I started studying Jerry Weinberg and General Systems thinking. When I graduated, I found that I had developed a habit of spending ten hours a week on professional development, and just kept at it, turning that time into writing, speaking, and consulting.

Which takes us to today. I view software development as intellectually challenging, creative work. I am interested in two forms of innovation - upstream (ideas to improve the product) and downstream (ideas to change and improve the process.)

My curent bugabo is Traditional "process improvement" models that focus on creating stable, predictable, repeatable systems, or the focus on implementing a complete spec. My software projects are all different; trying to be repeatable when you are doing different things doesn't make sense to me. And the focus on the complete spec over collaboration eliminates my ability to do upstream innovation.

After fifteen years of feeling insecure about my skills and being patted on the head, told that one day I will "get it", I'm beginning to believe that it is in fact the Cult Of Repeatability that doesn't get it. I think they read the two-page summaries of Deming, Juran and Crosby and missed the point. They should go back and read the entire book.

--heusser