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

Why write a book?

Today I formally launched my book 100 Questions to Ask Your Software Organization. The official press release went out. The book is available for sale. But why write a book? What was I trying to accomplish?

I had been writing some form of the book in my head for 9 years. When I sat down to write the book, it popped out of me. I wanted to write a practical, easy-to-read, scalable guide for software managers and executives who have software organizations reporting to them.

As I walked into organizations as a full time employee or as a consultant, I was applying some of the same methods time and time again. I wanted a guide to remind myself about those methods. I wanted a concise mechanism to help communicate with the team about my methods and my intent. I wanted a basis for discussion about better software management.

I talked to a lot of people along the way. One of those people was a venture capitalist who said he needed a better way to understand and evaluate software organizations in his portfolio. With that comment, I adopted the question format. I have been told by readers that it helps the momentum of the book. The questions lead the reader in the right direction and the words that follow strive to help the reader understand what is important to consider as they develop answers for themselves.

There is a crisis in this industry. Late and poor quality software are the norm and not the exception. Disgruntled and burnt-out employees are almost expected. Customers assume they cannot trust vendors based on real historical evidence.

We can do better. It is not rocket science.

Realistic budgets and roadmaps. Clear roles and responsibilities. Effective and efficient processes.

Leadership.

With this book I challenge you all to start a new dialogue. To begin anew. To be better.

More later ...

What does "Done" mean?

According to Webster, done is the past participle of do. According to Webster, do's definition includes produce, perform, execute, commit and carry-out. The problem with these definitions is that they do not speak to the agreement required by multiple parties as to the contextual semantics of the state of being done. In other words, when do all parties agree a product is produced or a task carried-out? This is a topic worth exploring because it causes angst, misunderstandings, delays in products, missing product quality, etc.

I recall a start-up I worked in a number of years back that had a fairly large release to accomplish. The release included new hardware and new software from the firmware through GUI. I was brought in to run the software group and more explicitly to execute. We had all of the typical problems: top-down dates, too much work for the number of resources, poorly defined features, unmade critical decisions. I worked on all of these with the team. I helped force clear and complete decisions. I helped set expectations about what really could be accomplished and divided the work into required and second tier. I helped the team make real schedules. When we got to the code complete milestone, my engineers said they were complete but we were not complete. Why did that happen?

I made the mistake that everyone shared the same concept of the word "done". To me, done, was, well, done! My engineers and even some of my managers thought that close was good enough. Of course this caused all hell to break loose. The QA folks could not test, the product management folks screamed publicly, and the engineers felt put-upon.

So now I take the time at team meeting to express my definition of done. When a project starts, I look each developer in the eye and ask them if they stand by their schedules. I require specs that can be compared with requirements documents so there can be no misunderstandings. I require developers write reproducible unit tests that can verify tasks do what they say they do before check-in.

Were my engineers bad or unique? No to both of those questions. Many engineers are not taught the meaning of the word "done" or worse yet, they are castigated for it. This is the new millennium and there are some basics when it comes to development. Take the time to agree with your team as to when they are done ...

More later ...

What can you do about over-commitment?

I just heard a fellow on NPR talk about his book called Results : Keep What's Good, Fix What's Wrong, and Unlock Great Performance. His name was Bruce Pasternick. Someone called in and asked him about the increased workload in the corporate world today. He pointed out that employees have been taking issue with this forever.

The Internet boom and follow-on Tech bust may make you feel like the problem is worse today. Do things on Internet time with less people. The squeeze is on. Large companies play catch up and leap frog quicker with competitors. Small companies get led around by customers for new features and products. Your employees either get burnt out or ignore the pressure and work to the level that meets there abilities like water seeking it's own level.

The results are unhappy customers with missed expectations and unhappy employees with little in the way of sanity or home life. Is there a way to do it all and within budget? Is there a way to retain your humanity along the way? There are good solutions to this issue and like all good solutions everyone will have to compromise.

It is all back to basics. Here are the steps to avoid over-commitments:

• Create a budget
• Get buy-in from product management, sales and support
• Instill development hygiene
• Handle surprises and requests

As a manager, your first job with the highest priority is to get a budget in place with a proposed set of deliverables. Your team has to develop estimates. Everyone hates to develop estimates, but you cannot do planning without them. Divide the work into external work that the customer sees directly and sales cares about and internal work that has to be done to keep the infrastructure going. Prioritize the projects with product management. Make sure you account for ongoing maintenance.

Plan regular frequent, smaller releases instead of larger releases with a lot of features. Large releases are hard to integrate and requirements often change during their development which often leads to delays.

Balance internal and external work in your releases. If you do not have some balance, your company will fail. You need features to meet customer demands and be competitive. You also need the basis and infrastructure to scale and extend your product.

Once you have a budget and plan for releases, you must get buy-in. I favor actual signatures by key stakeholders on the executive staff. Nothing like a signature to make people pay attention. Both the overall plan and individual release plans need approval. Often, you will find last minute intense discussions when you hit this step.

Now you have a budget. Go to work. All of the things you learned now come into play. PRDs, design specifications, architecture, code reviews, automated testing, adequate integration cycles, design patterns, coding conventions, well-defined APIs, detailed schedules, documentation, diagnosability, etc. Pay now or pay later. You can streamline processes and procedures but skipping them will cost you more time in the end.

Finally, the hardest item. What happens when you get a critical new unplanned requirement? What happens when you find a bug in the field that requires unplanned effort from your best resources? This is where many plans fall apart. You need a mechanism to evaluate and approve any changes. You only have four areas you can adjust: resources, schedule, features, quality. If you go back to the same area each time you have a change, your company will fail.

Make sure the business case for fixing a bug or doing a new feature make sense. Make sure the change is weighed against the other work you are doing. Get creative: bring in contractors, find bridge solutions, look at third party solutions, employ swat team efforts, learn how to say no, learn how to sell what you have, etc. Don't start work on a new feature until it is clear how you can afford it.

Don't assume you can just add one more thing your development team has to do without some other change to the equation. Especially when it is the third, fourth, or fifth change! Don't get caught in just saying yes. In the end your customers will suffer will late or low quality products and therefore your company will suffer with lost reputation or sales.

Use these basic steps and you will manage your commitments.

More later ...

Who is responsible for quality?

I had the pleasure this week of speaking at a chapter of ASQ (American Society for Quality). I chose a topic which is near and dear to me: Roles and Responsibilities. Applying that topic to this venue meant speaking about quality.

I felt I had a big challenge going into a group of quality professionals because both my book and my consulting practice help organizations strive for excellence and that is part of what quality professionals try to accomplish as well. I was heading into their home turf. I was going to preach to the converted.

The way I approached it was to discuss what I would try to accomplish with product development engineers. I asked them to suspend belief and maybe they could use some of my philosophies and techniques to their advantage. With me being the only thing between them and dinner, I was pleased by their interest, excitement and acceptance of the talk.

So who is responsible for Quality? The answer is obviously everyone. If you ever cordon off responsibility for quality to some group you will not achieve quality in your product.

I am also, as I say in my book, a firm believer in having one owner for each task or goal (they may delegate pieces but they must make it happen). So, who is responsible for Quality in a product? The answer is the person responsible for developing the product. No finger pointing, no blame and very simple.

This is a leadership thing. Your leaders must make quality a priority and legitimize time. The must set expectations that everyone must do their part and be held accountable. Without these critical pieces, you will not achieve quality in your product.

So what does this mean on a practical basis? Here is one example that I try to implement in each company I participate in: exhaustive functional unit tests. I require the engineers development products be responsible for the basic tests that prove what they developed works. Code cannot be checked in without those tests complete, run, working and code reviewed just like the product itself.

What does this accomplish? It pushes quality earlier in the cycle, makes it easier to get a quality product and enables accountability. It is hard. It is different. It is effective.

How does this affect accountability? Imagine, if you will, a salesman who sells a lot of product but his customers never pay or we have no idea if they ever pay. There is a reason why commissions are paid out on receipt of customer payment. The same thing goes for software. If a developer codes away and never proves their software works then they are not completing their job and the value to their company is significantly reduced.

More later ...

Welcome!

This blog is all about helping you and your teams succeed at your goals!

I have moved this blog from it's previous location and will re-post previous entries.