PDF version available here.
Research Software, Computing, and Data teams help advance the forefront of human knowledge every day. Our teams are research accelerators, helping research groups tackle more ambitious projects faster, preparing trainees for future accomplishments with new skills, and building a foundation of expertise and infrastructure that can improve the research of entire departments if not institutions.
You might think the teams would be constantly trumpeting these accomplishments. But almost none do, because they’re not taught how. Worse, many have been led to believe that communicating these successes is tawdry self-promotion, unbecoming of a team in the academy. “The work”, we’re told, “speaks for itself”.
This is a lie. It has always been a lie. The actual, obvious, truth in a busy, hands-off environment like academia is:
No one knows what your team has accomplished unless you tell them. Repeatedly.
Our teams deserve to have their wins and successes proclaimed. We need potential research clients to know what we can do for them; we need decision makers to see the impact we’re having; our team members deserve to see their names publicly associated with wins; potential team members need to see that the work of the team is exciting, meaningful, and recognized.
But it’s not enough to tell people once in your own words.
In order to have the communication matter, to have impact, we must to describe issues your audiences care about, in words they would use. The more expert we are on the technical matters, the harder this becomes, even if we were researchers ourselves. We need to borrow their words to do this well.
And in order to have the communication to “stick” with decision maker audiences, we must have multiple formats for conveying the same ideas, and present it to them multiple ways.
We need to cover both bases, with as little effort as possible given the demands on our time. Interviewing researchers lets us get multiple things out of the conversation. We can use the conversations to build a content library, helping us to both use the researcher’s words and tell the same story in different ways.
There are three audiences our teams need to communicate our stories to.
[This is 545 words]
For each case, the more we can echo the audience’s own words back to them, the more effective our success story write-ups will be.
The biggest distinctions here are:
Let’s start with the easiest audience for us:
Communicating (and, yes, marketing) our wins to these audiences is crucially important. We don’t have a lot of time to put into it, yet it’s vital to do it and do it consistently. A series of success stories that petered out three years ago does not inspire confidence.
That means we need to find ways of addressing all these needs with a minimum of effort. This means one of:
[~750 words]
For technical-audience content, teams tend to already have multiple points where technical stories can be generated with little additional effort:
Making public write-up publishing a consistent part of the process has the advantage of not pre-filtering stories. The answer to “is this worth writing up?” is “yes”. Communicating successes and accomplishments and new things learned isn’t something to be saved for special occasions or major initiatives:
[1000 words]
Note that the style you’re aiming for is not what we’re used to in writing up results. It is shockingly easy to take a story about how a team member wrestled with fun and challenging technical puzzle managed to discover an ingenious solution, then have our scientific writing experience take over and crush all the life out, rendering it a dry-as-dust, tedious slog of disembodied facts.
These stories must let your technical staff and their excitement or glories shine, for themselves and to future recruits! These aren’t mini technical reports, written in a soulless, objective and factual manner to sit as references on a shelf somewhere. Name names (not “we”, “I and my colleague [name here]”), describe false starts and hints, have the team member explain in emotive language why they’re excited about the technology or solution. We like our jobs and enjoy our successes and tools! These stories should reflect that.
I won’t focus any more on the technical stories, because teams have the experience to be excellent at writing those up once they get started doing them. The main challenge is to write good researcher-targeted success stories. And once those are in, distilling them down to target decision makers is straightforward.
To go beyond that will mean asking researchers for a modest amount of time, to collect their feedback and input in an interview.
We could write up our success story blog post without doing the interview. You and your team know what work was done, and what the science project was. That would serve the “recruiting candidate” audience fine, because it would be written from the technical point of view. But we need the researcher’s take, in the researcher’s words, on why our help mattered and the impact of that help for the writeup to appeal to the “potential researcher client” and “decision maker” audiences.
It’s ok if you don’t believe this; it remains true regardless. When researchers talk among themselves about your team, they highlight different things and express themselves differently than you would. You’ve likely noticed that word-of-mouth referral is more effective than you pitching your team. Here we’re trying to scale word-of-mouth referral by getting the researchers to commit their referral to text, and publishing and publicizing the text.
As a side effect, you’ll learn what researchers value about collaborations with your team, and what can be usefully changed. This is priceless information.
Even better, you can share some of those quotes about what the researchers valued, as testimonials.
Researchers don’t have a lot of time. Not every researcher will want to take a call with you. But if you’re clear about what it’s all for more than you might expect will give you a modest amount of your time. The motivations will include:
[1,500 words]
As an aside - an awful lot of our profession makes more sense once we realize we’re in the B2B professional services business, serving the busy leaders of small (research) businesses. They have many of the same needs we have - marketing materials/content for social media and their website, recruiting, securing funding - and we can help each other, one busy head of a team in the research space to another.
We don’t have a lot of time to put into this, and we don’t have a lot of our researcher’s time. We want to get multiple things out this discussion. The process will go more smoothly with a clear idea of what you want to end up with.
My suggestion for outputs from this process are below. You and your researchers might want something different, but this list is a doable and useful starting point:
For us:
For them (assuming they want them):
This sounds like a lot of work, but it comes down to recording a professional discussion between peers about a project, making transcripts, grabbing a couple of highlights, editing a couple of video clips, and writing up two short write-ups (and tools like Bing Chat/ChatGPT/Claude can help us enormously with first drafts of those given the transcript and ancillary materials.) With practice the whole thing, including the interview, fits comfortably in an afternoon with time to spare.
Note that if you go through this process and don’t get everything on the checklist above, that’s ok. Because our time is limited, we want this process and the work we put into it to serve many purposes. It doesn’t have to serve all possible purposes.
[2,000 words]
It’s the testimonial slide, feedback, and story that are top priorities.
For our teams, the most valuable thing we can get out of the call (and so what has to be priority 1) is a pull quote. Something along the lines of:
A good quote for your team and your collaborations might look different - longer, focussing on a particular aspect of the collaboration…
But glowing quotes like that are achievable, and reasonable to seek. Your team does speed research, make more ambitious projects possible, and grow the skills of trainees you work with. It’s perfectly ok to solicit and collect quotes that say so.
The most common way you’ll deploy this quote in the form of a slide that has, say:
As you collect a library of these, you’ll be able to use them all over the place - presenting to new faculty, pitching to decision makers…
Besides the pull quote testimonial, you’re going to be collecting other feedback; things that went well and were valued, and things that they didn’t like, in their own words. Both are invaluable.
You’ll be collecting all of this information, and file it away. Don’t react to it in the moment except to thank them for it and make notes.
You’ll use the feedback in two ways. Positive feedback you will echo in their words in the story and in discussions with other researchers. They appreciated how attentive/responsive/insightful/constructive the team was, and how much faster/more ambitious/more impactful the research was as a result.
Both positive and negative feedback you’ll share with the team, and collect and act on in aggregate. Feedback is invaluable, but it’s also noisy data. We’ll talk more about this later.
We’re going to get a short writeup of a success story, which means we want to know the goal of the project (the scientific impact and avenues that opens up), the challenges faced, how your team helped overcome them, and the happy ending, all from the researcher’s point of view.
As with the technical stories, this won’t be a scientific paper; it’s a blog post. It’ll be a quick read, a demonstration of success, and something that will get picked up by search engines.
Bloggers, copywriters, newsletter authors, and more have been experimenting with the “best” length of a blog post since the late 1990s, and it’s bimodal - there’s interest in both ~750 word short pieces, and ~1,500 word longer pieces.
[~2,500 words]
Our audience is academics, and we read a lot, so it’s ok to mainly have the longer pieces, although a mix of short and long is nice for variety.
Longer than 2,500, though, starts to get unwieldy. Now you’re talking about a 7-10 minute read, which is a lot to ask for on a a browser and an eternity for a casual reader to spend on one article on a phone screen. Blog posts of under 2,000 words, with links to the paper or talk slides or other long-form scholarly material, is a sweet spot for these articles.
I marked the 500, 1000, 1500, 2,000, and 2,500 word counts in this writeup. This is now above 2,500 words, and, well… it’s been a bit of an investment of time, right? This stopped being a casual read a few pages ago.
I’m writing this document as a comprehensive why-to and how-to, a single write-up to point people to when they ask questions about this approach. It’s not a brisk introduction where I invite people to contact me or follow links to find out more; this is intentionally an instruction manual, with all the heft and time requirement that implies. It won’t be of interest to most.
I might well make various abbreviated overview versions of subsets of this material in the future, to make different use of the content. An introductory “teaser” version for people to scan and decide whether a longer document would be of interest would be useful, for instance. But that’s not current aim for this document, so I haven’t done it.
Your success stories are different. They have as a purpose reaching potential stakeholders and making a quick positive impression. If the story is relevant to a client’s needs, you even want to inspire them to contact you, which means that you don’t want the material too detailed. You wouldn’t write it in the style of this material. Given different goals, we scope our writing differently.
We’re all busy. The researcher, considering your request for a call, will have two questions running through their mind: “why should I do this”, and “why should I do this now”.
If you are approaching a friendly and supportive researcher you have a strong working relationship with (an excellent idea for the first few), this won’t matter as much. For those you have weaker ties with, it can work well to time the request soon before a milestone for them. Examples include:
Using that milestone as a hook, send a short email asking them to do a call with you - the details will be later. A sample:
Subject: Video Call Discussion For Blog/Social Writeup about [Project Name]
Hi, [Researcher]:
We think a lot of people would benefit from hearing about [project] - it’s particularly interesting!
With [milestone] coming up, we’d like to write up a success story about [project] for our blog and social media, and feedback from you (and a testimonial, if you’re willing) about how it went.
A call with you would really help. I’d love to hear your perspective on the science impact of our work, what *you* found valuable, and what we could do better.
I’d be happy to provide you with a video clip of you describing the project and it’s science impact, and a writeup of that description for your lab website site & social media, if you’d find that valuable.
Can I have a recorded 45min call with you [you’ll get this down to ~30 min with practice - LJD] to discuss the project, and then I’ll do the rest? You’ll get to approve our writeup before we publish anything.
Thanks!
Politely thank them, and ask them if some time in the future would be better. We’re all busy, and this may not be a great time for them.
From the routine workings of the project you probably have, or have access to, project tickets or emails or WIP talks from the team about the work done.
Once you get a “yes” to an interview, it’s good to start reviewing this material. It’s a great trove of topics to ask about - whether it’s areas that seemed to cause problems, or interesting techniques.
You’re not reviewing the material to get up to speed on what was done - you really want the researcher being interviewed to provide all that information. But those materials are generally a great source of material for questions.
Also, collect any aesthetically or scientifically interesting images that were generated as part of the work - you can use those as default images to use in the write-ups.
Now, with those images in hand, you can send along the interview questions and scheduling request. An example is in the appendix. A potential list of questions follow:
You can ask some questions (over email or face-to-face) of the person on the team who has been/had worked on the project too, the team lead/project manager in charge for a larger project.
This is for a further perspective, and for more possible questions to ask during the interview.
Here you can settle with just informal discussion with some notes, or an email exchange:
Recording a Zoom or Teams call will make the process straightforward. There are more sophisticated tools for doing good two-person remote interviews, or for two-camera interviews in person, but the best tool to start using is whatever you and your researcher client use now.
If you have the choice between Zoom and teams, Zoom is better because you can record each audio track separately which makes cleaning up the sound much easier. At the time of writing, this is done by:
Teams won’t be as good for improving sound quality, but on the other hand you can turn on transcripts when recording, and Teams’ transcriptions is getting stronger and stronger at time of writing.
You’ll need something for creating clean transcripts of video calls and editing video clips. You might already have tools you like for this, in which case, great. If not, my favourite tool for this, by a lot, is Descript. It will transcribe the audio, clean up the sound, help clean up the transcript, and make producing video clips with text captions incredibly easy. The free subscription will get you most of what you need, but the pro version is worth every penny. Record locally. When the talk is over you’ll import the audio tracks and video into Descript or other tool.
I’ve seen people in our position get all weird about the recorded interview, like it’s supposed to be something people watch in its entirety, so it has to be smooth, professional, rehearsed…
Don’t worry about this. No one, not even you, is going to watch this recorded conversation end-to-end.
This is a data collection process. You and your colleague are going to have a structured professional discussion during which you’re going to collect information. The data collected from this discussion will go into blog posts and video clips. But only after a lot of data cleanup.
You can hesitate, repeat yourself, ask your colleague to rephrase something, run out of your home office for a minute to ask your partner to stop their yodeling practice, whatever. Don’t worry about it. We’re just collecting data.
Keep a list handy of the questions you’re planing to ask.
During the discussion, jot notes down on it to remind yourself of questions to come back to, and topics to follow up on - there’ll be lots, and you won’t remember them all on the fly.
Don’t worry about taking notes on the content of the interview otherwise - that’s what the recording and transcript is for.
And don’t worry about asking every single question you have written down. Again, the goal is to get lots of useful data, not to get every possible piece of useful data.
In emails with the researcher, we’ve talked about this as a “discussion”, because we don’t want them to be weirded out or feel on the spot.
From our point of view, though, we should think about this as an interview. It’s our job to ask questions and lots of followup questions, not to state things. 95% of our sentences after “Thanks for taking the time to talk with me” and before “That was great, thanks; I’ll send you the writeup shortly” should end with question marks.
Remember to dig into anything that sounds interesting or helpful. My favourite open-ended followup questions are:
Every now and then, it can be helpful to rephrase, either to check for understanding or to prompt a line of conversation — “would it be fair to say …..”? Which brings me to:
The one thing we do want to get right during the interview recording is the 10-ish-second video clip and quoted text of the researcher giving the testimonial.
And that will take some direction from you.
During your discussion, the researcher will effortlessly speak entire coherent, compelling paragraphs about the scientific project and its impact. Between recruiting trainees, writing grants and papers, and giving talks, this is what they do for a living. It’s what they think about all day.
What’s more, they know that nice, crisp, powerful sentences extolling the importance and inherent interest of these topics are important. Getting those first and final few sentences in the proposal or talk abstract or letter of reference just right matters for reasons they deeply understand.
They don’t spend as much time thinking about our team’s work that way. Nor should they. But if they’re at all positively disposed towards the team, they can appreciate that we benefit from nice succinct positive testimonial sentences just as they benefit from a powerful introductory paragraph on a grant proposal or on a letter of support for a tenure application.
And they’re overwhelmingly willing to restate a positive sentiment in a stronger but just as truthful way when prompted.
We’re two professionals talking about work done together. It’s perfectly ok to ask for a stronger quote from a satisfied collaborator. Or just to say it again if there was background noise. They won’t say it if they’re not willing to say it.
(Even though they may seem more intimidating, the more senior and high-profile the investigator is, the more familiar they are with this dynamic. University Comms has put them through this asking-for-a-quote thing before, often for reasons significantly less meaningful to the researcher than bringing a research project to a successful conclusion. It’s the juniors being asked this for the first time that might hem and haw.)
When you hear a strong, positive, and (from your point of view) helpful sentiment for the researcher, but the wording needs to be tightened up some to be useable, it’s perfectly fine to ask for that.
As you get more comfortable doing this, you’ll develop your own way of asking. My approach is to go in two steps.
They’ll likely pause, playing the words in their head to make sure they’re happy with it, and then cheerfully say it. Thank them profusely, “that’s going to be such a help!”, and continue with the interview.
It’s perfectly ok to do this a few times during the interview.
Once they’ve learned what you’re looking for, in your next interview with them, don’t be surprised if they have ready-made quotes all queued up.
Thank them again, and let them know you’ll get back to them shortly with any followup questions you have, and then:
And, if they want it:
I tend to ask people if they want those things at the end the interview, when they have more knowledge of how it went.
Your video transcript is your main source of notes, so generate the transcript and go through it first. If you’re surprised by the difference between what is there on the screen and your memory of the conversation that happened, that’s a good sign. It meant you were properly part of the discussion.
Highlight/underline/copy-and-paste any strong quotes by the researcher, even if only a couple words long, about the collaboration (positive and negative), about the science and its impact, about next steps…
Log the positive and negative quotes about the collaboration somewhere, along with any suggestions for other people to talk to. We’ll come back to these later.
Also highlight any sections that correspond to promising potential video clips.
Positive quotes about the collaboration, and strong quotes about the science and impact and next steps, are things we can use in the success story draft.
Similarly, make a quick pass through the notes or email you have from asking the team member questions. Look for potential quotes for the article. (You can also ask them somewhat more directly than the researcher if they’re willing to say something more quotable - “Can I quote you as saying [better version of what they actually said], or is there a wording you’d prefer?”)
By far the hardest part of this whole process is to get a complete first draft of the success story post written out. After that we can edit ourselves or ask others to at our leisure to get things to the point where we’re happy, and the other tasks are pretty straightforward.
My experience is that the sooner the draft is written after the interview and transcript review, the better. Get it out while it’s all fresh in mind. Pondering over it weakens the article, and leaves it weighing on your to-do list.
AI tooling can help a lot, a section at a time. You can experiment with feeding it your inputs (relevant chunks of transcripts + background material) and ask it to write up a short section in the style of (say) a popular science magazine. The tools uniformly work better if you iterate on the section “with” the chat bot, calling out things you like and don’t like and asking for rewrites. Think of these tools as enthusiastic, eager-to-please, precocious interns from an alien planet. What they do and don’t need guidance on is surprising even when you’ve worked with them a while.
Also in my experience, the writing goes much faster if you have a story structure in mind. Over time you will develop a small library of structures that you can match to the story. These common structures will greatly accelerate getting out a first draft.
Do not worry about the reusing a story structure making the stories “formulaic”:
Short write-ups like this will overwhelmingly have a structure along the lines of:
The only real question is what goes where. Then the work goes into making it compelling to the audience you’re targeting. For the researcher audience, just using the researcher’s own words to describe the challenge and success goes a long way.
In the Appendix are a couple template structures to get you started (once you learn the structures, you’ll see them everywhere).
However you write the first draft, use direct quotes, and echo the words the researcher used, as much as possible.
Remember to focus on the science goals and impacts. The request might have come in as asking for help with extending a 20-year old Fortran program, or to quickly get priority access to 20 nodes for an urgent project, or to analyze a directory of CSVs looking for unexpected correlations. Even so, it’s the research driver and research impact that matters to this (and other) researchers, and decision makers.
I never would have recommended doing video clips for these things five years ago. The time investment would have been prohibitive, and we weren’t doing video calls nearly as often so the recording would have been harder and lower quality.
But now video calls are so common, the tools are so straightforward, and the number of venues for using and sharing short (< 2 minutes, but especially < 30 seconds) videos so plentiful and high-traffic that it seems like a mistake not to do it.
You already know my favourite tool for this, Descript. Use its tools to clean up the transcript, and add “studio sound” on each track to clean up the audio. Copy-and-paste the sections of video you want into different compositions in the same project. Crop your video out of the frame so it’s just the researcher. Add captions (definitely) and audiogram (maybe), and you’re good to go.
You can crop the video to the format you’ll be sharing it on - portrait for TikTok/Youtube Shorts, landscape for everything else, square for something sort-of usable everywhere.
There are other tools worth trying. At the time of writing, Vidyo.ai is a new-ish tool that promises to automatically pull out helpful video clips from a longer video. There’s doubtless many others.
This one’s almost cheating.
The explanation of the science project and its impact that the researcher gave you at the start of the call is going to be almost perfect.
A cleaned up version of the transcript, maybe with a couple of links to wikipedia articles and acronyms expanded, is going to be a very serviceable first draft of something they can post on their lab web page explaining the project (and then linking to papers).
(You could even include a link that point to the success story writeup!)
Yes, the researcher could have written that up themselves, but for some reason it’s much easier (and faster) to just explain it to someone else than it is to write it up. This is a painless way for us to provide something to the researcher that they can probably use but would likely not spend the time to produce themselves.
Similarly with the corresponding video clip of the explanation. Yes, they could have opened up their phone or started an empty Zoom call and recorded the same thing themselves. But I bet they didn’t. And even if they did, the recording more lively and engaging when it’s an explanation to another real person, even when that other person is off-screen.
The success story isn’t going to do anyone any good sitting in your drafts folder.
I get it, we’re perfectionists, we’re used to word-smithing grants and manuscripts for months.
This isn’t like that. This is a blog post. It’s online on your website! You can edit it as much as you desire after publishing.
You have my permission, even encouragement, to go back and do some rewriting — after you’ve published it, and ideally after you’ve written and published a few more.
Make it better tomorrow, if you like, but make it published now. Start with sending your perfectly serviceable draft for approval.
Note that you are not asking for them to edit it. They don’t need the homework, and you might not benefit from their suggestions.
You’re asking for approval for the story & quotes & to use the video clips. We need to know if there’s anything so flawed that we shouldn’t use them as they stand. This is an accept/reject situation, not an “I think you should…” situation.
They can tweak the wording of the quotes, if they like — we’re using them as faithful rendition of their words and sentiment, after all — but don’t even directly ask for that. They’ll volunteer changes if they think it’s important. You’re not giving them an editorial chore; you’re asking “is this ok as is?”, and giving them an opportunity to stop you if it isn’t.
In general, so you’re not sitting around waiting for weeks for them to get to this, I usually give a default action by a deadline:
Hi, [Researcher]:
Thanks for the discussion on [project]! I really enjoyed it.
As promised, below is the success story write up. And here is the pull quote [optional: and video clip] we’ll be using:
[Testimonial quote here]
The plan is to push publish on these [a date, say, a week away]. Let us know there’s anything in there that’s not ok to publish as is!
[If asked for:] Also attached are the video clip of you explaining the project and scientific impact, and a first draft of a write up of same, for use on your lab website and/or social media.
We look forward to working with you again!
Sometimes in the course of writing up you’ll realize that something wasn’t as clear as you had thought. It’s ok to send a batch of follow-up questions, either with the approval (“I wrote [such-and-such] - was that right, or did I misunderstand?”) or while writing up.
Once the success story is up and being served successfully, you can post (or schedule) social media posts pointing to it.
You don’t need to over think this - the images you have, or even better video clips, along with the link to find out more, is great.
The slide comes together quickly rom the material you now have. As a reminder, you’re looking for something like:
If fortune has smiled on you and there’s two (or more!) different quotes worth including, make multiple versions of the slide, one with each.
When making use of these slides you’ll always be carefully curating a few (by topic, field, or work done, as a rule). You can choose which of these to use depending on what the other slides say, choosing the most complementary testimonial to the others and to the message you’re trying to convey.
The feedback you’ve logged is great to share with the team. These “voice of the client” sessions can be an agenda item at a team meeting, or can be part of routine post-project retrospectives.
If you’re routinely doing retrospectives at the end of the projects to speed learning and improvement (a practice I highly recommend!), and can time the interview right, that feedback can be included here.
Otherwise, I’d recommend batching the feedback, every so often, share the collected feedback of three or more projects, and having a discussion around it. This is a way of having a richer, longer discussion around more feedback than a single project can provide.
One very natural tendency is to over-react to individual pieces of negative feedback; but feedback is just data, and data is noisy. It’s really patterns of data that matter. If multiple researchers all see areas for improvement in the same area, they’re probably on to something. They may not be right about the source of the problem, and they may even disagree with each other - but there’s some signal there. Similarly, one researcher might find an aspect of working with you as exceptionally valuable, while that doesn’t register with others at all - again, it’s the patterns that matter, not individual items.
Choosing some steps to take, and revisiting how that progress has gone for the next round, can be an excellent way to make sure that your team is taking full advantage of the feedback.
Try to remain partly un-fobbed.
Honestly, the trainee is more likely to be a good interview! They’ll be more expressive, they were presumably more engaged with the project work, and turn around times for approvals or followups will be much shorter.
The main problem from our point of view is that the testimonial will carry much less weight; secondarily, the feedback will be more tactical so less valuable.
My approach here is to aim for the best of both worlds. Do the interview with the trainee, but ask for a followup-call with the PI:
Hi, [Researcher]:
Great! I’ll schedule the call with [trainee].
I’ll send you the write-ups for your approval; may I have a 15 minute call with you to go over it afterwards and collect your feedback and a quote or two?
Thanks!
We might not get the feedback call, but it’s well worth the ask. If we do, the aim is to get additional feedback and the testimonial in the shortened call.
Yes, but.
It won’t be as good; you won’t get as deep or rich feedback. And as we are all very much aware, researchers take forever in email back-and-forths.
Still, if the researcher is willing to do it over email but not over a call, then the email is hugely better than nothing.
You’ll be surprised by how many researchers would rather have a single call and get it all done, though, then be on yet another email thread of indeterminate length.
Yes, with a little attention.
I wouldn’t get someone junior on your team to do it. Amongst other things, if they’re junior enough it’s not really fair for them to have to come back with possible negative feedback for peers or the team.
Further, it’s good to show the research clients that the head of the team takes hearing from them seriously. If it’s someone on your team, probably best if it’s you, unless there’s someone super interested in growing their skills in this direction. In that case I’d still send them a thank you afterwards, or be involved in some other small way while still letting your team member run with it.
On the other hand, if you can get a third party or someone at arms length from you to do the interview, that can work really well. Someone outside your team, not so involved in the work, can often ask better interview questions on behalf of the reader. And sometimes it’s easier for the researcher to share frank feedback (positive or negative) to someone else rather than with you directly. You can certainly investigate having someone external doing these and reporting back.
Otherwise, if you work at an institution with a journalism school or communications program, another option is hiring an intern from those departments. That can be really helpful for doing the interviews and/or writing up the results, as well as working on other comms tasks. They will need some supervision and guidance on the science parts of the story, though.
Assuredly so! This can be a good way to reconnect with a researcher you haven’t worked with for a while, or to revisit a notable project. Or just to get started with your library of success stories.
One great advantage of a story from a while ago is that its impact (which is, let’s face it, a little hypothetical when the project is first completed) has become much clearer. Maybe the paper got the researchers invited to give a prestigious talk, or was a key reason why a proposal for follow-up work was funded. Those are fantastic things to include in a success story!
If there’s a milestone coming up or recently passed, like a paper that comes out, the researcher is more likely to say yes to a call. (Is it possible to tie into an upcoming paper that references the work?) But there’s no harm in asking even if there isn’t.
With a current project the story will be fresher in mind, and the interview and success story will be go longer and more in depth. But you don’t need a full hour of material to write a perfectly good success story and collect useful feedback.
I wouldn’t bother with the social media posts for older stories, unless there’s unusually good interview material or visuals. But the stories themselves (and as ever the testimonials) are valuable regardless of when they happened.
Yes! For a large project, this can work very nicely. You may even find that there’s increased willingness to give you frank feedback when there’s “safety in numbers” for them.
For that reason, group conversations can work well even apart from success stories; you can do a “focus group” with say a department or institute for collecting feedback and suggestions for new services.
I’d definitely recommend doing some of the interviews yourself. Talking with your clients and hearing how things are going in their work with your team, and what they’re thinking of next, is a very powerful way to spend our time.
Almost everything else can be effectively delegated - the pre-reading, the write-ups, the video editing….
That’s not really a question, but…
Not good enough? Are you kidding? Have you seen the stuff researchers will slog through if it’s relevant to their work? Hit the big green button and publish it.
Subject: Video Call Discussion For Blog/Social Writeup about [Project Name]
Hi, [Researcher]:
We think a lot of people would benefit from hearing about [project] - it’s particularly interesting!
With [milestone] coming up, we’d like to write up a success story about [project] for our blog and social media, and feedback from you (and a testimonial, if you’re willing) about how it went.
A call with you would really help. I’d love to hear your perspective on the science impact of our work, what *you* found valuable, and what we could do better.
I’d be happy to provide you with a video clip of you describing the project and it’s science impact, and a writeup of that description for your lab website site & social media, if you’d find that valuable.
Can I have a recorded 45min call with you [you’ll get this down to ~30 min with practice - LJD] to discuss the project, and then I’ll do the rest? You’ll get to approve our writeup before we publish anything.
Thanks!
Hi, [interviewee]:
Thanks for agreeing to speak with me about our project! If you share a few 45 minute slots that would work for you, I’ll find one that I can make. [If you have calendly/microsoft office scheduling: “or, if it’s more convenient, you can pick a time at this link”].
I’ve attached a couple of images we have from the project; are there others we should use in the success story post or social media links instead, or alongside?
The sorts of questions I usually ask when discussing how the projects went are below. I might followup questions on things that went particularly well, and with your permission would use that quote as a testimonial.
Tell me about the science of your project.
What is the impact your project will have on the field - what gap does it fill
What special requirements did you have for this project which made it challenging?
What made you think of working with us?
Tell me about how we fit in to the project, and we helped?
What would you have done if we hadn’t been here to help? What have you done in the past?
What was something you were worried about with this effort and our help?
What did you learn through working with us?
What was your experience throughout the project? What worked well and what didn’t? What was your favourite and least favourite part? What was most valuable, and what do you wish had been different?
What would a new faculty member need to know about how our team can help?
What would you recommend us to other researchers for, and why? What _wouldn't_ you currently recommend us to other researchers for, and why not?
Is there anything else I should be asking about?
Who else would be good for me to talk with, about this project or others?
Thanks - look forward to talking with you!
Hi, [Researcher]:
Thanks for the discussion on [project]! I really enjoyed it.
As promised, below is the success story write up. And here is the pull quote [optional: and video clip] we’ll be using:
[Testimonial quote here]
The plan is to push publish on these [a date, say, a week away]. Let us know there’s anything in there that’s not ok to publish as is!
[If asked for:] Also attached are the video clip of you explaining the project and scientific impact, and a first draft of a write up of same, for use on your lab website and/or social media.
We look forward to working with you again!
**Title**: How [Team] helped [Researcher] [achieve the science goal] with [thing team did to help].
**Body**:
[Interesting fact from the science background of this project].
In fact, [three sentence summary of the rest of the science background]. [Relevant image about the science problem, if you have one.]
But still unknown is [the question being addressed by the science project.] [Stated as a question]?
[Researcher] aimed to answer this question by [quick summary of the approach]. By [somewhat more detailed description of the approach], they could [how they’d get the answer out of the approach].
Doing this would answer an open research question in the field. It would [scientific impact in researcher’s words], leading to [further impact/future questions]. [Link to researcher video clip of them explaining the problem and impact, if you have it.]
But it would mean they need to [thing your team needed to help them with]. The challenge here is [challenge in the researcher’s own words, maybe with direct quote.]
[If applicable: ] [Research group] had tried [doing the thing] different ways in the past with [one messy approach] or [another]. But those approaches had disadvantages - [problems, expressed using their words from the interview, ideally direct quotes].
Working with [researcher], [named people] of the [team name] tackled the problem, bringing [applicable expertise or experience] to bear.
[not-too-technical paragraph or two about interesting challenges and how they were solved, sprinkled with quotes from the team member. Links to relevant tech stories, if applicable. False starts, unexpected problems and pivots are great to read about if they happened.]
[Image from completed project]
With that done, [couple sentences of how the completed technical work plugged into the overall science project].
[Quote about the resulting impact from the researcher… “We now know…”]. [Followups and next steps].
[Couple of sentences describing how the technical work made this project faster/more ambitious/possible]. [Testimonial quote from researcher.]
You can find out more about the completed project in [paper citation & link], and more detail about the kind of work we did for it at [relevant tech success story links, if applicable].
Would you like to find out out more about how we helped here, or how we can help with similar problems? Email as at [email address], or follow and contact us on [relevant social media link].
Again, caution with this one: to avoid the “written by technical people for technical people” trap, the challenge must be something a researcher would be thinking about/asking about. Something relatable from a researcher’s point of view. If it’s “write a C++ program to..” or “improve the scaling of…”, they’ll tune out instantly.
These work:
Naming a technology or computational technique won’t.
With that warning: the basic structure here isn’t all that different, it’s just that the pieces have been rearranged.
**Title**: [Relatable Challenge] for [Subdiscipline] - Helping [Scientific Impact]
**Body**:
How do you [do hard but relatable-to-researchers thing: _e.g._ analyze 10,000 samples/collect data from strangers across the internet/protect privacy while analyzing medical data, in the researcher’s own words]?
The challenge here is [challenge in the researcher’s own words, with direct quote.] But they needed to overcome this - so they could learn [underlying scientific question].
The plan was [basic approach taken by the scientific project]. [Doing the thing] would [how it fits into the project].
And if the project was successful, they’d learn [science goal]. [Background explaining the goal and why it matters]. [Science background image if you have it.]
[If applicable: ] Previous approaches weren’t going to get them there. [Research group] had tried [doing the thing] different ways in the past with [one messy approach] or [another]. But those approaches had [problems, expressed using their words from the interview, ideally direct quotes].
[Named team members] had an idea. They had wrestled with similar problems in [previous relevant experience/expertise].
[not-too-technical paragraph or two about interesting challenges and how they were solved, sprinkled with quotes from the team member. Links to relevant tech stories, if applicable. False starts, unexpected problems and pivots are great to read about if they happened.]
[Couple of sentences describing how the technical work made this project faster/more ambitious/possible]. [Testimonial quote from researcher.] [Finished science image if available.]
[Quote about the resulting impact from the researcher… “We now know…”]. [Followups and next steps].
You can find out more about the completed project in [paper citation & link], and more detail about the kind of work we did for it at [relevant tech success story links, if applicable].
Would you like to find out out more about how we helped here, or how we can help with similar problems? Email as at [email address], or follow and contact us on [relevant social media link].
