Well, that's an interesting question that I actually get asked quite a bit. You see, I have been "in business" for 25 years. I started as a programmer on old 16-bit PDP-11 computers (when 128KB of memory cost $10,000 and fit in a refrigerator box, and a 10mb disk was HUGE) back in late '70s. I moved up to "operating systems guru" on "new" 32-bit operating system called VMS. I was actually quite good, and could program assembly language faster than virtually everyone could code BASIC (someone dared me to prove this once so we took out a stopwatch and programmer a database application, and I finished it in a quarter time as expert BASIC programmer).

>From there, I moved onwards to design and analysis as well as project management, then to higher management (working my way up to a Vice President). Now I am a director of a multi-billion dollar company (Director of computer operations and technical services).

Why tell you this? I've managed hundreds of people and have to deal with question virtually every day (now I manage about a dozen). People (from my own department and others) ask me questions like: What should I do next? What training should I be doing? Should I be attending conferences? What books should I be reading? I always answer carefully, as this could mean difference between employment or unemployment, or a good raise and a not-so-good raise. I want people to do well, so I try very hard to guide them properly.

What is most important thing I've learned? Perhaps it sounds corny, but it's ability to look and to see what's actually there. To examine a problem and see problem, with no bias or assumptions. To look at a project plan and pick out all of assumptions (which can then be tested for accuracy), or to look at a program and see bugs or flaws.

An example? Sure. Someone I knew worked for one of my peers. Over a period of several weeks, I kept hearing about a severe, horrible problem which was delaying a major project. It was not my project and I did not manage person, and had my own fires going, so only heard about this in weekly meetings. This guy worked on this problem for weeks, literally weeks. He changed code over and over, tested and retested, had meeting after meeting, involved a dozen other people and spent tens of thousands of dollars of consulting money.

One day I happened to pass him in halls and got into a conversation about problem. I could see he was upset and decided I could possibly lend a few words of advice. He described issue and my jaw dropped open. He was trying to figure out why some critical numbers were not being transferred from payroll system to general ledger. It was critical that these numbers show up in general ledger.

I successfully kept from laughing out loud as I explained that payroll numbers didn't show up on general ledger because payroll programs didn't post to general ledger. It was quite simple really, and if he had taken time to actually ask users he would have discovered that they hand-entered numbers after each payroll. What happened was one week numbers didn't get to general ledger and he assumed there was a problem. If he had simply looked at what was there to be seen, he would have discovered that payroll person was out sick that week. A temp had run payroll, and hadn't known to enter numbers in general ledger. It was that simple. There actually was not a problem at all, yet we spent over 200 man-hours and twenty-five thousand dollars to try and find it!

The second most important lesson is that people are important. People are not machines, they are not commodities and they are not objects to be manipulated. People have feelings and they are to be allowed to be themselves, to have rights and freedoms. That does not mean you let them do whatever they want (you have to manage things if you are a manager) but you have to understand, communicate and respect them.

Why is this important? If you treat people badly or don't communicate with them you will find them uncooperative and even belligerent at times.