Covert Inter-Team Noncooperation

From time to time one team (call it Team Reluctant) might be required to cooperate with another team (call it Team Requestor) to produce something that Team Requestor needs, but which Team Reluctant doesn't want to produce, or which Team Reluctant regards as a waste of time or as conflicting with other priorities. And in some of these situations Team Reluctant is required not merely to cooperate, but to cooperate enthusiastically, or, at least, to not get caught cooperating unenthusiastically. From the perspective of Team Reluctant, such situations call for what might be termed covert inter-team noncooperation.

The most important indicators of covert inter-team noncooperation are two. First, the actions of Team Reluctant do appear to be cooperative. That is, Team Reluctant fulfills its obligations in a technical sense. Second, Team Requestor doesn't receive what it actually needs. Even though Team Reluctant has executed actions that technically satisfy Team Requestor's needs to a reasonable degree, Team Requestor can make very little progress because what it has received from Team Reluctant is pseudo-cooperation. What Team Reluctant delivers to Team Requestor isn't useful in any practical sense.

What follows is a little catalog of tactics Team Reluctant can use to execute a strategy of covert inter-team noncooperation. Team Requestor can use this catalog as a guide for what to watch for. That knowledge can help Team Requestor manage the risk of Team Reluctant using such a strategy. For example, if Team Requestor frames its requests carefully enough and specifically enough, it can make pseudo-cooperation difficult.

For concreteness, I've written the catalog as if it applied to a context in which Team Requestor needs a package of information, including some data files that Team Reluctant created to make projections of the behavior of a system under study. But the tactics described in this catalog apply to many situations in which one team needs something from another.

Delay

Team Reluctant can dawdle in responding to Team Requestor's requests. Dawdling is an appealing tactic for Team Reluctant because it limits the total requests per unit time that Team Requestor can produce.

What Team In some situations teams are required not
merely to cooperate, but to cooperate
enthusiastically, or, at least, not get
caught cooperating unenthusiasticallyRequestor wants should be readily available, because Team Reluctant should have "frozen" a copy of everything they used to produce their projections. For this reason, delays would be minimal if Team Reluctant were actually cooperating.

Configuration issues

The term "configuration management" denotes the practice of making certain that the different versions of the various components of a complex system are compatible. In this case, if Team Reluctant is actually cooperating, they will want to be certain to deliver to Team Requestor versions of files that are meant to work properly together. Things can go wrong when multiple "runs" of the system are executed with incompatible versions of some files. When configuration management is practiced effectively, we don't use incompatible versions of files to execute a run of the system.

An uncooperative Team Reluctant might deliver to Team Requestor a set of data files that are not meant to operate together. That is, although the files appear superficially to be a complete and compatible set, they include one or more files that are incompatible with the rest. If the incompatibility is discovered, a member of Team Reluctant might apologize and explain, "Sorry, in trying to respond to your request so quickly we got the wrong file in there. Here's the right one." The incident looks like an honest mistake.

Missing files

In response to Team Requestor's request for data files, Team Reluctant might deliver a package of data files, but that package might be incomplete. This too, can look like an honest mistake, even if it is not.

Incompleteness can be especially difficult to detect if the ability to recognize that some elements are missing depends on performing a significant piece of work. For example, if Team Requestor is attempting to replicate Team Reluctant's work, as they might if conducting an audit, Team Reluctant can omit an element that isn't actually required until late in the effort. In the interim, the system can produce results that are incorrect but mysteriously so. In some cases, Team Requestor might be able to determine that something is missing only by "debugging" the system.

Irrelevant files

The package delivered to Team Requestor might be a complete set of files, and they might be compatible with each other, but they might represent a run of the system that isn't the run Team Requestor wanted to receive. Another "honest" error.

Missing, incompatible, or incomplete documentation

Most data sets require accompanying documentation, explaining what file contains what data. Think of this documentation as engineer's notes. It tells anyone who wants to replicate the work exactly what to do, and where necessary information and data can be found. And the documentation must be compatible with the files.

Detecting missing documentation is relatively easy, because it isn't there. But detecting incomplete documentation can be difficult, because what you're looking for is what's missing from a possibly impressive looking assemblage of useful documentation. People don't usually notice missing elements until someone needs them. Likewise, incompatible document elements usually look like they fit in. Only when we actually need them do we recognize that they aren't compatible. These tactics often escape Team Requestor's notice until they have caused serious problems.

Finally, there is at least one most delicate tactic. When both teams are elements of the same organization, some members of Team Requestor might actually be loyal to the mission of Team Reluctant — covertly, of course. They can introduce delays and confusion into Team Requestor's activities at any point, if they're carful enough and knowledgeable enough.  Top    Next Issue

Are you fed up with tense, explosive meetings? Are you or a colleague the target of a bully? Destructive conflict can ruin organizations. But if we believe that all conflict is destructive, and that we can somehow eliminate conflict, or that conflict is an enemy of productivity, then we're in conflict with Conflict itself. Read 101 Tips for Managing Conflict to learn how to make peace with conflict and make it an organizational asset. Order Now!

Your comments are welcome

About Point Lookout

Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.

Point Lookout is a free weekly email newsletter. Browse the archive of past issues. Subscribe for free.

Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.

Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.

Related articles

More articles on Conflict Management:

Conflict Haiku

When tempers flare, or tension fills the air, many of us contribute to the stew, often without realizing that we do. Here are some haiku that describe some of the many stances we choose that can lead groups into tangles, or let those tangles persist once they form.

In the Groove

Under stress, we sometimes make choices that we later regret. And we wonder, "Will I ever learn?" Fortunately, the problem usually isn't a failure to learn. Changing just takes practice.

The Power of Situational Momentum

For many of us, the typical workday presents a series of opportunities to take action. We often approach these situations by choosing among the expected choices. But usually there are choices that exploit situational momentum, and they can be powerful choices indeed.

What Insubordinate Nonsubordinates Want: III

When you're responsible for an organizational function, and someone not reporting to you doesn't comply with policies you rightfully established, trouble looms. What role do supervisors play?

How Workplace Bullies Use OODA: I

Workplace bullies who succeed in carrying on their activities over a long period of time rely on more than mere intimidation to escape prosecution. They proactively shape their environments to make them safe for bullying. The OODA model gives us insights into how they accomplish this.

See also Conflict Management and Devious Political Tactics for more related articles.

Forthcoming issues of Point Lookout

Coming March 29: Time Slot Recycling: The Risks

When we can't begin a meeting because some people haven't arrived, we sometimes cancel the meeting and hold a different one, with the people who are in attendance. It might seem like a good way to avoid wasting time, but there are risks. Available here and by RSS on March 29.

And on April 5: The Fallacy of Division

Errors of reasoning are pervasive in everyday thought in most organizations. One of the more common errors is called the Fallacy of Division, in which we assume that attributes of a class apply to all members of that class. It leads to ridiculous results. Available here and by RSS on April 5.

Coaching services

I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenZLkFdSHmlHvCaSsuner@ChacbnsTPttsdDaRAswloCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.

Get the ebook!

Past issues of Point Lookout are available in six ebooks:

• Get 2001-2 in Geese Don't Land on Twigs (PDF, )
• Get 2003-4 in Why Dogs Wag (PDF, )
• Get 2005-6 in Loopy Things We Do (PDF, )
• Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
• Get 2009-10 in The Questions Not Asked (PDF, )
• Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info