Navigation

by Nick Belsten

Cover Sheet

Project Name: MIT AeroAstro Comm Lab Blog Posts

Memo Subject: Using memos within AeroAstro research teams

Author: Nicholas Belsten

To: Engineers, Scientists, and research team members in the field of Aeronautics and Astronautics

Initial Creation Date: 05/29/2024

Revision Number: V1.0

Revision Date: 06/23/2024

 

Executive Summary

Memos are a formal but simple method for communicating technical details with an audience which is already familiar with your work. Compared to emails, memos are more standardized, more referenceable, and tend to be more detailed. Most memos are not as polished as scientific papers, so should be drafted as soon as initial content is available. Once a memo is written, it is a living document; it should be updated to reflect new understandings and should be shared with relevant team members. It also can be cited in future internal communications. Your research project might benefit from adding memos as a technical communication option, and this memo-style blog post can serve as a template for your own technical memos. At the end of reading this blog post you will be prepared to craft your own memo for presentation to your supervisor and other research colleagues.

 

Body Pages

 

1. Motivation

 

Do you constantly sift through old emails and old slide decks looking for that one figure, or that one bullet point which you know you wrote down somewhere? You are not alone, and there is a solution! The modern technical workplace is dominated by emails and presentations. Even major design reviews often exist only as powerpoints and ephemeral presentations. While these communication channels are effective at the moment of creation, they are not great at leaving a permanent record or auditable paper trail. This informality of communication is one of the identified causes of the Mars Climate Orbiter crash in 1998 (Casani, 2010). Fortunately, the humble memo can come to our rescue.

Unlike other forms of communication, a good memo:

  • contains all relevant technical details.
  • can be cited, audited, and peer reviewed by members of your project or an external evaluator.
  • does not spend unnecessary time on motivation or background.
  • lives on in the project as referenceable and trackable engineering documentation.

When working on a technical project, you often need to communicate technical details with other members of your team. There are many mediums of communication available to you, such as emails, weekly meetings, slide decks, and conference papers. We often intuit the appropriate form of communication without explicitly thinking about why we selected that particular medium. Whether you know it or not, you are probably basing your decision on audience, purpose, and context.

  • Audience: The audience is composed of everyone who is likely to read your work. This can include your immediate coworkers, senior management, or even yourself in the future. Memos are written for an audience that is familiar with your work. Often, the audience is on the same “team” as you. 
  • Purpose: We all write for a reason. Proximally you may be writing just to appease a supervisor or advisor, but ultimately the fate of important projects and research depends on our ability to communicate. The purpose of a memo is to share technical details that may affect the activities and decisions of other members of your team. 
  • Context: Written communication does not exist in a vacuum. The findings of other researchers, the state of the project, and our own perspectives can affect our communications. The context of a memo is that you recently came to some technical conclusion. You may have just finished an experiment, or maybe you just learned something relevant from an external collaborator.

If you find yourself wanting to communicate with the above audience, purpose, and context, a memorandum (or memo for short) might be the technical communication tool you are looking for.

Although we primarily write memos for the benefit of our team, you will find that organizing your thoughts in the form of a memo also helps you communicate with your future self (perhaps while writing a paper), and with your advisor or other supervisor. Memos can also be easily shared with external collaborators to provide updates on project status.

With the advent of email and instant messaging, memos have fallen by the wayside on some technical projects. Today, scientists and engineers might not know the right time to write a memo. Here are some concrete indications to look out for.

You might benefit from a memo if:

  • you have technical content which you want to share now and which you may want to point to in the future.
  • you find yourself constantly referencing the same informal content (such as emails, notes, or a one-off plot in your computer’s file system).
  • you have recently performed an experiment or finished a design, but don’t know how to share the details with others.

 

 

2. How to write a memo

 

Most importantly, you should start writing the memo (Dahl, 2024). It is much easier to rearrange content or wordsmith later. Once you feel inspired to put your thoughts on paper you should not let formalisms get in the way. This is one of the great benefits of a memo; you can mold it to meet your needs.

With that said, a consistent structure will help you and your team members most easily find necessary information. I recommend that all memos include the following components:

  1. Header information that includes at a minimum: project name, memo author, memo date, and memo title
  2. Executive Summary
  3. Introduction/Motivation
  4. Technical Body Content
  5. Conclusion

This blog post itself is formatted this way, and you can use this blog as a template for your own memos.

 

A block diagram of the sections of a typical memo: header, introduction, body content, conclusion, and optional references.

Graphical summary of the structure of a typical memo.

 

Memos should primarily be a repository for your technical findings. The focus is not on the motivation or conclusion, although you should also write these sections while the technical findings are fresh in your mind. Memos are great places to put data tables and figures.

Remember that compared to a technical paper, a memo is primarily for internal sharing within your technical team or organization. There is no need to motivate the larger project because everyone on the team is already aware of this context. You can cut straight to the chase with only a minimal introduction that further motivates your work within the context of the project.

 

 

3. What to do once you have written a memo

 

Memos are meant to be shared, reviewed, and referenced. The first thing you should do is update the memo header information to reflect the current date and memo revision number (if applicable). Next, you should share it with those who would benefit from its content. On a small project it might be appropriate to share this memo with your entire team. On a larger project it might be best to pick and choose who to send it to.

Ideally, your project has a memo management system set up, in which case you should immediately place your memo in the memo management system and reference this when communicating with your team. If your project does not have a memo management system, consider setting one up using the methods outlined in Section 4 of this memo, or alternatively you can just attach your memo to an email for now.

When you share your memo, you should solicit action from your team. Are you looking for feedback? Do you need someone else to update their part of the project in response? Be clear with your intentions.

Finally, a memo should be a living document. If the context or your understanding evolves, you should update your memo to stay relevant. Send out the memo to relevant parties after updates. Additionally, you should increment the version number and version date so that any references to a previous version of your memo are still valid.

 

 

4. Managing your memos

 

Some projects provide infrastructure for the management of memos. If your project does not already have a technical memo series or technical memo repository, you can create one, or petition your project leadership to create one. Here at MIT we have access to several collaboration tools which could support a memo repository. Consider checking out our Wikis, Google Drive, or Dropbox options.

A memo management system does not have to be complicated, and it can even be part of your existing collaboration tools. If you have a shared wiki or Google drive, consider creating a dedicated top level folder for your technical memos. Be sure to give each memo a unique identifier. For example, I am in the AeroAstro Comm Lab (AACL) so I might give this blog post-cum-memo the identifier “AACL_How_to_write_a_memo_V1.0”. 

If your sharing tool already archives previous versions, you can replace old memo versions with new ones as they become available. If your system does not track old files (such as Google Drive) be sure to keep old versions of memos available on the system, perhaps in their own “Old Versions” subfolder of your memo directory.

There are a several benefits to providing a single repository for these memos:

  • It encourages team members to write memos
  • It provides a single place to look for memos
  • It makes sure memos stick around even after team members leave and emails get deleted from inboxes

 

 

5. Conclusion

 

Memos serve an important communication function within a technical team. Day-to-day communication needs are served by more familiar methods of communication like email and presentation slides, but memos can helpfully bridge the gap between informal emails and highly formal technical papers. Next time you forward that long email chain to the third collaborator in as many months, consider packaging it up into a nice neat memo; your collaborators and future you will be grateful.

After reading this blog post, you can now write your own memos. Use this blog post as a template to get started!

 

 

6. References

 

Yes, memos can have references, although they are not required. Your references could be to typical academic sources, but also can be internal communications or other memos.