Originally published at www.gunnargissel.com

Donald Trump has been in the news a lot lately. Especially concerning FBI investigations and memos. It seems like everyone in Washington is fighting with memos - Comey, McCabe, Nunes - the list goes on and on.

Clearly memos are important, but they also seem distant and removed from programming. You programmers reading this article aren't in a fight with the president or the FBI¹, so why should you care about memos?

Tools of Bureaucracy

You should care about memos because we work in a fundamentally bureaucratic society run by managers². It's likely that you work for an organization that is large enough to have its own bureaucracy - most programmers do.

If you aren't sure whether you work in a bureaucracy, here's a quick test:

• Is there a process for getting hired?
• Is here a process for leaving the company?
• Is there a process for getting fired?
• Is there a process for getting a promotion?
• Does your boss have a boss?

If you answered yes to more than two of them, congratulations! You are a programmer and part-time bureaucrat.

What is a Memo?

It's common for programmers to understand memos in Office Space terms. They are something supervisors do, and they really need TPS coversheets. While this is true³, it is a limiting conception of what a memo is.

Memo is short for "memorandum" which is from the Latin phrase memorandum est, "It must be remembered that..." A memo is some kind of documentation that jogs your memory. Of course, there are many different kinds memos in the modern world - policy memos, memorandum of understandings, meeting minutes, the list goes on.

From day-to-day programmer, the most important kind of memo is the memo-to-file. A memo-to-file is something you write after a conversation or an action that describes what happened. It isn't addressed to anyone, it's not trying to persuade anyone of anything. A memo-to-file simply records an event as you understood it at a certain point in time.

Put another way, a memo-to-file is a note with a date on it.

You should know that memos are being created about you. Your manager, coworkers, and stakeholders are all probably writing things down, about stuff you did!

Hold off on the panic attack. They probably aren't writing down bad things - the vast majority of memos are neutral. "Met with so-and-so, discussed project. Committed to reviewing Jira issues"

For the most part, these memos go unused. Written once, read never. They do, however, come in handy in a variety of situations, usually after something has gone wrong.

Concrete Examples

On the Road to a Job Hunt

Let's start right off the bat with the grim example. Your boss is not happy with your performance and thinks they may have to fire you. In bureaucratic organizations, there is a process connected with firing, and it typically starts with a performance improvement plan⁴.

Firing is expensive, and it is important to document a repeated pattern of behavior⁵. Because firing is expensive, many bureaucratic organizations recommend supervisors take actions to head off people getting even a performance improvement plan - mentoring meetings, feedback meetings, checkins, etc.

Supervisors document these informal actions with memos-to-file. "Counseled so-and-so that they need to inform stakeholders of a blown deadline before said deadline is blown." These notes build a case of a repeated pattern of behavior that supports the action they take down the road.

Reviewing What Went Wrong

A less grim occurrence is the post mortem, or after action report. A system failed, and the team wants to figure out what happened and why it failed. Keeping notes about who asked you to do what can be helpful when establishing a timeline. For example, "Chief stakeholder Jane wanted the big feature rolled out next week, so she asked me to do an unscheduled deploy on Friday."

They can also help establish mindset before a system failure - the best post mortems assume everyone is trying their professional best, so knowing why a person thought the action that caused the failure was a good idea is helpful, and memos-to-file can be a useful resource to determine the "why's".

Day-to-Day Disagreements

The most common (and least grim) place that memos-to-file can help a programmer out, is mild disagreement with stakeholders about feature requests and bug fixes. It's common to walk out of a meeting feeling like you have a shared understanding about what to do next, only to find a week or a month later that you did not.

A contemporaneous memo of what you understood as you left the meeting is useful, because it can help you figure out where the disagreement started. They can be useful in figuring out who was 'wrong' but this is of limited usefulness when everyone is on the same team working towards shared goals in a supportive fashion.

In the event that you are working on a contentious team, this type of memo can be useful protection - "See, I did what they said! It's not my fault they changed their mind." Hopefully you are not on a team like this, but even the best teams sometimes veer unexpectedly towards blame and contention.

End of the Year Writeups

Everyone with a boss must, from time to time, say what they did and why it was good for the company. This often comes in the form of an annual performance review with a short write up about what you did and a quick meeting with your boss. These meetings have a high impact on your promotion and bonus potential. It is in your best interest to have a good summary of your accomplishments at hand.

A good collection of memos documenting the people you talked to and the actions you took, as well as the motivations and results, makes quick work of writing end of the year accomplishments.

Be Prepared

Write memos, not with the intention of needing them, but with the knowledge that you might need them as circumstances change. "Be Prepared" is an excellent motto, whether you are a scout, a backup-conscientious admin or a programmer-bureaucrat. What is a happy situation today, may turn tomorrow. Memos-to-file can help bail you out when things turn sour.

Happy writing!

If you liked this and want great articles on programming and leadership delivered to your inbox monthly, sign up for my newsletter!

Credits

Thank you Kiran Foster for the picture of a filing cabinet
Thank you mcfarlandmo for the picture of many filing cabinets
Thank you Florian Hufsky for the picture of a notebook
Thank you Orin Zebest for the picture of a paper cliff
Thank you No More Plains for the picture of a printer

Footnotes

1: Unless you are in a fight with the president and/or the FBI - in that case, I'm interested and want to hear more; dish! ⏎
2: Say what you will about James Burnham and The Managerial Revolution, I think there is something to the description of society there ⏎
3: Not really. ⏎
4: Your organization may call these something else, but the idea is a last chance plan before they show you the door ⏎
5: For liability and unemployment insurance reasons both ⏎