peopleanalyst

guides · Capability guide · Qualitative Coding & Grounded Theory

Code First, Categorize Second

Open coding and grounded theory for turning unstructured material into a trustworthy taxonomy — instead of sorting it into one you already had

By Mike West

DraftJuly 6, 2026

Performance here means

In qualitative analysis, performance is a taxonomy that actually came from the data — categories with demonstrated properties and grounded membership, not a plausible-looking sort into buckets decided in advance.

This guide is for anyone sitting on a pile of unstructured material — interview transcripts, field notes, open-ended survey responses, a shelf of books — who needs to know what's actually in it, and who has felt the specific dishonesty of forcing that material into categories decided before anyone read it. The corpus this guide draws from settled that question in the 1960s and has kept refining the answer since: read first, code inductively, compare constantly, and let the categories emerge from what the data actually says — then, and only then, build the taxonomy. Skip the order and you don't get a faster analysis; you get a confident-looking one that quietly answers a question nobody asked. We move in the sequence the corpus itself insists on: generate codes with no category list in hand, write memos as you go so your thinking stays visible to you later, compare constantly instead of once at the end, build categories from the codes rather than sorting codes into categories, integrate toward a small number of core ideas, and — when your unit of analysis is a bounded case rather than a scatter of incidents — check the whole thing against a separate discipline built for exactly that.

The path

  1. Generate codes from the data itself, with no pre-existing category list in hand.
  2. Write analytic memos continuously — the thinking that turns a code into an idea.
  3. Compare constantly: incident to incident, code to code, category to category.
  4. Build categories from codes — properties, dimensions, and relationships, not a sorting bin.
  5. Integrate toward a small number of core categories, then toward theory.
  6. If your unit is a bounded case, cross-check with case-study rigor: triangulation, chain of evidence, analytic generalization.

Open Coding — Let the Data Name Itself

Foundations

Before any category list, there is the discipline of naming what's actually in front of you. Corbin & Strauss call this open coding: breaking data apart and asking, line by line or incident by incident, what is this, what does it represent — without importing a framework to sort it into. Saldaña's Coding Manual gives the mechanics: Initial Coding stays open and provisional, In Vivo Coding uses the source's own words as the code itself, Descriptive Coding names the topic in a short noun phrase. Charmaz's constructivist framing adds the caution that even these early codes are an interpretation the researcher is actively constructing, not a label the data hands you — which is precisely why starting from your own or someone else's pre-built category list contaminates the process at its first step.

Why it matters. A category list decided in advance doesn't just miss things — it actively mis-files them. Content that's actually about one phenomenon gets coded into an adjacent bucket because that's the bucket available, and the researcher never notices, because the mis-fit never surfaces as an error. Saldaña's own critique-of-coding section names the version of this every practitioner eventually hits: codes and themes don't "emerge" from data on their own — they are actively constructed by the coder, which means a coder working from a fixed list is constructing the mis-fit, not discovering a true category.

The myth: Classify first — you already know the categories that matter (retention, engagement, performance, whatever the standing taxonomy is), so just sort incoming material into them.

The reality: Corbin & Strauss are explicit that pre-existing literature and categories "should not be allowed to use you" — they're a sensitizing resource, consulted after initial codes exist, not a sorting bin applied before you've read the data. A category imposed early is the single most common way qualitative analysis quietly goes wrong.

The myth: Coding is basically the same as tagging — reduce the passage to whichever existing keyword fits closest.

The reality: Saldaña's whole manual argues coding is an interpretive, symbolic act — a code is a researcher's construction of what's significant, not a lookup against a controlled vocabulary. Reducing it to nearest-keyword-match discards the exact judgment that makes coding worth doing.

How to:

  • Read (or have the model read) the material with no category list available — generate codes from what's there, in language close to the source.
  • Prefer In Vivo or Descriptive codes early: the source's own words, or a short noun phrase naming the topic — not a category label borrowed from elsewhere.
  • Let a single source produce as many or as few codes as it substantively supports; don't pad to hit a quota or compress to fit one.
  • Ground every code in a specific quote or close paraphrase — an ungrounded code is a guess wearing a label.
  • Treat a code that resembles an existing taxonomy term as a coincidence to verify, not a confirmation to accept — check the actual source language before assuming the match is real.

Watch out for:

  • Believing categories "emerge" passively — they are constructed by the coder, which means a sloppy or rushed coding pass constructs sloppy categories, not neutral ones.
  • Letting a familiar taxonomy silently function as the code list even when you've told yourself you're coding openly — old categories are sticky.
  • Over-fitting a code to sound like a known label ("engagement") when the source's own language is doing something more specific — you lose precision converting it.

Grounded in: The Coding Manual for Qualitative Researchers — Johnny Saldaña; Basics of Qualitative Research — Juliet M. Corbin & Anselm Strauss; Constructing Grounded Theory — Kathy Charmaz

Analytic Memos — Thinking on the Page

Foundations

Coding and thinking are not the same act, and the corpus is unanimous that the second one needs its own artifact. Saldaña devotes a full chapter to analytic memos — reflective writing, prompted by specific questions, that runs concurrently with coding and is where codes actually turn into ideas. Corbin & Strauss treat memo-writing and diagramming as "not optional chores but integral parts of the analytic process" — the space where properties and dimensions of a concept get worked out, not just recorded. Charmaz places memo-writing as the crucial intermediate step between coding and writing up, the place where you "explore ideas... and build the theoretical density of the analysis."

Why it matters. Without memos, a coding pass produces a list of labels and no record of why any of them mattered. Weeks later — or when a second person needs to trust the categories — there's no trace of the reasoning that connected a code to a category, only the connection itself, asserted. Memos are the audit trail for judgment calls that are otherwise invisible.

The myth: Memos are optional notes-to-self — useful if you have time, skippable under deadline.

The reality: All three sources treat memoing as load-bearing, not supplementary. Corbin & Strauss go as far as calling it integral to the analytic process itself — skipping it doesn't just lose documentation, it degrades the analysis, because the memo is often where the actual thinking happens.

How to:

  • Write a memo the moment something about a code, a comparison, or a category strikes you — Saldaña's rule of thumb is immediacy, not end-of-session batching.
  • Use memos to work out a concept's properties and dimensions (Corbin & Strauss) — not just to restate what the code already says.
  • Let memos accumulate as the running record of how categories were built — when a category's origin is questioned later, the memo trail is the answer.

Watch out for:

  • Treating memos as a formality completed after the real analysis — the sources place memoing inside the analysis, not after it.
  • Writing memos that just re-describe the code — a memo earns its keep by asking why, what else, what's this connected to.

Grounded in: The Coding Manual for Qualitative Researchers — Johnny Saldaña; Basics of Qualitative Research — Juliet M. Corbin & Anselm Strauss; Constructing Grounded Theory — Kathy Charmaz

Constant Comparison & Theoretical Sampling

Foundations

Grounded theory's engine is comparison, run continuously rather than once at the end. Corbin & Strauss describe a constant interplay between data collection and analysis: emerging concepts guide what gets sampled next — theoretical sampling — rather than the sample being fixed up front. Charmaz names the same practice the "constant comparative method" and treats it as central to every stage, from comparing incident-to-incident early on, to comparing code-to-code, to eventually comparing category-to-category. Corbin & Strauss also supply the concrete tool: systematic questioning (who, what, when, where, why, how) paired with comparison, used to surface a concept's properties and dimensions rather than just its label.

Why it matters. A single pass through a fixed sample, compared only against itself, saturates nothing — you don't find out whether a category is real, or just an artifact of the particular sample you happened to read first, until you've deliberately gone looking for a case that might break it.

The myth: Once you have a plausible set of categories from your initial sample, the analysis is essentially done — additional material is just more of the same.

The reality: Theoretical sampling exists precisely because the opposite is true — the emerging analysis should actively direct what gets sampled next, seeking out data that could refine, extend, or challenge a category, not confirm it more times.

How to:

  • Compare each new incident or code against ones already coded — do they describe the same phenomenon, a variant of it, or something genuinely different?
  • Use theoretical sampling deliberately: once a category looks plausible, seek out material likely to test it, not just more material like what produced it.
  • Ask Corbin & Strauss's systematic questions of emerging concepts (who/what/when/where/why/how) to surface properties and dimensions, not just confirm the label fits.

Watch out for:

  • Mistaking "we've seen a lot of this" for "this category is saturated" — volume isn't the same as having actively tested the category against a case designed to challenge it.
  • Comparing only within a single source or session — cross-source comparison is where categories either hold up or fracture.

Grounded in: Basics of Qualitative Research — Juliet M. Corbin & Anselm Strauss; Constructing Grounded Theory — Kathy Charmaz

Axial Coding — From Codes to Categories

Foundations

Once open codes exist, the next move is relating them to each other — Corbin & Strauss's axial coding, which reassembles the data that open coding fractured, this time around categories with properties (general characteristics) and dimensions (where a specific instance falls along that property's range). Saldaña's second-cycle methods give the mechanics for getting there: code mapping and code landscaping (visually clustering codes to see what groups together), and Domain and Taxonomic Coding specifically for building an inventory or classification system bottom-up from the codes rather than top-down from a scheme. The discipline in both: a category is earned by showing which codes actually belong together and why, not asserted by giving a plausible-sounding cluster a name.

Why it matters. This is the exact step where a fixed taxonomy silently substitutes for real category-building — it's tempting to skip straight to "which of my existing buckets does this code belong in," which produces the mis-tagging and category errors that open coding was supposed to prevent in the first place. Axial coding is the discipline of building the bucket from the codes, not sorting codes into buckets that already exist.

The myth: Once you have your codes, the categorization step is just clerical — group similar-sounding codes together and name the group.

The reality: Corbin & Strauss insist a category needs demonstrated properties and dimensions, and a stated relationship among its members — two codes that sound similar can describe genuinely different phenomena (Saldaña's own example: a "theme" is not the same thing as a topic-driven list), and a real category has to survive that check.

The myth: A code that doesn't cleanly fit an emerging category should be forced in — every code needs a home.

The reality: Leaving a code unclustered, explicitly, is a legitimate outcome — it may belong to a category that hasn't saturated yet (more sampling needed) or it may simply not relate closely enough to anything else in the current sample. Forcing it in for tidiness manufactures a false category.

How to:

  • For each candidate category, state its properties (what characterizes members generally) and dimensions (where each specific code sits on that range) — not just a name.
  • Use code mapping/landscaping (Saldaña) to visually or explicitly cluster codes before naming categories, rather than naming first and fitting codes to the name after.
  • Let category names stay close to the language of the codes underneath them rather than reaching for an existing taxonomy term.
  • Leave genuinely unclustered codes unclustered — note them explicitly rather than forcing a fit.

Watch out for:

  • Two codes clustering because they use similar words while describing different underlying phenomena — check the grounding, not just the label.
  • A category built from codes that all come from a single source — that's evidence of one source's framing, not yet a corroborated pattern; say so.

Grounded in: Basics of Qualitative Research — Juliet M. Corbin & Anselm Strauss; The Coding Manual for Qualitative Researchers — Johnny Saldaña

Theoretical Coding — Toward Integration

Foundations

The final analytic move is integration: relating categories to each other around a central idea rather than leaving a flat list of unconnected buckets. Corbin & Strauss describe identifying a core category that the other major categories can be organized around, producing "a coherent, explanatory theoretical framework that is grounded in the data." Saldaña's second-cycle Grounded Theory methods — Focused, Axial, and Theoretical Coding — describe the same progression toward a central category and theory. Charmaz keeps the constructivist caveat running through this stage too: the resulting theory is an interpretive construction — useful, defensible, grounded — not an objective discovery to be mistaken for the only possible reading of the data.

Why it matters. A pile of well-built categories that never get related to each other is still just a pile — richer than a flat keyword tag, but not yet an account of what the corpus is actually saying. Integration is where the categories become a structure you can reason with, act on, and hand to someone else to check.

The myth: The goal of coding is always a single, formal, generalizable theory — anything short of that is an incomplete analysis.

The reality: Corbin & Strauss are explicit that these techniques are useful for other legitimate goals too — thick description, concept analysis, identifying themes — as long as the researcher is clear about which goal they're pursuing rather than treating theory-building as the only valid endpoint.

How to:

  • Look for a core category the other categories relate to — one that shows up repeatedly and has explanatory reach across the others.
  • State the relationships between categories explicitly (which drives which, which is a condition for which) rather than leaving them as a flat, unordered list.
  • Hold the result as a constructed, defensible account — open to revision with more data — not a final, objective classification.

Watch out for:

  • Forcing a core category that doesn't actually have reach across the data, just because integration is expected at this stage.
  • Presenting the emergent taxonomy as permanent — Charmaz's point that it's an interpretation means the next round of sampling can legitimately revise it.

Grounded in: Basics of Qualitative Research — Juliet M. Corbin & Anselm Strauss; The Coding Manual for Qualitative Researchers — Johnny Saldaña; Constructing Grounded Theory — Kathy Charmaz

Case-Based Rigor — When the Unit Is a Case, Not an Incident

Foundations

Grounded theory codes incidents; sometimes the unit you actually care about is a bounded case — a single book, a single organization, a single decision — and a different discipline applies. Yin's Case Study Research supplies it: a formal design (study questions, propositions, the unit of analysis, the logic linking data to propositions, criteria for interpreting findings), evaluated against four tests — construct validity, internal validity, external validity, reliability — and analyzed through triangulation of multiple evidence sources with a maintained chain of evidence. Yin's central reframe matters here specifically: case findings generalize to theory ("analytic generalization"), never to a population ("statistical generalization") — a distinction that keeps a small, rich case-based inventory honest about what it can and can't claim.

Why it matters. An emergent taxonomy built from open coding can look impressively rich and still be wrong about what it's entitled to claim — that a category showed up across cases proves something about the theory those cases inform, not that it will show up at the same rate in cases you haven't looked at. Conflating the two is exactly the kind of overclaim that undermines otherwise sound qualitative work.

The myth: You can't generalize from a handful of cases, so case-based findings are just anecdotes.

The reality: Yin's replication logic treats multiple cases the way multiple experiments are treated — selected to predict either similar results (literal replication) or contrasting results for predictable reasons (theoretical replication) — which is a legitimate, rigorous form of generalization to theory, distinct from (and not a substitute for) generalizing to a population.

How to:

  • Define the case and its boundaries explicitly before analyzing it — what's in scope, what isn't.
  • Triangulate: draw the same finding from more than one kind of evidence before trusting it.
  • Maintain a chain of evidence — an external reader should be able to trace a conclusion back to the specific data that supports it.
  • State generalization claims as analytic (to theory), never as statistical (to a population), when the underlying design is a small set of cases.

Watch out for:

  • Treating a single compelling case as if it settles a general claim — it supports or challenges a theoretical proposition, nothing more, until replicated.
  • Skipping the chain of evidence because the analysis "feels" sound — reliability lives in the trail, not the researcher's confidence.

Grounded in: Case Study Research: Design and Methods — Robert K. Yin

Sources

Was this useful?