Communications

As Research Engineers, we work closely with other scientists, and this requires a high skill in communication. This is one of the things which most of our new staff get surprised about. Compared to being a academic researcher, you must be prepared to work with customers who have very different focuses than you.

About this page

I don’t seriously think that anything I can tell you that you can’t better learn elsewhere. I don’t think this can be complete or a proper lesson. There are so many unique communication styles and unique projects, you need to figure out what to do yourself, via a lot of trial and error and learning from others. I hope can get you thinking (and maybe we can make it better), but always keep thinking, learning from others, and improving things.

Specific guidance for certain types of situations is found under the roles section.

Key rules

• Think defensively. We are the professionals and thus it is our responsibility to think about how you can be misinterpreted and preemptively prevent that.

• Right level of detail. Most of our customers don’t need to go as in-depth to technical things as we do. You need to present what they need to know.

  • RD: in Garage I always start by gently asking “what’s your position and department? [and history]” to understand where they are coming from.

• Be brief. Get to the point fast enough to be relevant (see above). People have much less time to listen to you than you have thoughts. You need to prepare your message well.

  • Of course, details are often needed, and you need to structure your presentation where you get to point fast for most people, and can go deeper {if needed, with others}.

• Don’t go alone. If you have a colleague there, you can work together (just like co-teaching). Two brains helps to detect mis-understandings earlier and people can think of different levels.

Also think of if you need to communicate strategically (broad shared mental models and ideas) or tactically (how are we working together to do something). Different people need a different view on the same project (e.g. professor vs their student you are working with). You will need to tailor the message to each.

Garage support

When you are doing small garage-type support, you need to figure out needs quickly and make a quick impact. You have less time to get to know the person and project, and perhaps less likely to already be familiar with the topic.

Keep in mind the “other side” of the “formulate your question” guide for customers in Help. Asking these is part of being defensive. We tell our users to tell us the following, so make sure you think if you need to ask these:

• Has it ever worked? (If so, what has changed?)

• What are you trying to accomplish? (Your ultimate goal, not current technical obstacle.)

• What did you do? (Be specific enough to be reproducible - copy and paste exact commands you run, exact output messages, scripts, inputs, etc.)

• What do you need? Do you need a complete solution, pointers to get started, or should we say if it will take too long and we recommend you think of other solutions first?

It is far too easy to quickly do something, and then realize you did the wrong thing.

See also:

• Garage supporter: All the things under “Garage support”, including the references there.

• How to actually respond to user support requests?: guide for answering users, notes from an old un-presented seminar. This is rkdarst’s lore.

Projects

Projects have unique communication needs in that they are long-term and you will go much more in depth. There are very many more ways for something to go off the rails and the team members to get de-synced.

Just think, for example, that you need to communicate a shared vision through all the following stages. At any stage, if the vision de-syncs, thing can go very far off the rails:

• The initial idea

• Decision if the idea is worth pursuing

• Formation of a plan

• Execution of the plan

• Finishing the plan (or deciding what is finished enough)

• Reviewing how it went

These steps may happen in a project with yourself, within ASC, with customers, or with the broader community. Everyone is busy and most people can’t go as deep into topics as you can, so you need to be able to summarize and present the right information to the right person.

Meetings

Meetings are the time we talk with customers, and while hacking/working-together meetings can be ad-hoc, when there are many people involved (for example the PIs or it’s starting a project), they need to be smooth. I won’t pretend to say the best way to do meetings, since there are so many unique needs, but it is something you should think about and prepare fore.

This document on military briefings (rkdarst found when searching how to do briefings for a game) was a somewhat useful classification. It is way too formal for us, but does provide some useful guidelines in a non-nonsense setting where people have to practice and do it well. I think it’s good to think about the different purposes a meeting may fill, and make sure the structure is tuned properly:

• Always start with what the purpose and structure of the meeting is. Ask if there are initial questions and if agenda seems OK.

• In reality, many of our meetings are a combination of the below types, so keep the overall structure and structure of each part clear.

• Information briefing: You are presenting information and the goal is listener compensation.

  • Keep it to the point, but the goal is for learners to see the whole picture. Start with the overall map of the info and end with a summary of the take-aways someone should remember the next day.

• Decision briefing: You are seeing a decision from those attending (who is less involved than you).

  • Present several alternatives and your recommendations (remember, you are probably the expert - don’t expect the audience to come up with solutions if it’s in your domain).

  • Realize that you know things that others can’t and won’t know, so you need to adjust your presentation so they can understand at a relevant depth (trade-offs relevant to them) to make the decision. As in, you do first filtering to figure out what they should consider, then they think about that.

  • Keep it to the point, but it’s possible a decision can be made even partway through without the full details. It’s also possible questions will take you deeper into some of the options.

  • Make the decision clear and write it down.

• Staff briefing: This is the term used for recurrent “status update” meetings.

  • Keep them short and don’t reproduce what could be read independently. Tailor for the audience and what is most important to discuss.

  • Can easily become boring and a waste of time if you can’t focus on what needs to be synced.

• Mission briefing: You are about to do something together.

  • More focused on coordination, much more technical. May have fewer people, or you may release the PIs after the initial intro and framing while others do hacking (if PIs aren’t involved so much there).

• We are much less formal than all of these, and many of our meetings have different types all mixed together, but there probably some worth to considering these points, writing to them, and being explicit about it.

• I think almost every meeting should have a live notes document (for example the project template google doc) which is set up at the beginning, screen-shared, and used to take notes. Share the link with everyone (if you use the same doc repeatedly, it’s easy next time). Yes, this takes some time but shows that we are actively listening. It also allows decisions and plans to be immediately recorded.

Meetings are a good time to bring another ASC team member, or use them to look over your materials. If you can’t explain it to an ASC team member, do you have any hope for customers? Does an ASC team member help to take notes or maintain a larger strategic overview?

Reports and writing

Most of us come from an academic background and have plenty of experience writing. Just like many of the things above, there is a difference in writing as research engineers: academic writing is made for other academics deep in your field (show your deep knowledge to get cited), while most of our writing is for people who are not as deep in our field and we need to adjust the way we think and write. (Same as everything above, right?)

Working together

Try not to be alone when there is any doubt of getting the message across as simply as possible. One thing I have found is that, even before preparing writing or a presentation, talk with someone about what the main points will be - what is my message actually going to be? Then expand some, then talk again, etc. Work backwards this way with others instead of making too much and trying to figure out what to remove. Often the “what is my message?” that is the hard part of planning communication, not “how do I write/say it?”.

Be involved early. It is much easier to help guide the main messages early, rather than try to fix them later after a lot of work is done. If one gives advice late, it often just becomes minor changes and not helping with the main message-setting. Insist on being involved early.

Bottom line up front

I can’t stop thinking about the concept of Bottom line up front (BLUF) communications, and similarly the inverted pyramid of journalism. In both of these, the point is to convey the most important information first, not slowly justify the conclusions. For busy customers, this is useful.

The basic idea is getting the point (recommendation, conclusion, request, …) first, and then supporting it. With this strategy, someone can stop reading as soon as they feel have enough information to do whatever they need to do. If one is receiving a request, they can know what they are asked immediately and stop reading (or begin skimming) once they have enough information to make a decision.

The typical academic writing style is the opposite, where one starts with background and slowly derives all conclusions, where each point is in theory justified by previous text. (No, an abstract doesn’t make it BLUF.) This either requires a huge time investment to read or requires the reader to hunt for what the main point they need to know is.

BLUF can be applied to emails, presentations, discussions, etc. It can take time to get used to, but can greatly improve response rates. It saves customers time and increases our efficiency. It is probably not applicable everywhere, but I recommend everyone to consider if every email/presentation/etc. they do could benefit from BLUF.

Other notes

• Communication is also about thinking. You need to figure out what the real issue is (by communicating) before you can communicate to solve it.

• Our work is often meeting of minds of two different specialties, where both sides don’t need to go deep into their things. What you need to think about, others may not need to. Managing this difference is very important.

• Conveying information succinctly (briefing). Most customers don’t need an academic talk on what we are doing. They need a staff briefing to figure out what they need to know.

• For a lot of this, we talk about work with customers. It’s also true within our team. We need to distilling down to the right important things that are needed to share information and make decisions. Even within the team, we have different roles, and not everyone can or should be the same depth into everything.

• Leaders finding the right information and converging to a decision in the right timeframe.

• My (rkdarst’s) estimate is it might take about two years of being on our team for someone to get good at this. Take it slow, be prepared for frustration, and take colleagues with you to support. Talk about what goes well and not so well.