Decompression channels

A definition I needed before I had a name for it

A decompression channel is a parallel technical project that uses different muscles than the main work and restores focus to the main work instead of competing for it. That is the whole definition. Every word in it is load-bearing.

Parallel: it runs alongside the main work, not after it. Technical: a hobby is also restorative but a hobby is not a decompression channel because the hands aren't learning anything that compounds. Different muscles: if it draws from exactly the same well as the main work, it doesn't decompress, it just fragments. Restores focus to the main work: this is the test. If after a session in the channel you come back sharper on the main thing, the channel works. If you come back duller, it doesn't.

A decompression channel is not a hobby (a hobby is non-technical), not a side hustle (a side hustle is commercial), and not a second main project (a second main project is a second main project). It is its own thing and the discipline is to keep it its own thing.

The five-minute story

I have ADD. The practical effect for me is not the cliché version. I can focus deeply. The problem is that focus runs on a refill cycle. If I push on QC patent strategy and MHG SBA paperwork for three days running, by day four my returns drop. By day five they're negative — I am sitting at the desk producing nothing and frustrated about producing nothing, which is its own tax.

The conventional advice is rest. Sleep more. Walk. I do those. They help. But for me they don't refill as fast as a different technical context does. There is something about loading a different codebase, reading a paper on a different topic, and writing one careful Python cell that does for my brain what eight hours of sleep doesn't quite do. I came to this slowly and embarrassed. The story I told myself for years was that the side projects were the problem. They weren't. The side projects without rails were the problem. A side project with rails is the refill.

This is the part where I have to be honest. Some operators don't need a decompression channel. They get full refill from sleep and exercise and conversations and they're done. If that's you, this lesson doesn't apply and you should not invent a need. Most of what gets posted online as "founder ADHD productivity" is people justifying distraction. I want to be clear that I'm not doing that. I'm describing a specific use of a parallel technical project for a specific neurological reason, and if your reason is different, the prescription is different.

Three ways it goes wrong

The channel becomes a second main project. This is the failure mode I watch for hardest. It happens when the channel starts to feel exciting and the main work starts to feel like obligation. Symptoms: you find yourself working on the channel during prime QC hours, you skip a QC deliverable because the channel "needs" something, you start to plan the channel's growth trajectory. Treatment: re-read the brief, in my case 12-Parley/project-brief.md, and remember that the cadence rail is one published notebook per month, max. Not minimum. Max.

The channel is too far from the main work and doesn't compound. Then it's a hobby, which is fine but doesn't earn its cycles. Lesson 2 in this track is the diagnostic for adjacency. If I were running QC and decided to learn ceramics on the weekends, ceramics would be a hobby. Lovely, but I shouldn't write a playbook chapter justifying it as portfolio strategy. Parley earns the cycles because the CV skills come back.

The channel has no forcing function and just sits. This is the third and quietest failure mode. The channel exists, the brief is written, the rails are clear, and nothing ships. The cure is a public forcing function. For Parley it's a published Kaggle notebook per month on a public profile. Public matters. A notebook in a private folder is a draft forever. A notebook with a URL has a date attached.

The diagnostic

After every session in the channel, ask one question. Am I more or less ready to work on the main thing right now? Write the answer down. Track it for four weeks.

If the answer is "more ready" most of the time, the channel works. Keep it.

If the answer is "less ready" most of the time, the channel is competing for cycles rather than refilling them. Kill it, or change something about it. Maybe the cadence is too aggressive. Maybe the topic isn't adjacent enough. Maybe you're working on it during the wrong hours of the day. The diagnostic doesn't tell you what to change. It tells you that something has to.

If the answer is "neutral" most of the time, the channel is a hobby. Hobbies are allowed, but they don't get to count as a research arm. Demote it in your own head, take the rails off, and let it be the thing you do with leftover time rather than a thing with a brief.

I am writing this lesson during the period before Parley has shipped its first notebook, so I don't yet have a month of diagnostic data on my own. That's honest. The diagnostic is borrowed from how I tracked TruPath OS in early 2026, where the answer was "less ready" something like four weeks running, which is part of why I killed it on March 29. The diagnostic worked. I just ignored it for too long.

Apply this

Open a note (paper or digital) and write the following three things down.

First, name your candidate channel. One sentence. Not the dream version. The version you would actually start this month.

Second, name what your candidate shares with your main work. Be specific. "CV pipeline" is not specific. "MediaPipe Holistic landmark extraction and transformer-on-sequence architectures" is specific. If you can't fill in the specific version, the adjacency may be imagined. Lesson 2 has the table format for this.

Third, name what your candidate does not share. Also specific. "Different end users" is not enough. "Different datasets, different evaluation protocols, different end-user scenarios" is enough. This is the part that gives you the rest.

Then commit to four weeks of tracking. After every session, write one sentence about whether you came back more or less ready to work on the main thing. At the end of week four, count.

If the count says keep, write the brief. The brief is in the next lesson sequence. If the count says kill, kill it without guilt and try a different candidate next quarter, or accept that you may not need a channel at all.