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:

Stonewalling: I

Stonewalling is a tactic of obstruction used by those who wish to stall the forward progress of some effort. Whether the effort is a rival project, an investigation, or just the work of a colleague, the stonewaller hopes to gain advantage. What can you do about stonewalling?

Tangled Thread Troubles

Even when we use a facilitator to manage a discussion, managing a queue for contributors can sometimes lead to problems. Here's a little catalog of those difficulties.

The Myth of Difficult People

Many books and Web sites offer advice for dealing with difficult people. There are indeed some difficult people, but are they as numerous as these books and Web sites would have us believe? I think not.

Compulsive Talkers at Work: Power

Compulsive talkers are unlikely to change their behavior in response to your polite (or even impolite) requests. In this second part of our exploration, we consider the role of power — both personal and organizational.

They Just Don't Understand

When we cannot resolve an issue in open debate, we sometimes try to explain the obstinacy of others. The explanations we favor can tell us more about ourselves than they do about others.

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

Forthcoming issues of Point Lookout

Coming January 19: Comply, Resist, or Exploit?

When we encounter obstacles, we have choices about how we deal with them. Generally, we can comply, we can resist, or sometimes, we can find ways to use the obstacles — to exploit them — to advance to our objectives. The pandemic provides two examples. Available here and by RSS on January 19.

And on January 26: Cyber Rumors in Organizations

Rumor management practices in organizations haven't kept up with rumor propagation technology. Rumors that propagate by digital means — cyber rumors — have longer lifetimes, spread faster, are more credible, and are better able to reinforce each other. Available here and by RSS on January 26.

Coaching services

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

Public seminars

The Power Affect: How We Express Our Personal Power

Many people who possess real organizational power have a characteristic demeanor. It's the way they project their presence. I call this the power affect. Some people — call them power pretenders — adopt the power affect well before they attain significant organizational power. Unfortunately for their colleagues, and for their organizations, power pretenders can attain organizational power out of proportion to their merit or abilities. Understanding the power affect is therefore important for anyone who aims to attain power, or anyone who works with power pretenders. Read more about this program.

• A recording of a program presented June 29, 2017, Monthly Webinar, sponsored by Technobility Webinar Series. PMI members can earn 1.0 Category 'A' PDU by viewing this program. View this program now.
   
• A recording of a program presented June 29, 2017, Monthly Webinar, sponsored by Technobility Webinar Series. PMI members can earn 1.0 Category 'A' PDU by viewing this program. View this program now.
   

Bullet Points: Mastery or Madness?

Decision makers in modern organizations commonly demand briefings in the form of bullet points or a series of series of bullet points. But this form of presentation has limited value for complex decisions. We need something more. We actually need to think. Briefers who combine the bullet-point format with a variety of persuasion techniques can mislead decision makers, guiding them into making poor decisions. Read more about this program.

• A recording of a program presented June 24, 2020, Monthly Webinar, sponsored by Technobility Webinar Series. PMI members can earn 1.0 Category 'A' PDU by viewing this program. View this program now.
   
• A recording of a program presented June 24, 2020, Monthly Webinar, sponsored by Technobility Webinar Series. PMI members can earn 1.0 Category 'A' PDU by viewing this program. View this program now.