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.

This article in its entirety was written by a human being. No machine intelligence was involved in any way.

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:

Bemused Detachment

Much of the difficulty between people at work is avoidable if only we can find ways to slow down our responses to each other. When we hurry, we react without thinking. Here's a suggestion for increasing comity by slowing down.

Masked Messages

Sometimes what we say to each other isn't what we really mean. We mask the messages, or we form them into what are usually positive structures, to make them appear to be something less malicious than they are. Here are some examples of masked messages.

Devious Political Tactics: More from the Field Manual

Careful observation of workplace politics reveals an assortment of devious tactics that the ruthless use to gain advantage. Here are some of their techniques, with suggestions for effective responses.

Meta-Debate at Work

Workplace discussions sometimes take the form of informal debate, in which parties who initially have different perspectives try to arrive at a shared perspective. Meta-debate is one way things can go wrong.

Compulsive Talkers at Work: Peers II

Our exploration of approaches for dealing with compulsive talkers now concludes, with Part II of a set of suggestions for what to do when peers who talk compulsively interfere with your work.

See also Conflict Management and Conflict Management for more related articles.

Forthcoming issues of Point Lookout

Coming December 11: White Water Rafting as a Metaphor for Group Development

Tuckman's model of small group development, best known as "Forming-Storming-Norming-Performing," applies better to development of some groups than to others. We can use a metaphor to explore how the model applies to Storming in task-oriented work groups. Available here and by RSS on December 11.

And on December 18: Subgrouping and Conway's Law

When task-oriented work groups address complex tasks, they might form subgroups to address subtasks. The structure of the subgroups and the order in which they form depend on the structure of the group's task and the sequencing of the subtasks. Available here and by RSS on December 18.

Coaching services

I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.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