columns
watts new
Being Your Own Boss—Part I: The Ideal Job
This is the first of a series of columns on our work as developers and how we can have truly satisfying jobs. This first column in the series discusses ideal jobs, what developers like about their work, and what they find annoying and unpleasant. It then describes how the developers’ and managers’ views on project success differ and what this means for both developers and their organizations. In subsequent columns, I will discuss how to turn almost any job into an ideal job, some of the issues you will face in trying to do so, and the level of support you will need from your managers and peers to be successful. While there are a few basic conditions that must be satisfied before you can expect to transform any job into this ideal, it is surprising how many jobs can be rewarding when you approach them in the right way.
Job Satisfaction
In discussing job satisfaction, we must first answer the question: “Satisfaction for whom?” One would expect the characteristics of a satisfying job to be different for the person doing the job and for the person for whom it is done. However, there is one condition that is common: the job must have been a success. This, of course, leads to the next question: “How do managers and developers view project success?”
This question has been researched by Kurt Linberg [Linberg 99]. He studied the views of developers about project success for his PhD dissertation. In this study, he asked groups of developers to identify the most successful and least successful jobs on which they had worked. Then he examined the characteristics of the most successful and least successful projects.
Successful Projects
From the developers’ perspectives, the most successful projects had three common characteristics:
- The project was a technical challenge.
- The final product worked in the way that it was supposed to work.
- The team was small and performed well.
Some typical developer views about these successful jobs were that
- the product was well designed and implemented
- it was well tested
- the team members enjoyed working with each other
- they didn’t feel pressured by management
In addition, as long as the project manager protected the team, conflicts with other groups or with senior management didn’t seem to bother the team members. They also thought that the work was innovative, that there was a high level of trust among the team members and with the project manager, and that the team was highly motivated.
In general, the developers attributed their high levels of motivation to five things:
- a sense of making a contribution
- an orderly and well-managed working environment
- frequent celebrations of even small successes
- positive feedback from both management and marketing
- the autonomy to do the job in the way that they thought best
It didn’t seem to matter how important the project was to the organization or how well the team worked with other groups. In fact, it didn’t even matter whether the job was completed on time and within its budget.
Unsuccessful Projects
Conversely, the team members viewed the least successful projects as unrewarding, as having poorly defined requirements, and as having inconsistent or even nonexistent marketing support. Typically, these worst performing projects were perceived as
- not achievable from the outset
- under excessive management pressure
- requiring unreasonable levels of overtime
- technically frustrating
- having frequent conflict among team members
- operating in a chaotic environment
In summary, the developers’ views of project success were largely independent of cost or schedule performance. The team members viewed a project as successful if it was a rewarding and enjoyable experience, even if it was late and over budget. In other words, a successful project was a personally satisfying project.
Management’s Views of Project Success
Linberg also found that management’s views of project success or failure almost entirely concerned cost, schedule, and quality performance. Table 1 summarizes his findings on the definition of various levels of success or failure for both completed and cancelled projects [Linberg 99]. This study found that developers view some projects as successful even when management does not and vice versa. Having been a manager for many years and having seen how hard developers worked to meet their schedules, I thought this conclusion contradicted everything I have seen in more than 50 years of development experience. I have worked with hundreds of teams and supervised groups of thousands of developers who worked around the clock to meet their deadlines. Every team I have ever worked with has always made an extraordinary effort to meet cost and schedule commitments, and many of them were consistently successful in doing so.
A little reflection, however, shows that Linberg’s conclusions do not conflict with my experience. I never asked the teams how they viewed their projects. They were paid to meet management’s goals, and when they did, management was happy and everyone got paid. So, in summary, management views a project as highly successful if a team delivers a quality product on schedule and within its committed costs, regardless of how the team feels about the job. Conversely, development teams view projects as highly successful if they are professionally challenging and technically successful and if they provide a rewarding and personally satisfying working environment.
Common Management and Team Goals
While no rational managers would object if developers enjoyed their work, that is not one of the managers’ highest priorities. Similarly, developers universally would like to deliver quality products on schedule, and they even strive to do so, but they do it because they know it is their job. What they really want, however, is to have a rewarding experience.
While these views don’t necessarily conflict, they are not mutually supportive. This situation is what is called cognitive dissonance, where our views of reality differ from what we experience. In the case of a project, the developers know what success feels like. Many of them have experienced it on sports teams where a winning performance is an exhilarating experience, the coach congratulates the players, and the fans cheer. Everybody then helps in the celebration.
But development is different from competitive sports. Developers know that the managers’ kind of success is what the organization wants, and that what developers value most is not a management priority. Sometimes the team wins and nobody seems to care, and other times, it feels as if the team loses but management cheers. Cognitive dissonance is demotivating and debilitating; it is not the stuff that builds winning teams or ideal jobs.
Congruent Management and Team Goals
This raises the next question: “What would happen if the managers’ and developers’ views of project success reinforced and supported each other?” One team’s experiences illustrate what could happen. On their last project, members of this team had put in more than 70-hour weeks, worked under enormous pressure, and managed to deliver their product to test on time. Testing, however, took longer than anyone had expected, and the product was delivered late. It was delivered, however, and at the time I met with the team, it was being installed by the users. While this job wasn’t a complete failure in Linberg’s terms, it certainly wasn’t a big success from either management’s or the team’s perspective.
On the next project, however, the team members had a realistic plan; they did high quality work; they had capable leadership; they had clear, agreed-upon goals; and they believed that the team owned the project. This was their job and they were going to make it a success both for the team and for the business. They not only delivered their product to test on time, but it was of such high quality that testing was finished early. They only worked 45-hour weeks and were home for dinner with their families every night. They said it was the best project they had ever worked on, and management was full of praise.
How did they do it? The answer is that they and their management made a real effort to make this project a success for both the developers and the managers. More on how to do this in the June column.
Acknowledgments
First, I want to thank Bob Schaefer for his note. He asked about ways to handle conflicts between managers and developers and, in thinking about the answer, I got the idea for this series of columns. Also, 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 Bob Cannon, Julia Mullaney, and Bill Peterson.
In Closing, an Invitation to Readers
In this particular series of columns, I have discussed some of the development issues related to large-scale projects. As I now consider the topics to address in subsequent columns, I would appreciate any of your comments and suggestions. If there are topics that you feel are particularly important and would like to see covered, please drop me a note with your comments, questions, or suggestions. Better yet, include a 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@sei.cmu.edu
Reference
[Linberg 99]
Linberg, Kurt R. “Software Developer Perceptions about Software Project Failure: a Case Study,” The Journal of Systems and Software, 49 (1999) 177–192.
About the Author
Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and several books. His most recent books are Introduction to the Team Software Process (2000) and Winning With Software: An Executive Strategy (2002). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.