How to run one without it cannibalizing the startup

Slide deck (PDF) ↗

Chapter 1 made the case for when a parallel research arm is worth running at all. This chapter is about how to run one so it doesn't quietly become the work it was supposed to support. The structural claim is simple: four discipline levers — scope rails, monthly cadence, a public publishing loop, and decision logs, with a written set of kill criteria behind them. Each lever is cheap on its own. Together they're what keeps the arm from drifting into a third startup or dying in week six.

Scope rails

Before the arm exists in any real sense, it needs a list of things it will not become. Written, dated, in the project doc. Not "we're keeping it small" — a specific enumeration of the shapes the project is allowed to refuse.

Parley's scope-rails block, copied from 12-Parley/project-brief.md:

**NOT in scope:**

- Real-time production system

- Mobile app

- Commercial licensing discussions

- Dataset marketplace participation

- Replacing any QC priority

Each line is there because at some point I would be tempted by it. A clean notebook with strong results is a magnet for "what if we…" thoughts, and most of those thoughts are how a research arm becomes a startup. The rails aren't there for the version of me reading the project brief on day one. They're there for the version of me three months in who has just shipped something that worked.

The fifth item on Parley's list, "replacing any QC priority," is the meta-rail. It's how the other four get enforced when a tempting opportunity slips past them. If pursuing the opportunity would push a QC item, the answer is no, full stop, regardless of how interesting the opportunity is. That single line carries more enforcement weight than the other four combined, because it's the one that has teeth when the temptation gets real.

Lesson 5 walks the full discipline of writing your own scope rails, and the failure modes for each of the four Parley items.

Monthly cadence

The default cadence for a side project is the one the founder feels guilty about. Usually that means weekly check-ins that erode into daily ones. None of those rhythms work for a research arm running alongside a startup.

Weekly is an overhead spiral. Every week becomes a tiny launch, with a writeup pass and a publish pass and a "what did I learn" pass, and within a month the meta-work outweighs the actual work. Quarterly has the opposite problem: no forcing function. Week 6 of a 13-week cycle is when the project quietly dies, because nothing is due and the main work is loud.

Monthly is the only cadence that survives the main work's variance. One notebook per month, full stop. A QC sprint that eats three weekends is fine; the month carries one notebook and the arm absorbs the disruption without scaling its commitment up or down.

The unit also matches the granularity of the work. A research notebook (a real one, with error bars and failure modes documented) is roughly a month of evenings and weekends. Trying to do it in a week produces something thin enough to embarrass the arm; trying to spread it over a quarter loses the thread. Monthly is the unit because the work is the unit. Lesson 6 covers the mechanics: what the monthly check-in looks like, what counts as "shipped," what to do when a month gets skipped.

A public publishing loop

The version of this work that stays in a private repo dies. I know this from earlier projects; there's nothing forcing rigor, so rigor erodes, and the project becomes a journal nobody reads.

Public publishing is the cheapest deadline mechanism available. For Parley the platform is Kaggle: every notebook ships to a public profile, gets indexed in search, and sits under comments and the platform's discovery loops. The deadline isn't a date I set. It's the asymmetry between a notebook that's good enough to publish under my name and one that isn't. That gap does the editorial work that a manager would otherwise do.

The publicness also forces a quality of writing that private notes don't. A private notebook can have hand-wavy sections and undefined terms; a public one can't, because someone reading it cold will notice. That pressure compounds. Every published notebook makes the next one a little easier to write at the same standard, because you've internalized what "publishable" feels like.

The platform matters less than the publicness. arXiv, GitHub with a README that's actually written, a Substack with a real audience — any of these works. What doesn't work is a private notebook on a private drive with a private commit history. Lesson 7 covers how to pick the right surface for a given arm.

Decision logs

The same artifact that runs QC and MHG runs the arm. A markdown file in the project repo, one entry per decision, dated, short. No process around it; just the discipline of writing the decision down when it happens.

Parley's 12-Parley/decisions.md is the working example. Each entry is a dated short title, one or two sentences summarizing the decision and the reason, and a link to an ADR if one was written. The file starts with "Project exists" and accumulates from there. Renaming the project, picking a scope mode, deferring a sub-track, adding the venture to the kanban — every move that would otherwise be reconstructed from memory or git archaeology gets a line. The cost is thirty seconds per entry. The payback is that six months in, when a question comes up about why the arm doesn't do mobile, the answer is in a file with a date next to it.

A concrete example from Parley's log: when the Kaggle writeup originally proposed two tracks (sign language and adaptive sports), the decision to scaffold sign-language-only got logged the same day, with the explicit note that adaptive sports was deferred and might live in this repo, a separate one, or inside QCaddy. Six months from now I won't remember whether that decision was deliberate or accidental. The log says deliberate, and it says when.

Decision logs aren't just for the arm's internal history. They're how I prove to myself that a "should we expand into X" thought has been thought before and answered. Without the log, the same expansion question shows up every couple of months and gets a fresh answer based on whichever mood happens to be running.

Kill criteria

The honest version of running a side project is that most of them should be killed before they're done. The dishonest version is to keep them alive on hope. Kill criteria, written before the project starts, are the difference.

Three triggers are written into the Parley rails.

Cadence failure first: two consecutive months without a shipped notebook. One miss is normal because the main work pulled cycles, fine. Two misses means the arm has stopped working, and continuing to keep it open is the lie.

Cannibalization next: any month where the arm pulls cycles from a QC [URGENT] item. Not "competes with" but actually pulls. If a Crave decision or a patent filing slips because I was working on a Kaggle notebook, that's the trigger, and the response is to pause the arm until the main work clears.

Scope drift last: any decision-log entry that proposes adding something from the NOT-in-scope list. The entry triggers a review; the review either kills the proposal or kills the arm.

The point of writing these down before starting isn't that they're guaranteed to fire. It's that when they do fire, the response is already decided. Lesson 8 covers each trigger in more detail with the failure mode it's meant to catch.

The monthly check-in

The four discipline levers above are passive. They sit in files. What turns them into a working system is one recurring action: a check-in on the first of each month, done in twenty minutes, against a fixed list.

From 12-Parley/roadmap.md, copied verbatim:

On the first of each month:

- Was last month's notebook shipped? If not, it's still the current notebook.

- Did anything from QC [URGENT] pull cycles? If yes, that's fine — note it in decisions.md.

- Any new research questions surfaced that should go on the roadmap?

- Update notebooks-published.md if anything shipped.

Four questions. No reporting layer attached to it, no metric to roll up. The check-in is the entire ceremony around the arm, and that's deliberate — the only thing more dangerous than no cadence is a cadence that grows its own overhead. Lesson 6 covers the mechanics of the check-in and what to do when the answers are bad.

Closing

The arm survives or doesn't based on whether these rails get enforced. None of them is hard to set up. All of them are easy to skip when the main work is loud, which is precisely when skipping them does the most damage. A scope-rails list with no enforcement is decoration. A monthly check-in skipped twice in a row is the project telling you it's already dead. A decision log nobody writes to is just a folder.

The rails aren't the work, and they aren't supposed to feel like the work. They're what makes the work possible to do in the cracks of a startup without becoming a second startup. Run them and the arm compounds quietly in the background. Skip them and the arm either eats the main work or quietly disappears, and either outcome was avoidable.