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.”