Protect Yourself like the FBI — with Memos
Tags: career, productivity, leadership, workplace
Published: 2018-03-28 03:59:17

---
title: Protect Yourself like the FBI — with Memos
published: true
description: FBI Special Agents have long been protecting themselves by writing memos.  Learn how to use the same techniques to protect yourself as a programmer
tags: career, productivity, leadership, workplace
cover_image: https://thepracticaldev.s3.amazonaws.com/i/d8p6p89znmaskm9s8udm.jpg
canonical_url: https://www.gunnargissel.com/protect-yourself-like-the-fbi--with-memos.html
---

_Originally published at [www.gunnargissel.com](https://www.gunnargissel.com/protect-yourself-like-the-fbi--with-memos.html)_

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](https://www.theatlantic.com/politics/archive/2017/05/congress-reacts-to-comey-memo-report/526947/), [McCabe](https://www.politico.com/story/2018/03/17/mccabe-memo-trump-fbi-469097), [Nunes](https://www.theatlantic.com/politics/archive/2018/02/read-the-full-text-of-the-nunes-memo/552191/) - [the list goes on and on](https://news.google.com/news/search/section/q/trump%20memo/trump%20memo?hl=en&gl=US&ned=us).

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<sup id="fnr-footnotes-1">[1](#fn-footnotes-1)</sup>, so why should you care about memos?

Tools of Bureaucracy
------------------------

<img src="https://i.imgur.com/vNIG4jwm.jpg" alt="Printing out memos" title="A printer with stack of memos on it"/>

You should care about memos because we work in a fundamentally bureaucratic society run by managers<sup id="fnr-footnotes-2">[2](#fn-footnotes-2)</sup>.  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?
-------------------

<img src="https://i.imgur.com/rkYnp3Sm.jpg" alt="Write things in a notebook" title="Notebooks, for writing memos"/>

It's common for programmers to understand memos in [Office Space](https://en.wikipedia.org/wiki/Office_Space) terms.  They are something supervisors do, and they really need TPS coversheets.  While this is true<sup id="fnr-footnotes-3">[3](#fn-footnotes-3)</sup>, 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](http://www.weeklystandard.com/a-brief-history-of-the-memo-to-the-file/article/2008086).  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
--------------------

<img src="https://i.imgur.com/LOc9JUfm.jpg" alt="Filing cabinets full of memos" title="Filing cabinets full of memos"/>

###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<sup id="fnr-footnotes-4">[4](#fn-footnotes-4)</sup>.  

Firing is expensive, and it is important to document a repeated pattern of behavior<sup id="fnr-footnotes-5">[5](#fn-footnotes-5)</sup>.  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
------------------

<img src="https://i.imgur.com/Yw9ncFkm.jpg" alt="A hall of filing cabinets" title="A hall of filling cabinets"/>

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!](https://www.gunnargissel.com/pages/email-signup-1.html)__

Credits
----------

_Thank you [Kiran Foster](https://www.flickr.com/photos/rueful/) for the [picture of a filing cabinet](https://flic.kr/p/a1VxYw)_
_Thank you [mcfarlandmo](https://www.flickr.com/photos/mcfarlandmo/) for the [picture of many filing cabinets](https://flic.kr/p/5ZrohQ)_
_Thank you [Florian Hufsky](https://www.flickr.com/photos/1000points/) for the [picture of a notebook](https://flic.kr/p/5AHHMk)_
_Thank you [Orin Zebest](https://www.flickr.com/photos/orinrobertjohn/) for the [picture of a paper cliff](https://flic.kr/p/4knuKB)_
_Thank you [No More Plains](https://www.flickr.com/photos/skolbwilliams/) for the [picture of a printer](https://flic.kr/p/dciy51)_


Footnotes
------------

<a id="fn-footnotes-1">1: </a> Unless you are in a fight with the president and/or the FBI - in that case, I'm interested and want to hear more; <a href="mailto:gunnar@gunnargissel.com">dish!</a> [⏎](#fnr-footnotes-1)
<a id="fn-footnotes-2">2: </a> [Say what you will](https://ebooks.adelaide.edu.au/o/orwell/george/james_burnham/) about [James Burnham](https://en.wikipedia.org/wiki/James_Burnham) and _[The Managerial Revolution](https://www.goodreads.com/book/show/1700735.The_Managerial_Revolution)_, I think there is something to the description of society there [⏎](#fnr-footnotes-2)
<a id="fn-footnotes-3">3: </a>Not really. [⏎](#fnr-footnotes-3)
<a id="fn-footnotes-4">4: </a>Your organization may call these something else, but the idea is a last chance plan before they show you the door [⏎](#fnr-footnotes-4)
<a id="fn-footnotes-5">5: </a>For liability and unemployment insurance reasons both [⏎](#fnr-footnotes-5)