/writing/ Beware: Proxy Battles

I’VE BEEN ON a recent history streak. One theme that continually intrigues me is the concept of proxy battles. In plain terms, it goes something like this:

-Interest A conflicts with interest B.
-Interest B is friends with interest C.
-Interest A avoids direct confrontation with interest B, and instead, attacks interest C.
-Interest C suffers.
-Interest A and interest B are no closer to a resolution.

It seems in the development industry we have an adapted version of this concept.

Yes, donors / government agencies / clients and implementers presumably share the same interest on paper, but of course, conflicts are unavoidable.

The approach to resolving issues between donors and implementers is a complex matter without a simple answer. But let’s look at it from a practical angle: The proxy battles that play out every day through our most basic administrative documents like progress reports, workplans, implementation / action plans, and M&E materials.

Important administrative documents reflect the outcome of discussions, analysis, and decision making between the client and implementer, as it relates to nearly every aspect of the program. By extension, they reflect outcomes (hopefully positive) of both technical and administrative conflicts or tensions between the implementer and client. They are living documents which help us formalize a problem-solving process.

Rigorous critique of these documents is healthy and natural, and above all, necessary. Afterall, they formalize the strategy, process, and details to complete a defined scope of work, which must be carefully vetted through a technical and administrative perspective that ensures its content balances strategic, technical, and political interests. In plain terms, clients are paying us, and so we must respond.

But there is a point in which not enough substantive dialogue and decision making has taken place on the front-end, and so, the writing / review & feedback / re-writing process – ground zero for the proxy battle – fails both sides; there is no longer a solution to be found in our administrative documents.

Let’s say there is a pending dispute between the implementer and the donor about the methodology of a capacity building module. You, the implementer is pushing for methodology ABC, while the donor expects XYZ.

So, as the author of the workplan – which your boss tells you will outline methodology ABC, knowing the client is expecting methodology XYZ – how confident are you in the quality of the product knowing this issues hasn’t been resolved? Or imagine your excitement when you are the one who gets to re-write the entire capacity building module section to reflect methodology XYZ because the client finally flexes and enforces its approach.

Aside from the personal aggravation of the team writing and re-writing these documents, this approach ultimately undermines the quality the document (interest C suffers) and overall strength of the implementer (interest B). Few would argue that a document reflecting conflicting narratives, methodologies, or timelines is at all effective or would serve both interests in any meaningful way. Development work is messy enough when the donor and implementer are aligned in policy and practice; it’s downright impossible when neither are.

Regarding client feedback, be mindful of a seemingly innocuous trick that can potentially have significant consequences. My team recently responded to feedback on an annual report. A very minor issue, rephrasing an achievement statement (which was valid feedback), warranted an illogical and exaggerated conclusion that the entire structure of the report needed reworking. Another example: Briefly referencing one part of the project and its integration into a larger reporting section, left our team questioning how to respond to an accusation that we were double reporting the achievement. (We rejected both comments and called the client on making illogical and exaggerated conclusions. No changes were made.)

The danger here is that clients can slowly build a case against your program – based on false or misleading premises – that your reporting doesn’t reflect the scope, is poorly organized, is trying to hide important information, or some other damaging narrative. Over time, the perception of ineffective reporting becomes a reality that can be used as leverage against you, your team, or the program (i.e., during negotiations, extensions, or even to close the program early).

The solution?

Push back on your senior management team to make sure they are doing their job; that they are resolving matters with the client actively and conclusively. They get paid the big money to resolve and communicate the big-picture issues before administrative documents are developed. Be vocal about how a lack of clarity in their work impacts the process down the chain. Pre-writing meetings on important document can be a tremendous help in resolving pending issues and understanding client priorities. As well, meeting with clients after they have provided feedback, but before re-writes begin, to help contextualize written feedback (which can often be taken more negative or unclear in comparison to verbal explanations). Show your willingness to improve your work, but hold a tight line related to the little tricks that can slowly be used to undermine you, your work, and the program.

Ultimately, don’t let your reporting and other documents be used against the program. They are objective platforms which should reflect a balance of client and implementer interests, not mechanisms to wage proxy battles.

Thanks for reading.