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:

So You Want the Bullying to End: I

If you're the target of a workplace bully, you probably want the bullying to end. If you've ever been the target of a workplace bully, you probably remember wanting it to end. But how it ends can be more important than whether or when it ends.

Contextual Causes of Conflict: I

When destructive conflict erupts, we usually hold responsible only the people directly involved. But the choices of others, and general circumstances, can be the real causes of destructive conflict.

Strategic Waiting

Time can be a tool. Letting time pass can be a strategy for resolving problems or getting out of tight places. Waiting is an often-overlooked strategic option.

Risk Acceptance: Naïve Realism

When we suddenly notice a "project-killer" risk that hasn't yet materialized, we sometimes accept the risk even though we know how seriously it threatens the effort. A psychological phenomenon known as naïve realism plays a role in this behavior.

Rescheduling: The Paradox of Politics

When the current project schedule no longer leads to acceptable results, we must reschedule. Sometimes political factors compel us to not only delay our results, but also to produce those results in ways that accommodate organizational politics.

See also Conflict Management for more related articles.

Forthcoming issues of Point Lookout

Coming July 16: Responding to Unwelcome Events

Unwelcome events have two kinds of effects on decision-makers. One set of effects appears as we respond to events that have actually occurred. Another set manifests itself as we prepare for unwelcome events that haven't yet occurred, but which might occur. Making a wrong decision in either case can be costly. Available here and by RSS on July 16.

And on July 23: Microdelegation

Microdelegation is a style of delegation in which the delegator unintentionally communicates the task to the subordinate in such detail and so repetitively that the subordinate is offended. As a result of this delegation style, many subordinates feel distrusted or suspected of fraud or goldbricking. Available here and by RSS on July 23.

Coaching services

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