My Manager Thinks I'm Holding Her Hostage

[article]

Linda Hayes wrote an excellent article called "Held Hostage by Coders." In it, she describes three unhealthy behavior types (and how to deal with them) in programmers:

  • The hijacker is a developer who takes control of strategic product decisions without permission or authority, holding the company and its customers hostage to his decisions through delays and diversion. Even though the hijacker's intentions might actually be good, the results are bad.
  • The prima donna is a developer who enjoys writing new code but doesn't want to support and maintain it.
  • The control freak is a coder who hoards the code.

I've seen the behavior that Linda describes firsthand, but I have also seen problematic behavior displayed by managers. While some programmers may be inexperienced, immature, or difficult to get along with, they also may be hard-working people who have learned to react subversively to cope in an environment where management intimidates them (either consciously or accidentally). Here are some management behavioral anti-patterns that can aggravate or cause hijacking reactions:

The Underminer
Underminers are leaders who won't take your answer as valid if it doesn't have the result they're looking for. Sometimes they will just go around the office asking the same question until they find someone who will give them the answer they want. In other cases, this behavior is displayed by a manager who is playing politics and trying to deflect blame onto someone else or to make a subordinate look bad.

Symptoms

  • Focuses on short-term gains over long-term product strategy.
  • Doesn't understand how much work is required, if all
  • Lacks trust in programmers' estimates.
  • Finds the shortest estimate, picking that and making the other people feel disrespected.

Corresponding Programmer Behavior

  • Prima Donnas tend to placate underminers by promising quick and dirty solutions, as prima donnas often undermine their teammates.
  • Hijackers take their maintenance work or other work underground, believing it won't get approved anyway.
  • Control freak behavior is reinforced by paranoia after being undermined.

Solution Ideas

  • Create a management process to handle project management tasks, and don't let one person subvert it without the approval of others.
  • Set up a point person who can run interference.
  • Add visibility to all the actual work involved to rewrite hacks, put in more maintenance, and advise on the tradeoffs between doing it quickly and paying off resulting technical debt later.

The Erratic Driver
This type of manager is referred to as an "unpredictable change agent," or less favorably as "management by whimsy."

The erratic driver is a leader who changes direction on schedules and projects frequently, which disrupts everyone else's work. This leader may feel that he is losing control to the technical staff, inexperience, or merely disorganized thinking. It is frequently displayed by "big picture," visionary entrepreneurs who think of a lot of ideas very quickly and expect the rest of the team to be able to keep up. Sometimes this type of leader subverts process, project management, and other managers to interrupt and direct individuals to change work tasks and projects directly, sometimes by stealth.

Symptoms

  • Frequent schedule changes (usually attempts to ship something earlier)
  • Change in product direction (we are building this now instead)
  • An "I need this new feature NOW!" mindset

Corresponding Programmer Behavior

  • Prima Donnas tend to work with erratic drivers, who provide escapes from maintenance with something new.
  • Control freaks try to regain some control during erratic change by becoming even more controlling and less flexible.
  • Hijackers avoid changing work and may continue to work on an existing project and refuse to work on new projects. They may secretly work on maintenance tasks and other activities under the budget of a new project or feature.

Solution Ideas

  • Create a management process that manages communication-a united management front instead of a constant change.
  • Set up an escalation process to fleece out the fickle requirements (whimsical ideas) vs. the real requirements (what visionaries really want).
  • Create a safe place for visionaries to try out ideas that isn't disruptive to the team. Schedule time and have people work with the visionary on an ongoing basis. If needed, create a team for new project development to explore these ideas while existing work is still being completed.

Micromanager
This leadership behavior is the complement to the control-freak programmer. The micromanager is a manager who can't let go and doesn't trust his staff to do the work right. This manager wants to know what you are working on every hour of the day and will second-guess decisions you make about your work. Micromanagers often are obsessed with time-tracking systems, planning, and interrupting employees to find out what they are working on. This manager fosters a culture of heroes ("This employee is great; he is doing what I told him to do.") vs. scapegoats ("Why did you solve the problem that way? Do you want to ruin the release?").

Symptoms

  • Manager comes to work early, stays late, and doesn't like to take holidays-or, if on holidays, constantly checks in.
  • Poor employee morale results from feeling like "big brother" is watching.
  • Management demands excessive time-tracking and process administration.
  • Employees spend a lot of time entering and justifying time spent on tasks.
  • Manager second-guesses employee time spent on tasks.
  • There are frequent communication breakdowns.

Corresponding Programmer Behavior

  • Prima donnas bypass micromanagers and subvert or undermine them.
  • Hijackers inflate numbers to work on other projects (or look for another job).
  • Control freaks team up with micromanagers and blame the others.

Solution Ideas

  • Raise visibility on management tasks and behavior and keep managers accountable by the same rules as the technical staff.
  • Use collaborative project management tools, such as group estimates and pairing when working, to deflect scrutiny on individuals.
  • Group task assessments. "We succeed as a team; we fail as a team."
  • Make sure managers are measured on qualitative measures such as customer satisfaction, employee happiness, and their contribution to building valuable products. If they are measured by quantitative numbers alone, they will focus on those numbers to the detriment of the product.

Conclusion
I once worked with a software development team that had developed a blame culture. I witnessed all the behaviors described in Linda's article and the corresponding management behaviors described here. To confront it, I called a team meeting and discussed the programmers' hijacking behavior. The managers all nodded their heads vigorously. I then described the management behaviors, as described in this article, and the programmers and other technical staff nodded their heads as well. I then facilitated a group discussion about the behaviors, and the group discussed ways to counteract them. I asked the team members to be accountable for their own behavior and to point out that behavior in others when it was affecting them. The labels discussed in the meeting were helpful to use as a non-threatening means of letting someone know when they were displaying unwanted behavior.

While these behaviors are different and can manifest in various people, they are shared behaviors and easy to slip into. In fact, many of us have personality traits that lend themselves to these behaviors. In many cases, we just ignore the behavior and don't confront it directly. We may resort to some of these behaviors to try to change behavior in others, but it doesn't work. In fact, it usually backfires. For example, a manager may feel that he is being held hostage by prima donna programmer behavior and resort to micromanaging. Instead of gaining control, the manager may find the prima donna just bypasses and undermines him. In other cases, this behavior is less deliberate.

Ignoring poor behavior is a type of enabling-the more we let the behavior go without confronting it directly, the more we allow it to continue. It feels easier either to ignore the problem behavior or to try to deal with it indirectly.

It can be intimidating to confront this kind of behavior, but try the following:

  • Talk to your manager directly.
  • Ask HR for advice.
  • Talk to your manager and HR together.
  • Have a facilitator help your group.

Do not:

  • Talk to other employees about your manager's behavior.
  • Subvert or undermine your manager.
  • Engage in the same kind of behavior to try to change their behavior.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.