Skip to main content
GASSTUDI
Systems & Scale5 min read

The Hidden Tax of Context Switching (And How I'm Removing It)

Juggling multiple ventures without a persistent context system quietly costs more than the switching itself. Here's what building better documentation habits fixed.

Nic DeMore

Nic DeMore

Founder, GAS Studio · August 9, 2026

Person writing notes at a desk with an open notebook and coffee

Context switching gets talked about as if the cost is the switch itself, the few minutes it takes to close one tab and open another. That's not where the real cost lives. The real cost is everything that happens after the switch, when you're trying to remember what you were actually thinking the last time you touched this, and you don't have it written down anywhere reliable.

I felt this most acutely moving between ventures that don't share an obvious rhythm. A Margle client strategy session in the morning, a Giveable brand partnership question in the afternoon, an FOA content review in the evening. Each one requires a genuinely different mode of thinking. Without something to reload the specific state of where each venture actually stood, every switch meant reconstructing that state from memory, and memory is a bad, lossy place to store operational context.

Why this tax is worse than it looks

The obvious cost is time, the minutes spent remembering instead of doing. The less obvious cost is quality. Decisions made from a half-reconstructed memory of where things stand are worse decisions than ones made from accurate, current context. You forget a constraint that mattered. You repeat a question that was already answered. You miss that something is actually further along than you remembered, and you waste effort re-deciding something that was settled.

Across a single project, this is a minor annoyance. Across a portfolio of ventures each with their own state, it becomes a structural drag on decision quality, one that's easy to miss because no single instance of it feels like a big deal.

What actually fixed it

The fix wasn't a productivity trick. It was building the habit, and the underlying system, of writing down state before switching away from something, consistently enough that picking it back up doesn't require memory at all. A short, current record of where each venture stands, what the open questions are, and what the next real step is, kept up to date as a discipline rather than an occasional cleanup task.

The habit had to come before the tooling mattered. I could have the best documentation system in the world and it would still fail if I didn't actually update it every time something changed. The tooling just makes the habit easier to sustain, it doesn't replace the decision to build the habit in the first place.

Once that existed, switching between ventures stopped requiring reconstruction. I could close out a Giveable session, open an FOA session, and pick up exactly where I'd left each one, because the state was written down accurately instead of stored in a memory that degrades every time something else competes for attention.

The compounding effect

The interesting part isn't that any single switch got faster. It's that the quality of decisions across all the ventures went up simultaneously, because none of them were being run on stale or reconstructed context anymore. That's a different kind of win than a time-saved metric. It's closer to a floor being raised under everything I do across the portfolio at once.

What I'd tell someone else running multiple things

If you're feeling scattered across more than one project, the switching itself probably isn't your real problem. Your real problem is probably that nothing reliably holds the state of each thing between the times you touch it. Fix that first. The switching gets a lot less expensive once you're not rebuilding memory every single time you come back to something.

The habit is harder to build than the system

I want to be honest that the system alone didn't fix this. I built a place to record state before I actually committed to using it consistently, and for a stretch it sat mostly empty because updating it felt like an extra step on top of an already full day. The fix only started working once I treated the update itself as part of finishing a work session, not an optional extra. Closing out a session on any venture now includes a short note on where things stand and what's next, the same way I'd never leave a kitchen without wiping down the counter. It's a small habit, but it's the actual mechanism that makes the system worth anything.

Where AI-assisted workflows fit into this

Once the habit was in place, AI-assisted tools became genuinely useful for this specific problem in a way they weren't before. A system that can read the current state of a venture and summarize it back to me in a few seconds removes even the small remaining friction of skimming my own notes to reload context. That's a modest convenience on its own, but it compounds across a dozen switches a week, and it's only possible because there's accurate, current state for the system to read in the first place. Automation without accurate underlying context just automates confusion faster.

The mistake I keep watching for

The failure mode I actively guard against now is letting the recorded state drift out of sync with reality again, the exact problem I built this to solve. It's an easy trap: update the source of truth diligently for a few weeks, then skip it during a busy stretch, and quietly slide back into reconstructing memory instead of reading a record. I don't think this is a problem that gets solved once. It's a discipline that has to be renewed continuously, and noticing the early signs of drift, a status that feels slightly stale, a next step that no longer matches what actually happened, is the signal to tighten the habit back up before the old tax creeps back in.

Share this entry