You say you want a revolution ...

Revolution and evolution. Destination and directions. Do not confuse your need to have a company or team vision with how they get there.

I always say that my goals are revolutionary and I make every attempt to have my methods be evolutionary. Sometimes even little common sense things can take a long time. When it comes to change, trust is key. When I took over the Solaris (TM) team at Sun, no one tracked progress of the team's efforts. I resisted instituting such a process until I had fought some battles on their behalf. Even then I posed it as a question to my staff "How can we know if our teams are working consistently and successfully?"

You need to think big and bold in order to ignite your team's imagination but you must translate those thoughts into practical tasks. Both thoughts and tasks are important. Did you ever try to give a driver step-by-step directions without them knowing the destination. It is unsettling and disconcerting for the driver. The same is true for your developers. If you cannot articulate your team's destination and your company's destination, they will be unsettled, less motivated, and more prone to leave.

Sometimes change is necessary to reach your destination. The ability to change is important to any organization. Brokering change is difficult. It takes time and patience. Most of the time you need to continue to produce product while you make change. It is akin, as one of my previous managers used to say, to figuring out how to re-tool the engine of an airplane mid-flight and still land on time. Do not underestimate what developers look at as change. From my understanding, before GE took on Six Sigma (TM) they developed a process to help adopt change because they knew they could not make the Six-Sigma-discovered changes without such a mechanism.

Think big and plan thoughtfully!

More later ...

Schedules, Schedules, Schedules

Why create schedules? How do you make schedules? How do you get your team buy-in to schedules?

Schedules are about predictability. This may be obvious to you but get lost on the way to the troops. It is always important to talk about rationale. You need to be able to predict product availability so your sales team can sell and your executive team can predict revenues for budgeting and investor purposes. You need to be able to predict integrations points between constituents on your team like QA or docs and development. Your developers need to predict when they need to work harder or longer and when they are done and can go home for the weekend.

Schedules are not rocket science but they do require effort. First you need agreement on what you are building and therefore you need both requirements documents and preliminary engineering specifications and you need them to be consistent. Next you to do project decomposition and there are a lot of books on this subject (just google software project decomposition). Next you must define integration points. Some hints:

• Only schedule 4 days a week
• Update the schedule weekly and do not let slips go unattended
• Don't let people go home if they do not finish their tasks
• Make people sequentialize their tasks even if it takes longer. Mounds of partially completed tasks will result in slips
• Allocate enough time for docs, qa, integration and field test feedback

Many engineers will tell you that software is not schedulable. They are wrong but it something that can only be believed when experienced. Get some people who have done it before as part of your team. Make your first release smaller and eminently accomplishable to help get your team experience. Goals have to be top down but schedules have to be bottoms up --- do not dictate dates.

Persevere.

More later ...

What do you do when you make a mistake?

Many of us grew our careers through the engineering ranks. Engineering is more black and white than management. Either your code works or it does not. When an engineer becomes a manager that kind of thinking has to change. Everyday managers are faced with things that do not work like people leaving their teams, irate or lost customers, bugs in their products, etc.

Managers cannot afford to be paralyzed by setbacks. They need to obtain the mentality of a baseball player that loses a game one day and goes out with energy to win the next day. The most successful teams have winning percentages of 50% and the most successful ballplayers have hitting averages of around 30%. Managers have to learn how to sleep well after a failure and get up the next with energy and win.

Some of the aforementioned setbacks will be due to manager mistakes. These may be the hardest to overcome. I have personally done things like shorten development cycles or said the wrong thing at the wrong time resulting in missed schedules or unhappy peers and employees. The question you need to ask yourself is what do you when you make a mistake?

Here are some things that work for me:

• Get up the next day with energy
• Do not be embarrassed
• Take responsibility for your actions
• Acknowledge the mistake before you are told about it by others
• Look at the problems ensuing from the mistake as just things to be solved
• Put a plan together
• Work harder and longer to make up for your actions
• Work with your team to deal with the problem
• Be open minded
• Learn from your mistake

These are not easy things to do but they can make all of the difference in your success as a manager.

More later ...