Podcast: The divide between academics and practitioners -- Interview with Lisa Meloncon
Here’s the audio for the podcast:
One common response I usually get with podcasts is that people want a transcript of the audio. Although I don’t have time to make a verbatim transcript, I decided to write out a brief summary of notes and highlights (based on what jumped out at me during my own listening) in a more informal way this time. Here’s the description:
Tell me a little bit about yourself.
Lisa Meloncon started out writing technical documentation for missile guidance systems for the U.S. Army. When she left the army, she stayed in tech comm and started her own company in 1994. As a consultant, she solved communication problems at many different types of organizations. Later, she returned to school for a PhD and, after completing her program, pursued an academic job. As a professor, she does research, teaching, and service. She loves teaching and brings her research into the classroom in energizing ways.
Why did you decide to get into the academia and do research?
There were some things that were driving her crazy in the field, one of them involving questions of document design. One client wanted reports with bullets only, and no independent sentences. She couldn’t convince him, and she felt that an academic program and research would give her information to persuade clients like this and many others about best practices with tech comm.
How do you get academic research out to practitioners?
It’s extremely hard. The paywall is an enormous barrier. But this is simply how publishing is done in higher education. It really falls on the academic to try to get the research out there in another way.
However, publishing outside of academic journals doesn’t have any rewards for the academic, except for falling into a general service category. As a result, academics just don’t have the time, energy, or money to rework and publish the content in other formats.
Do journals retain publishing rights over the articles academics write?
It depends. Sometimes journals allow academics to publish the articles for educational reasons. Or if the journal makes a special exception (maybe you’ve won an award), you can sometimes republish. But by and large, journals control access to the content in ways that make it difficult for practitioners to access.
Even with journals that are accessible (like the Technical Communication journal), practitioners often don’t read the articles that they actually have access to. Why?
If practitioners don’t read the journal because they find the content irrelevant, remember that these journals can only publish the content they receive. This content has to go through peer review by an academic and practitioner. The reviews may be at odds with each other, which complicates the editor’s job.
About 19-25% of submitted articles get accepted. Although the articles in the Technical Communication journal follow a traditional academic style, the Technical Communication journal actually does publish practitioner takeaways that summarize relevant points for the practitioner. The Technical Communication journal is one of the few journals to do this.
As for the academic writing style, this style is entrenched in the discipline of academic publishing. When Lisa first got into academic publishing, she had to change her style dramatically. It was painfully difficult for her, but she would have never published anything had she not taken a more academic tone and approach.
Although practitioners are turned off by the academic writing style, in order for academics to excel in their field, they have to publish this way — in academic journals with content written in a thick academic style. There isn’t much incentive for the academics to publish outside of academic journals in online sites with a more popular style. There is some reward giving to service when you publish, but it’s not significant in comparison to the academic publishing.
Larry Kunz recently published a blog post titled What should a Technical Communication course teach?. Though Larry doesn’t mention it, he covers a similar topic as Miles Kimball’s article, Training and Education: Technical Communication Managers Speak Out, in the latest issue of Technical Communication journal. Miles’ conclusion is that managers want people skilled in the fundamentals of technical communication rather than specific tool knowledge. Hence tech comm programs should focus on writing and editing, not so much tool knowledge. Do you agree?
Well, the research in the article was based on a small number of managers and isn’t so general. But many job ads do list tools as requirements. So tools are important, but the problem is that the tool taught in a program may not be the tool required by the job market. The tools used by different companies are really diverse. A lot of times when teachers teach a tool, the students get caught up in this tool and then become hesitant to learn or embrace another tool.
This tools question is a really constant scenario that people run into. These technologies aren’t cheap. So many of these jobs seem to require knowledge of Adobe products. When Adobe moved to their cloud subscription model, this increased the cost of the tools five-fold.
Students often come in and say, I see all of these tech writer job ads requiring tools … so where’s the Framemaker course? Teachers constantly have to explain why there isn’t one.
Programs have a difficult time making the subscription model work for students. Students may have to buy 3-4 different subscriptions for different tools, which adds up to a lot more than a book. Consequently, programs look for open source alternatives that approximate a similar experience.
A lot of practitioners form communities around tools. Is the lack of focus on tools one reason why practitioners don’t find academic journals relevant?
Possibly, but access is also a huge issue. And sometimes it’s hard for practitioners to see how an academic journal is relevant to their jobs. It requires more time to really sift through the content.
Was the most recent Technical Communication journal, whose focus was on “How a few great companies get it done,” specifically trying to be more relevant to practitioners?
Not necessarily. The issue looks at what’s going in these great companies. It shows the types of research that can be done, but it wasn’t conceived as an attempt to bridge the academic-practitioner divide.
The research for this issue took 2.5 years. Good research takes a lot of time.
Why does it take so long to complete the research?
Access to the information is one problem. It also takes a while to come up with the best way to answer a question. Research has to be rigorous or it’s not going to be get published.
One of the reasons Lisa was successful as a consultant was her ability to go good research. Her pet peeve at conferences is seeing people present information that is based on poor research.
The research element is a huge dividing factor separating academic publications from non-academic publications.
However, Lisa doesn’t discount articles that aren’t based on more rigorous research. Lisa says that the non-academic publications provide academics with preliminary data, which can then be leveraged in more rigorous research.
One of the questions in the latest TC journal is whether tech writers should be specialists or generalists. The research in the journal suggests that generalist skills form the core identity of tech writers and allows them to play more roles throughout the product life cycle. The journal used a Delphi method with iterative surveys. Is this the best way to go about the research?
You need to start as a generalist, but if you’re ever going to advance, you have to specialize. Lisa’s specializations, especially her geography and environmental science knowledge, helped her advance in her career.
Which is more persuasive to practitioners — the academic approach or the practitioner approach? Does all of this rigorous academic research really matter to practitioners?
When you’re a consultant, research can be key to your survival because you constantly have to argue for the positions that you take. Consultants have to leverage the research to make compelling cases.
Rigorous research also helps us avoid repeating history. There’s definitely value to knowledge, but you may value different types of knowledge.
Additionally, there is sometimes a contradiction between specialized, authorized knowledge (based on your own experience at different companies) and generalized knowledge (based on academic research).
The research in the journal gives you validity and authority to persuade clients. Anecdotes are a single data point, but not enough to persuade people to make decisions that have millions of dollars attached to it. If you match the research to the organization’s goals, it provides a strong case.
How can we bridge the divide between practitioners and academics?
Academics can be more public in their work. If given more assistance, academics might write more blog posts. Academics can put out practitioner versions of their research.
Practitioners can participate when asked to complete surveys and provide other feedback and information.
If there is data practitioners want, they should ask academics. This can help academics focus on research that they should do.
Overall, there does need to be more exchanges between academics and practitioners, especially at conferences. We need to be showing up at others’ places more regularly. We have to be talking more to each other in different locations.
Practitioners should also respect academics more, recognizing that the job academics do is different and unique. The sense of value practitioners have towards academics will increase as practitioners see the value of what academics write.
- Lisa Meloncon’s website and blog
- Intersections at the Ivory Tower
- Why is there a divide between academics and practitioners in tech comm?
- Lisa’s U. of Cincinnatti About page
About Tom Johnson
I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.