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.
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.
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.
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.
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.
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.
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
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—
see this item in the ACM Digital Library
Ivar Jacobson, Ian Spence, Ed Seidewitz - Industrial Scale Agile - from Craft to Engineering
Essence is instrumental in moving software development toward a true engineering discipline.
Andre Medeiros - Dynamics of Change: Why Reactivity Matters
Tame the dynamics of change by centralizing each concern in its own module.
Brendan Gregg - The Flame Graph
This visualization of software execution is a new necessity for performance profiling and debugging.
Ivar Jacobson, Ian Spence, Brian Kerr - Use-Case 2.0
The Hub of Software Development