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.

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 support: 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 (found when searching how to do briefings for other purposes) 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?

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.