Download PDF version of this article PDF

Mal Managerium: A Field Guide

Phillip Laplante, Penn State University

Please allow me the pleasure of leading you on an “office safari,” so to speak. On today’s journey we’ll travel the corridors of computerdom in search of the widespread but elusive mal managerium, or bad manager, in common parlance. They will be difficult to spot because we will be in a sense looking for that most elusive creature of all: ourselves. That is to say, it’s quite possible that many of us will share some of the qualities with the various types of bad managers we shall encounter. Qualities that we are loath to admit we possess, I might add.

To help you handle this unsettling glance into the mirror, I’ve prepared this field guide to identifying bad managers. I hope that you find it useful in identifying the bad manager in both yourself and your superiors, where applicable. But first, some background.


All bad managers are members of the family managerium. These are top-level predators1 and resource consumers in the organizational food chain. The manager family consists of three distinct genera: good manager (bono managerium), bad manager (mal managerium), and mediocre manager (mediocris managerium).

Bad managers have unlimited range. They are found in Fortune 500 companies, privately owned businesses, government, and nonprofit organizations. They can manage software requirements, development, and testing operations or supervise help desks and call centers. Mal managerium is found in every industry and every application domain and can migrate at will. The software/IT industry seems to be a favorite habitat. Why, no one knows.

In the following guide, you will be presented with the common and scientific names for each species, the best means for its identification (defining characteristics), and the proper way to deal with one when encountered.2 In some cases the species is highly dangerous and the best course of action is to run away.

DATA-DRIVEN MANAGER (mal managerium indicium)

Identification. An insatiable hunger for data (often meaningless) before making a decision. Occasionally this craving for data is rooted in a true need for more information, but more often, this craving is simply a diversionary tactic used to keep enemies or rivals at bay, to keep the data-driven manager’s brood occupied with busy work, or to forestall having to make a meaningful decision.

As an example, consider a situation in which you are asked to conduct a performance analysis for a networked application. After running the tests under simulated and real loads you offer the opinion that “it does not unduly stress the network.” The data-driven manager responds, “This is your opinion, bring me more fact data!” You conduct more tests, and they confirm your conclusion. But it is never enough for the data-driven manager, as each time you bring the desired data, you are asked for more.

Handling. Data-driven managers can cause frustration because every time you think you have satisfied their hunger for information, they want more. Be persistent in dealing with mal managerium indicium. In a sense, just as they are trying to exhaust you, you try to exhaust them with data. Of course, it takes less energy to ask for data than to get it, and if the data-driven manager isn’t really looking at the data, you probably can’t win. But if these managers are honest, then eventually you might satisfy their needs or wear them down in trying.

In the situation just described, for example, you can ask the manager, “Precisely, what data do you need?” If you get a definitive answer, great. If you get an inconclusive answer, then you are probably being stonewalled.

MICROMANAGER (mal managerium minimus)

Identification. Obsessive involvement in details of others; insistence on constant reports of your activities. Endless pestering and carping on their brood.

To illustrate, mal managerium minimus will give the design to a software designer, rather than allowing the designer to actually conduct design activities.

Handling. Direct confrontation may cause mal managerium minimus to temporarily cease the characteristic behaviors.

In the previous example, you must ask the micromanager, “Do you want to do the design, or will you let me do it?” Long term, however, it is unlikely that the micromanager can change. Constant overloading of the mal managerium minimus with data and reports can provide sufficient cover so that real work can be accomplished.

UNCERTAIN MANAGER (mal managerium incertus)

Identification. Inability to make tough decisions, appearance of being overwhelmed, or incompetent. In all cases the behavior causes mal managerium incertus to look weak.

For example, when asked to select between two hardware platforms, mal managerium incertus will waffle, no matter what information is presented.

Handling. Mal managerium incertus must be identified by higher management or self-identified, and taken out. Otherwise, you can try to reconcile the manager by asking probing questions. You can also help by recalibrating and helping to articulate the vision of the organization to provide a compass point for the manager. If all else fails, flee.

In the previous example, you could ask specific questions about the performance characteristics of the two competing platforms to highlight the differences. You could also ask if one hardware platform or the other is implied by corporate strategy, cost, or a strategic alliance.

HEADLESS CHICKEN (mal managerium abrumpo capitas pullus)

Identification. Confused behavior; trying this idea and that; running from one problem to another, without focus. For example, mal managerium abrumpo capitas pullus switches from one architecture or platform to another and back again, seemingly without justification. Those observing the headless chicken performance are themselves confused and demoralized.

Handling. These managers have to be made to realize they are headless. Maybe a close confidante can tell them. Maybe they can be made to realize it on their own. But if the headless chicken managers don’t come to their senses, the organization (that manager, anyway) is doomed, and the only solution is to find a way for upper management to put the chicken out of its misery, or for you to flee.

Perhaps you can document the sequence of the haphazard decisions in the previous example to show how ridiculous it appears.

SPINELESS MANAGER (mal managerium invertabrae)

Identification. A manager who isn’t prepared to face bad news. Instead, mal managerium invertabrae sends an underling to take the rap, or is over-conciliatory—anything to try to keep everyone happy. But the result is usually that no one is happy.

Suppose that your project has been cancelled, requiring the layoff of two of your team members. Mal managerium invertabrae avoids this uncomfortable responsibility and, even though you are “only” the technical lead, tells you to fire them.

Handling. The spineless manager has to be brought to face reality by you, and you must avoid communication through the middleman. But just as spineless managers are fearful to make decisions, they show great ferocity in defending their ability not to make decisions. Therefore, approach mal managerium invertabrae on the subject of spinelessness with great caution.

In the example, you have to remind your boss that you’re a technical lead, and not a manager—and that it’s the manager’s job to deal with personnel issues. Spineless managers might push back, however and get tough with you just to avoid having to do the layoffs.

VACILLATING MANAGER (mal managerium pendulus)

Identification. Wishy-washy managers who can’t make up their own minds. Often appear to be adversarial, when in fact, they are wrestling with themselves. Mal managerium pendulus can be misidentified as mal managerium incertus. The difference is that the former on any given day thinks they have made a decision, but later second guess themselves (dazzling their friends and enemies alike). The latter species simply cannot make any decision at all.

For example, one day mal managerium pendulus resolves to go with software vendor A after a particularly pleasant telephone call. A few days later, vendor A is out in favor of vendor B because mal managerium pendulus has read a glowing report in a trade journal. But a week later mal managerium pendulus flip-flops again after being taken out to lunch by vendor A.

Handling. As with most of the species of this genus, you need to confront these bad managers head on and force them to recognize their vacillations. You can do this by asking questions that lead to the right answers.

So, in the example, you can prepare a features list with the pros and cons of vendors A and B and present it to mal managerium pendulus. Save the “evidence” of the manager’s response to it, so if mal managerium pendulus flip-flops later, you can present this previous analysis and force a justification, and eventually, a decision.


Complicating the proper identification and handling of bad managers is the fact that many hybrids exist. If you encounter a hybrid individual, then you must use the response techniques outlined here corresponding to the characteristic behavior exhibited at the time. You must therefore pay careful attention to the behaviors of bad managers, even if you have handled the situation for the moment. Bad managers are resourceful creatures and they may adopt any bad behavior of sibling species or adapt an existing behavior to survive.

I hope you enjoyed this abridged bad manager watching and handling guide. A complete guide to all species, and including artist renderings, will appear soon.3


  1. The uninformed misidentify mal managerium as parasites.
  2. One classic work that every watcher of bad managers should own is Antipatterns (Brown, W. H., Malveau, R., McCormick III, H. W., and Mowbray, T. J. 1998. New York: John Wiley & Sons). William Brown et al.’s pioneering work was the inspiration for the field guide presented in this article. In another related guide, this author examined the “environmental antipatterns”—negative environments that lead to failure and that tend to be created by indigenous bad managers and/or help to breed bad managers (Laplante, P. A. 2004. The burning bag of dung—and other environmental antipatterns. Queue 2 (7): 78-80).
  3. Laplante, P. A., and Neill, C. J. Forthcoming November 2005. Antipatterns: Identification, Refactoring, and Management. Auerbach Publications.

PHILLIP LAPLANTE is associate professor of software engineering at the Penn State Great Valley School of Graduate Studies. His research interests include realtime and embedded systems, image processing, and software requirements engineering. He has written numerous papers, 20 books, and co-founded the journal Real-Time Imaging. He edits the CRC Press Series on image processing and is on the editorial boards of four journals. Laplante received his B.S. in computer science, M.Eng. in electrical engineering, and Ph.D. in computer science from Stevens Institute of Technology, and an M.B.A. from the University of Colorado. He is a senior member of the IEEE, a member of ACM and the International Society for Optical Engineering (SPIE), and a registered professional engineer in Pennsylvania.


Originally published in Queue vol. 3, no. 4
Comment on this article in the ACM Digital Library

More related articles:

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx in Action
DevEx (developer experience) is garnering increased attention at many software organizations as leaders seek to optimize software delivery amid the backdrop of fiscal tightening and transformational technologies such as AI. Intuitively, there is acceptance among technical leaders that good developer experience enables more effective software delivery and developer happiness. Yet, at many organizations, proposed initiatives and investments to improve DevEx struggle to get buy-in as business stakeholders question the value proposition of improvements.

João Varajão, António Trigo, Miguel Almeida - Low-code Development Productivity
This article aims to provide new insights on the subject by presenting the results of laboratory experiments carried out with code-based, low-code, and extreme low-code technologies to study differences in productivity. Low-code technologies have clearly shown higher levels of productivity, providing strong arguments for low-code to dominate the software development mainstream in the short/medium term. The article reports the procedure and protocols, results, limitations, and opportunities for future research.

Ivar Jacobson, Alistair Cockburn - Use Cases are Essential
While the software industry is a fast-paced and exciting world in which new tools, technologies, and techniques are constantly being developed to serve business and society, it is also forgetful. In its haste for fast-forward motion, it is subject to the whims of fashion and can forget or ignore proven solutions to some of the eternal problems that it faces. Use cases, first introduced in 1986 and popularized later, are one of those proven solutions.

Jorge A. Navas, Ashish Gehani - OCCAM-v2: Combining Static and Dynamic Analysis for Effective and Efficient Whole-program Specialization
OCCAM-v2 leverages scalable pointer analysis, value analysis, and dynamic analysis to create an effective and efficient tool for specializing LLVM bitcode. The extent of the code-size reduction achieved depends on the specific deployment configuration. Each application that is to be specialized is accompanied by a manifest that specifies concrete arguments that are known a priori, as well as a count of residual arguments that will be provided at runtime. The best case for partial evaluation occurs when the arguments are completely concretely specified. OCCAM-v2 uses a pointer analysis to devirtualize calls, allowing it to eliminate the entire body of functions that are not reachable by any direct calls.

© ACM, Inc. All Rights Reserved.