Does your team have a sense of urgency?

Does your staff drive action items or do they let them happen? Do you have to check on action items you have assigned or does your staff update you on a regular basis? Do projects slip because your staff waited to follow up on action items?

I get astounded all the time by people who do not follow up on critical action items in a timely fashion. Some people do not have a sense of priority. Some people do not have a sense of how much time they will lose if they just let events play out. Some people just to not have the drive to follow through quickly.

You and your teams can easily slip products days or weeks or months without a sense of urgency.

Recently I was involved in a project that was coming to the end of an integration cycle. I was getting status on a Friday morning. I was told that one bug may have an unbounded solution. The manager went on to say that he thought he would get people together that afternoon to discuss it. I said no that we would meet in 10 minutes. If we had not met, then we would have lost at least one half week. By meeting immediately, developers had time to research solutions before the weekend and begin the work. These kind of issues occur everyday.

Here are things I know to do to help this issue:

• Hire people with a sense of urgency
• Set expectations about action items
• Spend time communicating to your group about urgency
• Hold people accountable for being late
• Developing a team with a sense of urgency will, many times, make the difference between success and failure.

More later ...

Is your team working hard enough?

Do you dictate fixed working hours? How do you compare work ethics? What can you do if you are behind?

Every company I have ever been in has worried that the development teams were not working hard enough.

The first thing you must do is decide what kind of work ethic you want in your team or company. Do not think this will happen by magic. Actually sit down and discuss it. Write it down.

Next you need to communicate it to your team. If you have a team in place, expect some fallout. Face it honestly "I know up until now we have had a different set of rules, but now we need to set down some new rules. I understand if this is not what you signed up for and we will help you transition if it is not right for you ..." Having disgruntled employees is worse than replacing some. Obviously job markets, critical company timing and other factor must be taken into account.

You need to be clear to anyone you interview about what the team's rules are.

I have known some companies to dictate 12 hour days, 6-7 day working weeks or fixed hours. There are lots of great examples of successful companies that have aggressive rules and demands. I am not saying one is right or wrong. The important thing is that you make it clear what you want from your employees.

Personally, I like to build teams for the long run. I want to set goals that are aggressive but accomplishable. I want my teams to only work the 60+ hour weeks 2-4 times a year for periods of no longer than a month at a time.

I find that the average age in the industry is a little higher than when I started out and I find that more people have families. I want employees to have balance. I want them fresh the next time I need them for a crisis. I want them to have enough outside interests so that if the company is having issues, the company is not the only thing of importance in their worlds.

When I run an organization, it is schedule driven. For me, the important thing is that we accomplish our tasks in an aggressive and predictable fashion. I care more about function than form. I expect employees to develop their own schedules. From there it is a means test. If a developer is running behind I expect them to work harder. During integration times I expect them to work harder. It is good for employees to know when they can go home at the end of the week. See My blog entries on schedules and what "Done" means.

My final words here are about accountability. Make sure your employees understand how they will be held accountable. Make sure consequences are in fact applied.

By being clear you can get the team you want.

More later ...

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 ...

How do you make progress on your roadmap in the face of firefighting?

This is an ongoing question from the moment that you have a product and even a prospective customer. Real-time requirements for assistance, demos, features and bugfixing are common diversions for many engineering groups. So how do you handle this natural competition for resources?

The first thing you need is a roadmap. Without clear plans and goals you won't even know what you are not doing. Time can slip by easily in fire-fighting mode and along with it market opportunities.

The next thing you need is a budget. You need to legitimize the time spent on diversions from the roadmap. Do not expect your developers to handle a full development load along with a second development load for bugfixing. Another key to successfully managing resource competition is to firewall resources for new development (see Christensen's 1997 book The Innovator's Dilemma).

The next thing you need is some process. Decent schedules which represent all of the activities engineering is responsible for is a must. If new opportunities arise, do not assume the team can just lump more work on. I like schedules to be aggressive but accomplishable -- where the key word is accomplishable. Put a process in place that allows for change. If a new feature is needed, will you fund it with new resources, re-target resources working on some of projects, etc. ? Outside influence can begin to look like a fire-fight. Changing directions too often will be inefficient and depress developers.

Finally you need leadership. Understand your team's capacity. Understand your company's financial and competitive situation. Aggressive but accomplishable.

More later ...

Live to work or work to live?

This is a question that many people ask implicitly or explicitly. It is a value that changes during a lifetime. Teenagers might feel work minimally to live only to become twenty-something work-aholics to become burned-out forty-somethings trying to reconnect with their families. The lucky among us find balance. But let's go back to the question, what should you do? How should you think about work?

I have the pleasure of being the dad to a wonderful teenage girl who is starting to be interested in the inevitability of work. She wants to earn enough to do stuff. She doesn't feel like she needs to live my lifestyle (yet:-). She is getting pressure from her school to think about careers. So I will lean on what I tell her as I write this entry.

I tell her she has to do two things: find something she enjoys doing a lot and be passionate about and find something that will pay the bills for the lifestyle she chooses.

In reading the first item, I think the keyword is passion. When I started working a colleague of mine said "If you are not willing to put in more than eight hours in a job, why are you willing to put in eight?" The upshot of his statement was that when we work we invest our most alert and most valuable hours of our day and we should use those hours doing something we love and are passionate about. I agree with him.

If you only work to meet your financial needs, you will be miserable. Sometimes we have to do things we would otherwise choose not to do. You need to understand this aspect of your life. However, I suspect that most of us can figure out how to do something we are passionate about and still pay the bills.

When I hire people, I look for people who have that passion. I do not want someone just paying the bills or putting in time.

So how do I answer this for myself? I live to be passionate and excited about all aspects of my life and today that includes work.

More later ...