Three days into coding a large batch of open-ended responses, it's genuinely easy to lose track of why a specific call was made - why a code got split into two more specific ones on day two, why one particular response was coded a certain way despite looking, on the surface, a lot like others that were coded differently. Memoing is the practice of writing these decisions down as they happen, in the moment, not primarily for anyone else's benefit - though it helps there too - but so the analyst themselves stays consistent with their own reasoning from three days ago rather than unconsciously drifting into a slightly different, unwritten standard by the end of a long coding pass.
Table of Contents¶
- Why Coding Drifts Without Memoing
- What a Useful Memo Actually Contains
- The Difference Between a Memo and a Code Definition
- When to Write One
- Memos as an Audit Trail Later
- A Worked Example
- FAQ
Why Coding Drifts Without Memoing¶
Coding a long dataset in a single sitting or across several sessions inevitably involves a long series of small, in-the-moment judgment calls - a response that's genuinely ambiguous between two codes, a decision to split a code that turned out to be a grab-bag, a borderline case resolved one way that will come up again in slightly different form later. Without a written record, the reasoning behind each of these calls lives only in the analyst's memory, which degrades and shifts over the course of a project the same way any memory does - a borderline case resolved a certain way on day one can easily get resolved differently, without the analyst even noticing the inconsistency, when a similar case comes up again on day four. Memoing exists specifically to interrupt this quiet, unintentional drift by making the reasoning explicit and referable rather than trusting it to persist accurately in memory alone.
What a Useful Memo Actually Contains¶
A useful analytic memo is short - often just a few sentences - and captures a specific decision along with the reasoning behind it, not a general summary of what was coded that day. "Response #47 discusses both onboarding confusion and a pricing complaint; coded primarily as onboarding since that was the response's opening and dominant point, with pricing mentioned only in passing" is a genuinely useful memo - specific, tied to an identifiable case, and reusable the next time a similarly mixed response comes up. "Coded several more onboarding-related responses today" is not a useful memo in the same sense - it records that work happened without capturing any of the reasoning a future version of the same analyst, or a different analyst entirely, could actually learn from or check consistency against.
The Difference Between a Memo and a Code Definition¶
A memo and a codebook entry serve related but distinct purposes, covered from the codebook side in our guide on what makes a good qualitative codebook. A codebook entry states the general, stable rule for a code - what belongs, what doesn't, going forward. A memo captures the specific reasoning behind an individual judgment call at the moment it happened, including cases that don't cleanly resolve into a simple, generalizable rule. When a memo reveals a pattern - the same kind of ambiguous case keeps coming up and getting resolved the same way - that's a strong signal the codebook itself needs an explicit rule added, promoting a memo's ad hoc reasoning into a permanent, generalizable part of the codebook rather than leaving it to be independently rediscovered and re-reasoned through every time a similar case appears.
When to Write One¶
Not every coding decision needs its own memo - that would slow coding to a crawl and bury the genuinely important entries in noise. A memo is worth writing specifically when a decision was genuinely non-obvious (a response that could plausibly have gone more than one way), when a decision represents a new precedent that future similar cases should probably follow, or when something about the data itself surprised the analyst in a way worth flagging for later - a theme showing up in a context nobody expected, or a pattern that seems to contradict an earlier finding. A rough, practical rule: if resolving a specific case took more than a few seconds of genuine thought, it's usually worth the additional thirty seconds to write down why.
Memos as an Audit Trail Later¶
Beyond keeping an individual analyst consistent with themselves during active coding, a collection of memos becomes a genuinely valuable audit trail once analysis is finished and findings are being written up or defended. A stakeholder or reviewer asking "why was this specific response coded this way" can be answered with an actual documented reason rather than a reconstructed, after-the-fact justification the analyst has to invent from memory - a meaningfully more credible position to be in, particularly for any finding that ends up being scrutinized or challenged later. This also matters for a second coder joining a project partway through, or a re-analysis conducted months later by someone who wasn't involved the first time - memos give both a real window into the original reasoning that a finished codebook and clean final dataset, on their own, don't preserve.
A Worked Example¶
A researcher coding 200 employee survey responses about workplace culture writes a memo on day one: "Response #12 mentions feeling 'burned out' but frames it as a personal circumstance (recent move, family issue) rather than a workplace-caused complaint; coded as Personal Context rather than Workload, since the respondent explicitly separates the cause from work itself." On day three, a similar case appears - a response mentioning exhaustion with an ambiguous cause - and the researcher checks back through their memos, finds the day-one entry, and applies the same reasoning consistently rather than making an independent, possibly different call based on that day's mood or fatigue. By the end of coding, a recurring pattern across several memos - several responses distinguishing personal-life stress from work-caused stress in a way the original codebook hadn't explicitly anticipated - prompts the researcher to add an explicit rule to the codebook itself, turning a repeated ad hoc judgment call into a stable, documented standard for the rest of the project and any future wave of the same survey.
FAQ¶
How long should a memo be?
Usually just a few sentences - long enough to capture the specific case and the reasoning behind the decision, short enough that writing one doesn't meaningfully slow down the coding process itself.
Should memos be written for every response coded?
No - reserve them for genuinely non-obvious decisions, new precedents, or surprising patterns. Writing a memo for every routine, obvious coding decision creates noise that buries the genuinely useful entries.
What's the difference between a memo and just editing the codebook directly?
A memo captures reasoning at the moment of a specific decision, often before it's clear whether the case represents a one-off or a genuine pattern. Once a pattern across several memos becomes clear, that's the signal to formalize it as an actual codebook rule rather than leaving it scattered across individual memo entries.
Is memoing only relevant for large, long-running qualitative projects?
It's most valuable for larger or longer projects where memory naturally degrades over time, but even a short project benefits from a handful of memos on the genuinely ambiguous cases - the practice scales down easily, unlike some more formal qualitative research procedures.
For related guidance, see What Makes a Good Qualitative Codebook and Reflexivity in Qualitative Analysis: Why Your Own Perspective Is Part of the Data.