Disclaimer: The views on this site are entirely my own and do not represent those of any employer, past or present. The case study described below was constructed for a graduate course: it is a hypothetical composite with all details invented or altered for teaching purposes. It does not describe any real organization, team, or individual, and no internal company data or information was used in the course work or in this post.
The final project was a case study of an organizational intervention — a constructed scenario in which several small teams were asked to adopt a shared working practice, some quickly, one not at all. My first instinct, trained by a decade in quality assurance, was to go find the one broken variable that explained the difference. The analytical method I ended up using — one I’d stumbled onto at a conference — doesn’t believe that variable exists, and arguing with it was most of the education.
When something works for one team and fails for another, almost everyone reaches for the same question: what’s the one thing that’s different? A root cause. It’s how we’re trained to think about failure — in engineering, in medicine, in a code review — find the broken part, replace it, done. The project quietly took that assumption away from me before I’d finished the literature review.
The setup
The teaching case was a set of small teams, all asked to adopt a shared practice for making their work visible. Some got there fast. One didn’t get there at all. The research question was simple to state and hard to answer honestly: what made the difference?
Early feedback on my first outline was blunt, and useful: my thesis wasn’t clear yet, and a tangent I’d added about conflict-management styles and inclusion in team decision-making was pulling the paper off its own topic. I’d tried to fit in everything I cared about — that’s the instinct of someone whose day job is arguing that overlooked voices matter — and the result was a paper that hadn’t decided what it was actually testing. The fix wasn’t cutting what I cared about; it was narrowing the question until it could be answered instead of gestured at.
The method that argued back
The conventional move here is regression: gather enough cases, code your variables, see which ones correlate with success. With a handful of teams and a handful of Boolean conditions, that’s not a dataset — it’s a small case comparison, and treating it like a regression problem would have manufactured false precision out of noise.
I didn’t find the alternative in the assignment brief. I found it at my first SIOP conference — Boston, 2023 — sitting in a symposium called Capturing Complexity: Using Coincidence Analysis to Evaluate Interventions. Susanne Tafvelin, Karina Nielsen, and Marta Roczniewska were showing how a configurational method explains why the same organizational intervention takes hold on some teams and stalls on others. Evaluating why the same intervention lands unevenly across teams is its own well-studied problem in the field, and here was a room bringing a newer causal method to it — the exact question my course work case had backed me into. One of their talk titles followed me out of the room — many simple roads to failure, only two complex ones to success — because it was my paper’s problem, stated more honestly than I’d managed to state it myself. I went back and rewrote the whole study around the method they were using: Coincidence Analysis (CNA), part of the Configurational Comparative Methods family alongside the better-known Qualitative Comparative Analysis. The premise is a genuine departure from how I’d been trained to think about defects:
- You study combinations, not variables in isolation. The question isn’t “does leadership support correlate with success,” it’s “which combination of conditions, together, is sufficient for success.”
- Causes can be asymmetric. What produces success and what produces failure don’t have to be mirror images of each other — the presence of a condition and its absence can each carry entirely different causal weight.
- Equifinality is the default assumption, not an exception. Multiple, non-overlapping combinations of conditions can each independently produce the same outcome. There doesn’t have to be one path.
- You minimize toward the simplest sufficient recipe, using Boolean algebra to strip out anything that isn’t doing causal work — the same discipline as reducing a bug report to its minimal reproducible case.
For the constructed case, I defined candidate conditions in neutral, structural terms — things like how present the person driving the change was, how consistent each team’s own leadership was, team size, and whether the team was co-located or distributed — measured at two points a few weeks apart. Boolean minimization surfaced three distinct combinations that were each independently sufficient for fast adoption in the scenario, and a separate, non-overlapping set of combinations sufficient for failure. No single condition, alone, explained either outcome. The clearest illustration of asymmetry in the model: an absent change sponsor was enough, by itself, to guarantee failure — but a present sponsor, by itself, was not enough to guarantee fast success. Presence prevented one outcome without producing the other. Absence and presence weren’t opposites; they were doing different jobs entirely.
The instinct I had to unlearn
Here’s the honest defect in my own thinking, not just my paper: my first pass tried to rank the conditions by importance, the way I’d rank risk factors in a test plan or read a regression coefficient. That’s a category error in configurational thinking. There is no “most important” condition sitting outside the combinations — a condition’s causal weight only exists inside the specific recipe it appears in. Asking “which variable matters most” is a question this method is built to refuse to answer, and it took me longer than I’d like to admit to stop asking it anyway.
What transfers
Root-cause analysis assumes a system has one broken part waiting to be found, and that assumption is so deep in how I work that I didn’t notice I was importing it into a paper explicitly designed to test it. Equifinality says otherwise: a system can arrive at the same success, or the same failure, through entirely different, non-reducible paths — and demanding a single explanation doesn’t make the system simpler, it just makes your explanation wrong in a confident way.
My throughline is negotiating for clarity, and this method sharpened what that actually means in messy human systems: clarity isn’t collapsing the answer down to one variable so it fits on a slide. It’s being precise about which combination you’re actually looking at, and honest that a different team, with a different sufficient recipe, might be looking at another one entirely.
Thanks for reading. Next time something works in one place and not another, it’s worth asking which question you’re really asking: which single thing broke — or which different recipe was missing?
Comments