Interliminality

Interliminality: A Practical Field Guide

Most people who run into this term discover it accidentally while trying to describe something they already knew how to do. They're looking for a label for the work that happens between formal processes. That work exists whether anyone named it or not. The word comes from the academic tradition around liminality — the anthropological concept of transitional spaces between structured states. Victor Turner wrote about it. People in organizational studies started using it to describe moments where formal structures break down and informal coordination takes over. Interliminality is the condition of operating in that gap. It's not mystical. It's the Tuesday afternoon when the project charter expired but the next one hasn't been approved, and someone has to make sure nothing falls through. It's the cross-departmental handoff where nobody owns the deliverable until someone decides to own it. These spaces are everywhere in any organization larger than about fifteen people.

The reason this concept matters practically is that most process frameworks completely ignore the in-between. You'll find detailed SOPs for Phase 1 and Phase 3, and then a two-sentence placeholder for Phase 2. The work doesn't vanish because the documentation does. It just becomes undocumented, unmeasured, and someone's problem at 4:45 PM on a Friday.

How to Work With Interliminality Instead of Around It

I learned this the hard way about four years ago. We had a product launch where the engineering handoff to operations was supposedly covered by a runbook. The runbook existed. It was also eight pages of assumptions written by someone who had left the company six months earlier. The actual transition — the three weeks where code was deployed but nobody was formally responsible for monitoring, triage, or customer communication — was a complete blank spot in every process document we had. A customer issue hit during that gap on a Thursday. Support had no escalation path. Engineering was on a different ticket queue. Operations hadn't been briefed. I spent twelve hours just figuring out who was supposed to be making decisions. That cost us approximately forty thousand dollars in downtime and a relationship with a key account that never fully recovered. The workaround I built afterward wasn't elegant. It was a simple matrix that mapped each handoff point in our workflow to a named interim owner — not the person who would own it permanently, but the person responsible for the gap period specifically. The interim owner had decision authority limited to that window. Nothing more, nothing less. We updated it quarterly. It took about twenty minutes a person to maintain.

Key Techniques for Managing Interliminal Spaces

First, you need to stop pretending handoffs are clean. They aren't. Every transition between teams, phases, or systems creates a liminal period where accountability is ambiguous. Name them. Map them. Put them on a single page that anyone can read in under thirty seconds. Second, assign interim ownership explicitly. This is the single most important step and the one most organizations skip. "Shared ownership" means no ownership. Pick one person per gap period. Give them a scope of authority. Document it in writing. Move on. Third, create a minimum viable protocol for the gap. You don't need a full SOP. You need three things: who to escalate to, what decisions they can make without checking back in, and what the exit criteria are for the next phase to begin accepting responsibility. That's it. Three bullets per handoff point. Four sentences maximum per point.

I've seen this reduce incident response time in transition periods from an average of six hours to under forty-five minutes across the teams I've worked with. The variation depends heavily on how messy your existing documentation is. If you're starting from zero documentation, expect the first implementation to take a full sprint. After that, maintenance is roughly two hours per quarter for a team of twenty.

Common Misunderstandings and Where This Approach Breaks

Interliminality is not a license for chronic process neglect. If your organization has constant interliminal gaps because formal processes are perpetually unfinished, naming the gaps doesn't solve the underlying problem. It just makes the dysfunction visible instead of invisible. That's valuable, but it's not a fix. The approach also fails in environments where power structures are too rigid for interim owners to have real authority. I worked once with a highly matrixed organization where the "interim owner" on paper had no actual budget or staffing control. The designation was decorative. Real decisions still required three levels of approval from people who weren't part of the process design. In cases like that, the formal matrix just becomes another layer of noise. Another limitation: this works best in environments where the liminal spaces are periodic and bounded. If your organization operates in a state of permanent liminality — which is actually the case for many startups and crisis-response teams — the concept loses its utility because there's no return to structured phases. You're not managing gaps between stable states. You're just surviving continuous ambiguity, and that requires a different toolkit entirely.

When Interliminality Doesn't Apply

Don't use this framework for routine operational work that already has clean ownership boundaries. If Team A hands off to Team B every Tuesday at 9 AM and the handoff has been working for three years without issues, adding an interliminality protocol is overhead that solves a problem you don't have. The framework is for the messy spots, not the smooth ones. The most useful application I've found is in organizations undergoing structural change — mergers, reorgs, new platform migrations — where existing handoff maps become invalid but the work continues regardless. During our last infrastructure migration, the interliminality matrix was the only thing that prevented three separate production incidents from escalating into full outages. Each migration phase had a defined gap where the old system was decommissioned but the new one wasn't yet fully operational. We had a different interim owner for each gap, each with a different escalation path. It wasn't pretty. It worked. If you're looking for a template to start with, the simplest version is a table with five columns: process phase, gap description, interim owner name, decision authority scope, and exit criteria. That's it. No software needed. A shared spreadsheet works. The value isn't in the tool — it's in the act of making the invisible work visible.

There's no downloadable framework package for this because the whole point is that you build it for your specific context. Generic templates fail here because the gaps are organization-specific. What works for a SaaS company's deployment handoff won't work for a manufacturing line's shift change. Build your own. It'll take one afternoon and it'll be better than anything you'd download.