Skill-transfer adjacency
Picking a topic close enough to compound with the main work, far enough to feel like rest.
The definition
A parallel research arm earns its cycles when the topic is adjacent to the main work along the dimensions where skills actually transfer, and distant from the main work along the dimensions that make it feel like rest. Both halves matter. The first half is what makes the arm compound. The second half is what makes it decompress (see Lesson 1).
The mistake most operators make when picking a topic is to over-index on one dimension. They pick something "in the same field" without checking whether the same field means the same tools, the same architectures, the same evaluation discipline. Or they pick something "completely different" because they want a break, and end up with a hobby instead of an arm.
The diagnostic is a table. Build it before you start, and check it again at month three.
The substrate table — Parley as the worked example
Parley is sign-language computer vision. The main work it's adjacent to is an internal CV venture in a different end-user domain. Here is the actual table I'd write for that pairing.
| Substrate | Transfers from sign-language CV to the main work? |
|---|---|
| Pose estimation libraries (MediaPipe Holistic, OpenPose) | Yes |
| Landmark extraction pipelines (keypoint tensors, per-frame normalization) | Yes |
| Temporal model architectures (transformers on landmark sequences) | Yes |
| Identity-independent evaluation discipline (signer-independent in Parley's case, analogous splits in any human-subject CV venture) | Yes |
| Datasets | No. A 250-class isolated-sign vocabulary and a small fixed outcome set are completely different label spaces |
| Evaluation protocols | Partial. Top-k accuracy yes, the specific benchmark splits no |
| End-user scenarios | No. A Deaf-hearing conversation and a different real-world capture scenario share almost nothing |
Read down the Yes column. Those are the skills Parley will give me back as QC engineering capacity. Read down the No column. Those are what give the project its decompression character. If the table were all Yes, I'd be doing QC work under a different name and burning out twice. If the table were all No, I'd have a hobby.
The rule I use: the Yes column needs at least three rows that are real tools or architectures, not just abstract categories. The No column needs at least two rows that involve real differences in domain, dataset, or end user. If either side is thin, the candidate isn't adjacent enough or isn't distant enough.
Three ways it goes wrong
The candidate is too close. This is when the table is all Yes and you've picked a project that's basically a feature your main company isn't shipping. Symptoms: you keep wanting to tell investors about the arm because it sounds like the company. Treatment: pick something farther. The point of the arm is rest plus compounding, not stealth pivots.
The candidate is too far. This is when the table is mostly No and the Yes column is one weak entry like "I use Python in both." Symptoms: at month three you've shipped two notebooks but they haven't taught you anything that came back to the main work. Treatment: either accept that you have a hobby and demote it, or pick a different candidate where the substrate actually overlaps. The example I almost made was picking a generative-music project, which would have been fun and zero help to QC.
The candidate is single-axis. This is the subtle one. The table shows Yes on one row that you've convinced yourself is the important row, while the rows that actually matter for your main work are No. Sign-language CV would fail this test for a QC competitor whose work was on edge-device deployment and TFLite quantization, because Parley's research arc doesn't push hard on quantization. The lesson: list the dimensions that actually matter for your main work first, and check the table against that list rather than against generic CV categories.
The diagnostic
Before you commit to a candidate, do two things on paper.
First, list the five technical skills you most want to deepen for the main work over the next twelve months. Be specific. Not "computer vision." Things like "temporal models on landmark sequences," "identity-independent evaluation protocols at the architecture-and-test-split level," "ONNX or CoreML conversion for Apple Silicon deployment," "data augmentation strategies for small labeled datasets," "self-supervised pretraining on unlabeled video." Five concrete capabilities.
Second, for each capability, mark whether the candidate channel will exercise it within the first six notebooks. Use a three-way mark: yes / partial / no.
If at least three of the five are Yes or partial, the adjacency is real. If two or fewer, it isn't. Pick a different candidate or accept a hobby.
This is the test I would have applied to TruPath OS in early 2026, where the five capabilities I needed for QC and MHG were all on the data-pipeline and CV side, and TruPath OS exercised exactly zero of them. It exercised React 19 and Electron and SQLite schema design. None of which I needed for the main work. The diagnostic would have killed it on day one. I learned the diagnostic by killing it on day ninety. The lesson cost me three months.
Apply this
Build the substrate table for your candidate channel. Use the format above. Six to eight rows. Be honest about what transfers and what doesn't.
Then list your five technical skills for the main work over the next twelve months. Cross-check.
If both halves of the table are full and at least three of your five skills get exercised, write the brief and start the arm. If either side is thin, you've saved yourself the months I lost on TruPath OS, which is a fair trade for thirty minutes of paper work.
The table is a living document. Re-run it at month three. If the Yes column has shrunk because the project drifted, or the No column has shrunk because the project has started to look suspiciously like your main work, that's the early signal. Course-correct then, not at month nine when the cost of correction is higher.