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 FBI1, 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 managers2. 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 true3, 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 plan4.
Firing is expensive, and it is important to document a repeated pattern of behavior5. 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 ⏎
Top comments (5)
My first mentor taught me the importance of documenting anything that could be important in the future. And that idea was reinforced by a lawyer who once told me that "in a court case, he who has the most documentation wins." That's stuck with me throughout my career.
For anything I don't want other people to see or that they wouldn't care to see, I write handwritten notes in a journal format. For things others might be interested in, I mostly write emails.
A key feature of my memos is that the dates must be beyond dispute (able to stand up in court if it ever came to that).
I consider my memo writing part of being a professional and cheap career insurance.
I've also heard, "Never write anything down you don't want read in court with a demeaning tone"
Maybe I should do a quick blurb on the importance of phone calls for delicate inquiries that might be awkward on paper, lol
Yes, that's very good advice.
Related to that, I had a professor summarize an ethics course by saying, "basically, don't do anything that you wouldn't want your mother to read on the front page of a national newspaper." I'll never forget that.
Can't info tracking systems, like issue systems, wikis with history, archived chat, and the like all fulfill the role of a memo? It won't capture off-line chats, but that's a small area to make-up for.
Those certainly have similar roles and overlap in a lot of ways. The principal places where I see differences are in two areas - the potentially adversarial workplace, and personal opinions you don't necessarily want to share.
All the things you mentioned are geared towards collaboration and sharing. They are typically public (inside the company public, anyhow), or at least accessible by your boss and/or your companies HR department and legal team.
In the case of the adversarial workplace, that means anything you write on a company system, and potentially anything you transmit over company wires (hello Firepower) is readable by an entity with more people, more money and more time than you. Why give them a leg up, if you don't have to?
In the case of the personal opinion you don't necessarily want to share, here's an example. I sit on a board that votes on who gets the employee of the month award at my regional line office. There's a defined procedure for submitting applications, and then the board votes on the pool of applicants and picks one.
An individual attended our meeting because they were very upset we had not selected their nominee. They had a lot to say, much of quite heated and not at all complimentary. We record meeting minutes in a wiki. I put a respectful, formal, high level overview of the complaint in the minutes. I did not minute a complete description of my impression (they weren't listening they were aggressive, they started repeating themselves louder and louder, etc.) You can bet I wrote down my impressions of what went on in my personal notebook, because I have no intention of catching any more grief for giving a dang award out.
In my view, wikis, issue trackers and chats are for actually getting project based coding work done, and keeping a record of how the work was done. The memo comes into play in that gray area, where non-project based, not necessarily coding work is done. They are useful in the political, human side of work that inevitably crops up in large organizations.
I will say that not all workplaces are adversarial, and it's possible to work somewhere that nothing ever comes up that you wouldn't share publicly. The benefits of personal memos are greatly lessened in those environments, however I contend they are still useful for preparing an end of the year summary of what you did. They are also a useful hedge against nice environments turning bad - it's often only a supervisor change/merger/team swap away.