NEWS AT SEI
This article was originally published in News at SEI on: March 1, 2008
This fifth and final column on being your own boss describes how to take control of your own work. It covers the key issues you will face, the fears you must overcome, and the self-confidence and credibility you must build. While the challenge of doing all of this may seem daunting, and while it does take personal courage, it isn’t really that difficult. The key is to be willing and able to take responsibility for your commitments. While you can take all of these steps by yourself, it helps to have teammates to work with you. Once you know how to manage yourself, however, you will not want to work any other way.
Starting a Job
To take charge of your own work, you must assert your position at the very beginning of every job. It is the only way that you will be able to consistently work on projects with realistic schedules and plans. Working in this way, however, requires the courage to take personal risks, a willingness to step out of the crowd, and the responsibility to own your own work.
Just about every one of us in the software business has been regularly told what to do and when to do it. This is the way our business has always been run. While there are many reasons for this state of affairs, the fundamental cause is that management does not trust us to establish our own plans or to set our own schedules. This is not surprising, however, for, with few exceptions, when software groups have been asked to make their own commitments, they have rarely met them.
So you start out with two strikes against you. In this negative environment, you must somehow convince your managers that they can trust you to do what you say. Then, of course, you must do what you promised. This is critical, because if you don’t, it will be even harder to convince management the next time. To do all of this, however, you must overcome some fears and build your self confidence. Only then will you be able to convince your managers that they can trust you. The challenges are to overcome fears, to build self-confidence, and to establish trust.
While there are many kinds of fears, the worst ones are fears of the unknown. The best way to deal with these is to consider rationally what is most likely to happen and to assess all of the realistic outcomes. For example, suppose management told you and your teammates that this new project must be done in three months. And suppose also that none of you believed there was the slightest chance that you could do the job in that time. What would happen if you told management that three months was not nearly enough time?
In response, management is likely to say one of two things. First, they could say: “Three months is critical to the business, so do your best.” Since you can’t refuse to try, all you can do is agree and, regardless of what you think, you will then be stuck with a three-month commitment for doing the job. The second thing management could say is: “How long do you think it will take?” Then you would probably have to answer: “While I don’t know how long it will take, it will certainly be longer than three months.” Then you will again get management’s first answer and be stuck with the same three-month schedule.
Of course, instead of saying you don’t know how long the job will take, you could make a guess and say it will take five months. At this point, any manager with half a brain would say: “Prove it.” And again, unless you had a really convincing story, you would be stuck with the same three-month schedule. So this fear is really not an unknown at all. If you complain about the short schedule, there are very few possible outcomes, and they all end up exactly where you started: stuck with the three-month schedule. There is, however, another approach you could take and it concerns building your self-confidence.
Some people can speak with assurance about things they don’t know or understand, but that skill is more common to politicians than technical people. The fundamental problem with bluffing is that the person with the most resources or power usually wins. In development work, of course, that is the manager and not the developer. This means that if you want to debate the schedule with your management, you must know what you are talking about.
This suggests that you follow a different strategy. Now, when management says that the job must be done in three months, first make sure that you understand what they want you to do and then tell management that you need to make a plan before you can discuss the schedule. At this point, management really has only two choices: They could refuse to let you make a plan or they could agree and wait for you to come back. In all of my years in development work, I have never run into a manager who refused to let the developers make a plan. While the manager may be surprised at your request, he or she will invariably agree to let you make a plan, as long as you don’t take too long.
This means that you will almost certainly be faced with the need to make a plan. In doing so, however, you must try to make a plan that does the job on the requested schedule. Then, if you can’t, you will know why and be able to explain the problem to management. Better yet, you could propose several alternate plans, each of which meets some but not all of management’s goals. Also, of course, you must know how to make a realistic and convincing plan. I have written extensively on this subject, and if you are working by yourself, the best reference is PSP: A Self-Improvement Process for Software Engineers [Humphrey 05]. If, however, you are part of a development team, you should still consult this PSP reference but also look at: TSP: Coaching Development Teams [Humphrey 06].
Let’s assume that you are to do the job by yourself and that you have now made a plan. Also let’s assume that, in making this plan, you followed the methods described in the PSP book. Now your job is to convince management that you have made a realistic and aggressive plan and that you are willing to commit to a delivery schedule. Also, if history is any guide, you will have found that this job is far too big for you to complete in the desired three months, and that five months would be required. To make your plan presentation to management convincing, you must describe both how you made the plan and the plan itself. The key topics to cover in this meeting are the following:
- the goals of the project—in this case, to finish in three months
- the assumptions you made—presumably about the requirements and other key project characteristics
- your concept of what the product will look like
- your estimate of the product’s size and how it compares to other previously developed products
- your estimate for the time required to develop the product and the data you used to make this estimate
- some alternate plans that show how adding resources or reducing product function could shorten the schedule
- the recommended plan and schedule
- the key project risks and recommended mitigation actions
While this is a lot of work, it is a lot easier than struggling for months with an unrealistic plan and schedule. Furthermore, with a little guidance and experience, you will find that it takes surprisingly little time to make such a plan. For your own personal work, you should be able to make such a plan in a few hours to a day or two. Even teams building large products can typically make these plans in about a week. Finally, I can guarantee that, if you take these steps and make such a presentation, management will trust your plan and negotiate an aggressive but realistic schedule with you.
Once you have produced a complete and realistic plan, and once you have convinced management to accept that plan, you can get to work. However, as you do the work, you must continue to maintain management’s trust. Trust is fleeting, and after a relatively brief period, management will start to worry and begin to suspect that you are having problems. Given a little time, they will even start thinking that you cannot be trusted to meet your commitments. To counter this natural tendency, you must keep management regularly informed about your status and progress.
Again, this is not that difficult, and the PSP and TSP books can show you how to do it. I have found that, at the project level, weekly reports to your immediate managers are required. If you waited for a month between reports, management would almost certainly worry and even two weeks is probably too long. These reports should factually describe your progress and summarize any key issues and problems together with the actions you are taking to address them. By doing this, you can keep management on your side and ensure that they will be willing and able to help you if you run into serious problems.
Since problems are common in development work, and since some of these problems are likely to impact your schedule, you will occasionally find that you cannot meet an important commitment. While preparing a sound and detailed project plan will usually enable you to meet your commitments, occasionally that won’t be possible. This is when frequent management reports are most important. As soon as you know that the schedule is exposed and that you are almost certain to miss the date, go to your management for help. As long as you keep them regularly informed and give them plenty of warning of problems, they will be willing to help solve the problems. Then, even if you do have to miss the schedule, management will continue to trust you to manage your own work.
Commitments in Practice
Depending of your organization’s business, use the same commitment principles but follow different implementation practices. For example, with an existing fixed-price contract, cost and schedule will be paramount and the key will be finding the alternative approaches that most closely meet the existing commitments. Since even fixed-price contracts can run late and over cost, however, make the most realistic plans that you can and face any bad news as quickly as possible. When developers merely hope things will improve, they practically never do. Then, when the bad news must be faced, there is no time to consider alternatives or prepare for the overruns. While the bearers of bad new are often shot, if you know what you are talking about and can defend your story, you will almost always come out ahead. But since there are no guarantees in this business, you must have the courage of your convictions.
Regardless of the business situation or the size and scope of the job, you will know least about the job at the beginning and learn more as development proceeds. Therefore, for any reasonably sized project, you must make progressively more detailed and better informed plans every few months. Also, since it is impossible to make detailed plans for complex development work that extend for more than three or four months, you must regularly replan anyway.
Regardless of your situation, the key is to negotiate a realistic plan and commitment at the beginning. Then, as you learn more about the work, continue refining your plan as you strive to meet that commitment. If you find that you can no longer meet the commitment, get to management right away so they can both help you meet the commitment and prepare for any possible delay.
This series of five articles has described how to take charge of your personal work and explained why this is the only way to have a truly satisfying and rewarding work life. The first column in the series described the different ways that managers and developers view success and it concluded that, to be truly successful, projects must be successful for both the managers and the developers. The second column pointed out that managers often seem autocratic merely because their developers don’t know how to make accurate plans or consistently meet commitments. The third column points out that the only ones who can make accurate and useful plans for knowledge-working projects like software development are the knowledge workers themselves. Part four of the series then describes the five steps required for developers to take charge of their own work, and part five discusses the challenges and risks of actually doing so. Taking charge of our own work is the key to a rewarding and satisfying career. Once you know how to do it, you won’t want to work in any other way.
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Tim Chick, Julia Mullaney, and Bob Stoddard.
In Closing, an Invitation to Readers
In these columns, I discuss development issues and how they impact the work of engineers and their organizations. However, I am most interested in addressing the issues that you feel are important. So, please drop me a note with your comments, questions, or suggestions. Better yet, include a war story or brief anecdote to illustrate your ideas. I will read your notes and consider them when planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
Watts S. Humphrey, PSP: A Self-Improvement Process for Software Engineers, Reading, MA: Addison Wesley, 2005.
Watts S. Humphrey, TSP: Coaching Development Teams, Reading MA: Addison Wesley: 2006.