Why run a parallel research arm

Slide deck (PDF) ↗

Most operators who try to run a side technical project alongside a real company have the side project cannibalize the real one inside three months. I've watched it happen to friends. I almost watched it happen to me with TruPath OS, which is the postmortem in Field Note 0001. So writing a chapter that says "run a parallel research arm" needs a defense.

Here is the defense. A parallel research arm can be structured so it doesn't compete with the main work. The conditions are narrow and most operators won't qualify. When the conditions hold, the arm pays back across the portfolio for years. When they don't, it's the TruPath OS mistake in slower motion.

Parley is my worked example. It started on 2026-04-22 as a research-only sign-language computer-vision project, tracked in 12-Parley/ and scoped in 12-Parley/project-brief.md. The premise was specific. One published Kaggle notebook per month, max. Weekends and evenings only. Pauses without guilt on any QC [URGENT] item. No leaderboard chasing. Not a product. The brief makes the rails explicit because the brief is what I read on month four when I'm tempted to break them.

This chapter is about why the arm exists at all. The lessons that follow are about how to keep one from drifting.

Two compounding reasons

Parley does two jobs at once. Either one alone would not justify the cycles. Together they do.

The first job is a decompression channel. I have ADD, and the practical effect is that my focus on the main work runs on a refill cycle. Pushing on QC patent strategy or MHG SBA paperwork for three days in a row leaves me less ready to push on day four, not more. A parallel technical project that uses adjacent muscles but a different problem domain restores the refill faster than rest does. Sleep helps. Walks help. A research notebook on landmark-only classification ceilings, where I'm reading three papers and writing one Python cell at a time, helps more. Lesson 1 in this track is the full diagnostic for whether your candidate channel actually qualifies as decompression or is just another main project in disguise.

The second job is that sign-language computer vision is a legitimate underserved research area. Google's ASL Signs Kaggle competition in 2023 produced a flurry of public work — the 1st-place transformer solution from Hoyeol Sohn, the 2nd-place "What Hands Say" writeup, Starner's PopSign ASL v1.0 paper at NeurIPS 2023. Then the public research cadence slowed. Four specific questions, written into the Parley repo AGENTS.md §2, are open enough that an honest applied notebook can move them: the relative contribution of hand-shape vs temporal signal (FineHand arXiv:2003.08753 vs Temporal Accumulative Features arXiv:2004.01225), the classification ceiling when you discard pixels and keep only MediaPipe landmarks (Moryossef et al. arXiv:2104.10166 puts a number on it), signer-dialect robustness under leave-one-signer-out evaluation (the FluentSigners-50 benchmark and the C²SLR signer-removal work arXiv:2212.13023), and the failure modes when a model trained on isolated signs meets continuous co-articulated video (Albanie's BSL-1K arXiv:2007.12131 shows the cliff). Those are real questions. I am not pretending the field needs another medal-chaser. I am pointing at four gaps a careful operator with weekends can poke at.

The two jobs compound because the same hours produce both outputs. The notebook I publish to refill my focus is also the notebook that builds a small public reputation for honest applied work, which is a portfolio signal when I talk to QC investors, to ACL, to a future CV hire.

Skill-transfer adjacency math

The reason this works at all is that sign-language computer vision shares substrate with QC's cornhole vision pipeline. Not all of it. Enough.

What transfers: pose estimation libraries, landmark extraction pipelines (keypoint-tensor shapes and per-frame normalization patterns port cleanly across domains), temporal model architectures common to sequence classification, and the discipline of evaluating on identity-independent splits rather than random shuffles. These are category-level tools that any CV venture working with human-movement data eventually touches. Every hour I spend on Parley sharpens a tool the main work will eventually use.

What does not transfer: the datasets are completely different (250 ASL signs vs four cornhole throw outcomes), the evaluation protocols are only partly shared (top-k accuracy yes, signer-independence as a concept yes, but the specific benchmark splits do not move), and the end-user scenarios share nothing (a Deaf-hearing conversation is not a cornhole match). That is the rest part. My brain treats sign-language CV as a different problem and gets the decompression benefit. My hands learn tools that come back as QC engineering capacity.

The math I run on this is loose but honest. If I spend six hours on a Parley notebook and four of those hours sharpen a tool QC will use within twelve months, the effective cost to QC is two hours. Two hours per month is the rounding error on any week where I sleep an extra forty-five minutes. When I run the math the other direction, asking what it would take to invent these same skills inside QC at the pace QC is moving, the answer is more hours, not fewer, because QC's dataset isn't ready yet for the techniques that the sign-language community already has labeled benchmarks for. Parley gets me the rep on the techniques first, against datasets that already exist, and QC inherits the engineer who has done them.

Lesson 2 in this track has the substrate table in detail and the diagnostic for whether your candidate adjacency is real or imagined. The fastest way to fool yourself is to claim adjacency on one dimension that doesn't matter while ignoring three that do.

What you give up

I want to be honest about the cost because most playbook chapters that recommend a thing skip this part.

You give up cycles. Maybe four to eight focused hours a month if you hold the cadence to one notebook. That is not nothing. Those hours could go to QC fundraising deck iteration or MHG site-visit prep or just to more sleep.

You give up some focus during low-energy weeks. There are weeks where the QC patent draft needs a third pass and the MHG SBA package needs a fourth, and the right answer is to skip the Parley notebook that month and write a one-line entry in decisions.md saying so. That is the rail. But the temptation in a low-energy week is to do the easier thing, and Parley is often the easier thing because the stakes are lower. The discipline is to do the harder thing and skip the easier one.

You give up the ability to call yourself single-threaded. When an investor asks what you're working on, the honest answer now includes a research project. Some investors hear "founder is distractible." Some hear "founder builds compounding capacity in the white space." You have to be ready for the first reading and have the second one earned.

You give up the option to start a different parallel project later without breaking a precedent. If I add Parley and then six months later add a third side track because something catches my eye, every rail I wrote into 12-Parley/project-brief.md becomes negotiable. The discipline of having exactly one arm is part of what makes the arm not be a distraction. Two arms is three things competing for cycles, which is two startups and two arms, which is four. Curtis runs QC ops with me and gives me real grief when I sound like I'm flirting with a second side project, which is the corrective I need.

When not to start one

Three conditions mean don't do this. Lesson 4 in this track expands each one, but the short list is worth stating here.

If the main work is in launch crunch, don't start an arm. Launch crunch is the wrong time to add a second context. Finish the launch. Run the arm in the next quieter quarter.

If the underlying intent is commercial, meaning you secretly hope this becomes a product or a side hustle, don't start an arm. The Parley brief is explicit that it is not a product, and Phase 0-3 is research only. The minute the secret hope is "this could be a company," the rails break. Either start a company on purpose or keep the arm research-only. Pretending will degrade both.

If the candidate topic is just a different itch rather than an adjacent topic, don't start an arm. A side project in iOS app development while running a hardware company is not adjacency, it is a hobby. Hobbies are fine. Hobbies don't get a playbook chapter justifying the cycles. The arm earns its existence by compounding into the main work.

Closing

A parallel research arm is an edge when the conditions hold. It is a slow-motion version of the TruPath OS mistake when they don't. The two compounding jobs (decompression and underserved research) plus skill-transfer adjacency plus honest scope rails are what separates the first case from the second.

The rest of this track is the operating system for that. Lessons 1 and 2 cover the two diagnostics — is your candidate channel actually decompression, and is your candidate topic actually adjacent. Lesson 3 covers the discipline of keeping the arm from becoming a product. Lesson 4 covers the three "don't start one" conditions in detail. Lessons 5 through 7 cover the scope rails, the monthly check-in checklist, and Kaggle as the forcing function.

Parley is twelve months old when I write this. Phase 0 ships its first notebook in the next available weekend. The check is whether it has earned its cycles a year from now. If it has, this chapter generalizes. If it hasn't, this chapter becomes the next postmortem.