Being Your Own Boss—Part II: The Autocratic Manager

NEWS AT SEI

Author

Watts S. Humphrey

This library item is related to the following area(s) of work:

Process Improvement

This article was originally published in News at SEI on: May 1, 2007

This is the second in a series of columns on being your own boss. The prior column discussed ideal jobs, what developers like about their work, and what they don’t like. It also described how managers’ and developers’ views differ about project success and what this means to developers, managers, and their organizations. In this column, I talk about autocratic managers, autocratic behavior and why it is common, and the consequences of autocratic behavior. In subsequent columns, I will discuss why an autocratic management style is not appropriate for modern development work, the alternatives to autocratic management styles, and how each developer can take charge of his or her personal working environment to turn a seemingly unpleasant job into an ideal one.

The Autocratic Boss

Autocratic bosses are common. Starting with the construction of the early pyramids in Egypt, the literature is full of examples. Bosses have historically been slave drivers, demons with whips, or guards with guns. Historically, workers may have been slaves or prisoners, but that is not true of typical working environments today. However, in development work, bosses typically have very substantial power, and workers do not. This power confers a level of authority that bosses can use in autocratic ways.

Even when the boss is charming and seemingly respectful and friendly, that boss would still be an autocrat if he or she behaved unilaterally. Autocrats do not really consider the feelings or views of their workers. While this may sound extreme, it really is not. The true test is whether the boss actually considers your needs and views in making decisions. Merely pretending to listen to your opinions does not change the facts. A typical autocrat in effect says, “Let’s compromise and do it my way.”

Why Is Autocratic Behavior Common?

Autocratic behavior is common because it can have substantial advantages for the autocrat. For example, autocratic decisions can be made quickly. Assuming that the autocrat is technically competent, this could be advantageous in dangerous situations like military campaigns or natural disasters. Autocratic behavior could also be effective when the autocrat-boss was better informed and more competent than the workers. This is often the case for simple and highly repetitive work. The autocrat can also get substantial personal rewards from unilateral action. Every time some autocratic command is promptly and successfully carried out, the autocrat’s belief in his or her competence and infallibility is reinforced. This self-reinforcing characteristic of power led Lord Acton to say over 100 years ago that “power corrupts, and absolute power corrupts absolutely.”

While this conclusion has been widely recognized and quoted, there is another similar conclusion that is not as well known: “Petty powers are most corrupting.” Philip Zimbardo found this to be the case in simulated-prison experiments at Stanford University in the 1970s [Gladwell 1973]. Zimbardo enlisted volunteers to act like prisoners and guards in a simulated prison. They had built a facility just like a prison in the laboratory basement and actually locked up the volunteer “prisoners.”

What Zimbardo found was that, after only a couple of days, the “guards” started to behave so abusively that one of the “prisoners” actually had a severe emotional breakdown. He had to stop the planned two-week experiment in only six days. He concluded that ordinary people will often act in authoritarian ways when they are given even menial jobs that have some minor but absolute powers.

Zimbardo’s conclusion can be seen in the behavior of many bureaucrats: they often tend to use their limited powers in arbitrary and highly authoritarian ways. This is what makes some clerks, guards, or other support people insist on strictly interpreting the rules although that interpretation would make no logical sense in the specific case at hand. This kind of strict adherence to work rules makes organizations unresponsive and hard to work with. It can also be expensive and demotivating.

Why People Are Autocratic

There are four reasons for people to behave autocratically.

  1. There is a crisis.
  2. There is a power vacuum, and they feel they must take charge.
  3. They act autocratically because that is the way such jobs have always been done.
  4. They get emotional benefits from being autocratic.

The Crisis—In times of crisis, rapid decisions are often required, and a single authority is usually thought to be most effective. Most people understand and accept that this is the best way to behave in such cases.

The Power Vacuum—A power vacuum can occur in a crisis when the leader is either killed or otherwise unavailable and someone takes over. Such cases can arise in almost any situation, and it may be seen in combat when the commanding officer is killed, and a sergeant or even a private takes charge. While this situation need not lead to autocratic behavior, it generally does when nobody else seems willing to or able to make the needed decisions.

Force of Habit—While power vacuums can occur in development, the force-of-habit case is more typical. Development managers have generally managed in this way so pretty much everyone does. Furthermore, since it seems so natural and expected for the boss to make all of the decisions, force of habit tends to create power vacuums. Nobody but the designated boss feels able to make decisions.

Emotional Reinforcement—Emotional reinforcement presents an entirely different situation. When the person has clear authority and resists either suggestions or appeals to common sense, it is generally a good idea to keep quiet and do what you are told. If this person is your boss, it may not be clear whether he or she would accept suggestions or not. This is when you may have to conduct tentative tests to see how your suggestions are received. While I have only seen a couple of truly autocratic managers in 50+ years of development experience, they do exist, and they can be both unpleasant and threatening to work for, particularly if, like me, you like to make your own decisions.

The Consequences of Autocratic Behavior

While autocratic environments are not pleasant places to work, they can be reasonably efficient when the boss is both competent and fully capable of directing the work. Even in these cases, however, it has long been known that autocratic management styles demotivate the workers and produce less than optimum workplace performance.

One reason for this is explained by James Surowiecki in his book The Wisdom of Crowds [Surowiecki 2004]. He cites many examples of how groups typically make much better decisions than even expert individuals. This is particularly important for development groups and is the reason that autocratic behavior is ineffective and often even counterproductive. This is true regardless of how pleasant and friendly the autocrat is; the problem is unilateral behavior.

An Example

Since it is often hard to recognize that you are working in an autocratic environment, an example may help. In one case, a development team was starting a new project and management told the team leader that the job had to be completed in nine months. The team leader then produced an overall plan with key milestones for

  • design-specification sign-off
  • detailed design complete
  • code complete
  • functional testing
  • system testing
  • customer-acceptance testing

He then met with the entire development team and reviewed his proposed plan. Over the next couple of hours, he answered all of the developers’ questions and made some minor additions and adjustments to the plan. In the end, even though none of the developers felt that the nine-month schedule could be met, the team agreed to the plan pretty much as the team leader had originally proposed it. This team leader then told management that his team now had a plan to deliver the finished product in the desired nine months.

The question is: “Is this autocratic behavior?” Most developers would say no. This is how most of their projects have always been run. They believe that they could have spoken up and made changes to the plan if they had wanted to. Furthermore, most of them also felt that the team leader knew more about planning than they did, and they may even have believed that he or she had produced a better plan than they could have. Finally, since they had to meet management’s nine-month schedule and this plan did, they didn’t have anything better to suggest. The team leader would also likely argue that he or she was not being autocratic. After all, there was a full team review of the plan and all of the team’s suggestions and changes were incorporated.

While it is true that this style is nothing like that of the despot or slave driver of old, it still results in a unilateral plan that was produced with little or no team input. While minor changes were made, the plan had the original resources management allocated, it produced the product that they had specified, and it met management’s suggested end date. Such plans commonly have three important characteristics.

  1. They do not guide the developers in doing the job.
  2. They do not have the full commitment of the team members.
  3. They are rarely met.

The next question, of course is: “If this is autocratic management, how else could you produce a plan?” The answer is to truly involve the team in making its own plan. However, there are typically two objections to doing this.

  1. It would take too long.
  2. The developers wouldn’t know how to make a plan.

Of course, if you don’t mind getting inaccurate and largely useless plans, it doesn’t make much difference how you produce them. However, if you want accurate and useful plans, it might make sense to consider alternatives. I address these points in subsequent columns.

Acknowledgments

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 Dan Burton, David Carrington, Julia Mullaney, Bill Nichols, Bill Peterson, and Alan Willett.

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

References

[Gladwell 1973]
Malcolm Gladwell discusses Zimbardo’s work on pages 152 to 155 of his book The Tipping Point: How Little Things Can Make a Big Difference, Little, Brown and Co., New York, 2000. The original reference is Henry, C.; Banks, W.C.; and Zimbardo, P.G. (1973), “A study of prisoners and guards in a simulated prison.” Naval Research Review, 30, 4-17.

[Surowiecki 2004]
Surowiecki, James. The Wisdom of Crowds: Why the Many Are Smarter than the Few and How Collective Wisdom Shapes Business, Economies, Societies, and Nations, Doubleday, New York, 2004.

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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.