When to write in DevSpeak; when to use Plain Language? More handy tips.

Andrew Johnston of Words for Change felt moved to respond to Friday’s post on the use of plain language in development comms. He argues that writers have to be able to write for multiple audiences simultaneously, which reminds me of Disney films’ amazing ability to combine a simple narrative to entertain the kids with enough irony and knowing references to keep the adults amused.

Kate Murphy’s post Just to be clear: why Devspeak needs to adopt Plain Language rang many bells for me. Over the past five years I’ve given 115 writing workshops for NGOs, charities, UN agencies and other non-profit groups, mostly in the development sector in Europe and Africa.

When I’m not giving workshops, I’m editing for the same kinds of agencies, so I’ve seen close-up the kind of mayhem Devspeak can cause. Duncan’s earlier post Which awful Devspeak words would you most like to ban? brought back the horrors of my migration to Devspeak-land 10 years ago after 25 years in journalism.

I agree wholeheartedly with Kate’s diagnosis of the malaise and her recommended treatment. Much of what I teach in my workshops is based on plain language principles.

But I worry that in Kate’s and Duncan’s posts there is an either/or attitude to Devspeak – Devspeak bad, plain language good – that doesn’t match the reality many writers face.

Yes, Devspeak on its own is dire. But sometimes people have to use Devspeak words because certain readers are expecting to see them (or because they mean specific things for which there are no other words).

The answer is that you can use both Devspeak and plain language – and you often should.

First time round, use the development term that will push the right buttons – for donors, experts, wonks, officials – and explain it in simpler language. After that, you can go on using either the Devspeak term or the paraphrase, depending on how your audience is made up.

That question of audience is crucial. I ask my workshop participants to consider which of their audiences – and how many people in each audience – understand their agency’s jargon. Few audiences, it turns out, are made up solely of specialist or non-specialists. In other words, we almost always need to write for both.

The readers with the most power to bring about change – policy-makers, decision-makers, donors, community leaders, even the media – are often non-specialists. So failing to explain your Devspeak to them can literally get you nowhere.

What consequences do you risk in the other direction – in spelling out for experts what they already know? Perhaps they’ll be bored, irritated or frustrated. But those are minor problems compared with the consequences of not tapping into the power of the change-makers.

Nevertheless, many Devspeak users are reluctant to spell out the meaning of the terms they use. Kate calls this “an inexplicable resistance to plain language writing”. When I ask my workshop participants why they use jargon, though, they also tell me why they steer clear of plain language, and the answers are revealing.

Writers fear that they won’t be taken seriously. They worry that they won’t seem expert, professional, qualified or sufficiently educated. They are apprehensive that won’t be regarded as part of the in-crowd.

Where do these fears come from? Many development experts (especially those in think tanks) write as if their audience is made up solely of academics or their peers, and they are concerned above all else to preserve a brittle, narrowly perceived scientific credibility. The irony is that the best academic writing has moved on from the dense, stodgy manner that some Devspeak writers use, as Helen Sword describes in her terrific book Stylish Academic Writing.

In general, there is a failure to imagine the audience. That leaves most Devspeakers writing principally for one another.

I think the sector needs not only to adopt plain language principles, as Kate says, but to recommit to writing for the least specialist reader as well as the specialist reader. And that means talking both languages, Devspeak and plain language, when necessary. It can be complicated (you could write a book about it, and I am). But it’s a crucial step towards, yes, making change happen.

Spelling out what you mean takes more work, of course (as well as more words), but you need to do it so that the reader doesn’t have to do it. Where do you leave a reader who is baffled by a term you haven’t explained? They’ll probably Google it, and then you’re in deep trouble.

There are huge benefits to explaining Devspeak terms, in fact. You get to show what you and your organisation mean by a particular term, which is vital in the development sector where many terms are vague and/or used to mean different things by different people. (Try “educational attainment” on the next education wonk you meet. And then on the one after that.)

The first time I gave a workshop at the Overseas Development Institute, I asked the participants to write down definitions of some terms commonly used in international organisations. When we compared the results, uproar ensued. Civil society? Capacity building? Stakeholder? All were interpreted in vastly different ways by people who nevertheless worked for the same organization.

(Conclusion: Name the main groups you include in “civil society” and “stakeholders”. Say what “capacity building” entails in the context and say whose capacity to do what.)

A last thought about that resistance to plain language. In some development organisations, particularly in the UK, I’ve found that a deep distrust between research and communications teams seems to feed researchers’ reluctance to explain their terms (Devspeak is what I do, plain language is what you do). Breaking down that mistrust is crucial for many reasons, including the need for both sides to speak both languages so that we can reach both audiences, specialist and non-specialist.

The best comment I’ve heard on these questions came from Alexandros Lordos, research director of the Centre for Sustainable Peace and Democratic Development, in Cyprus. He came up to me after I’d given a workshop for his team in Nicosia in June. “I understand what you mean,” he said. “You mean that each of us needs to be our own communications officer.”

Subscribe to our Newsletter

You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please see our Privacy Policy.

We use MailChimp as our marketing platform. By subscribing, you acknowledge that your information will be transferred to MailChimp for processing. Learn more about MailChimp's privacy practices here.

Comments

4 Responses to “When to write in DevSpeak; when to use Plain Language? More handy tips.”
  1. Thanks, Andrew. I would like to touch on the issue of writing/producing too much and how this effects ‘bad writing’. Like academia, the development sector produces far to much written output. Imagine an organization of your choice had 50% of their archive deleted-would you notice this, let alone miss the annual report from 2015?
    Most academic journal articles are inaccessible and one major reason is that authors needed to fit them into the straitjacket of journal guidelines. Same in large organizations where every story needs to be turned into a templated ‘product’ that make them look ‘professional’ and often takes away any ‘plainness’. I’m quite convinced if organizations were to adopt a policy of writing less and use more creativity over the final product writing would improve.
    However, I am also realistic and agree to some extent with Andrew’s observation that some kind of professional language is necessary in every sector. I am highly doubtful that “policy-makers, decision-makers, donors, community leaders, even the media” always use plain language-they use different jargon, because they are also under pressure to produce writing or similar output.
    As much as I appreciate Andrew’s efforts I firmly believe that the sector needs to produce less writing-is there any reason why anybody needs a documents that extents 20 or so pages ?!?

    • Thanks! And….just in response to your concluding question, reasons include:
      a) Requirement by donor or executing entity
      b) Perception that more pages demonstrate more insight, leading to more (perceived) plausible conclusions
      c) Lack of or no clarity on what the components of a particular section/chapter etc. should actually include
      d) Confusion as to what could/should be included as an appendix to support the more succint main narrative

  2. Silva Ferretti

    Sometimes dev-speak is not “a failure to imagine the audience”. But a failure to imagine practice. By the time information about a programme reaches the “dev-speak interpreters” (for example, project / report writers and the like) a lot of substance is lost. I met communication and reporting manager (in-country expats) who, since their arrivals 6 months before, had never visited once the villages they were writing about. They did not even know how they looked like. How can you report on something you have never seen once? And, as an evaluator, I often spend ages asking questions like “what do you mean with capacity building? Can you give me an example?” or “when you say community, who do you mean, within a community?”. These questions are obviously never asked, as they leave people really puzzled. Project implementers are then able to answer. With lots of interesting stuff, which was hidden by jargon. The next echelon up… often has no clue.

    We spend ages in reporting about project in ways that are meaningless. Sentences like “we empowered vulnerable people in the community, so that they could improve their resilience” means everything and nothing. And, more often than not, after reading a project report I have to ask people: can you please explain me what you are actually doing? Which is often much more interesting than jargon. The aid industry really need to reflect on how much meaning is lost in jargon. And how much of the jargon is a way to hide a substantial ignorance about how development happens.

    I would also add – on top of dev-jargon – the challenge of over reliance on the written word and the report format. I am trying to use, more and more, videos and visuals to show what reality looks like in the words of the people experiencing it. I had to fight with interpreters who were making people speaking jargon in the subtitles… but, once this battle was won, I found it incredible refreshing to hear, in plain language, what change looked like for the people who experienced it.

  3. One additional consideration, at least in my work in several major conflict areas or in countries with autocratic rule, is–simplicity and jargon aside–ensuring palatability by the government of the day. One may not wish to avoid uncomfortable issues and findings; however, if one does realise the probablity of being kicked out of a place after using insensitive, inappropriate, sometimes even threatening language, and one wishes to remain in the country, then one must be willing and able to include but wordsmith issues in ways that are acceptable to the rulers.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.