The Boring Spreadsheet That Keeps Your Lab Honest

Ask a lab director what their team is working on and you'll get a confident answer. Ask what's currently running — deployed, in use, holding data, costing money — and the answer gets slower and more hedged.

This is normal. It's also the root of about half the problems labs complain about: duplicate work, zombie projects, surprise dependencies, and that one tool nobody remembers approving that's been quietly emailing a customer list every Monday since spring.

Three Versions of the Truth

Most labs carry three separate realities:

1. What we pitched — documented, polished, probably in a deck.
2. What we built — partially documented, lives in repos and Slack threads.
3. What's still alive — almost entirely undocumented, and the only one that costs anything.

The idea portal covers the first. Nothing covers the third. That's the gap a registry fills.

What a Registry Actually Is

Not a platform. Not a Jira workflow. A single table, one row per experiment, that answers the questions people actually ask: what is this, who owns it, what does it touch, and when do we decide its fate.

Minimum viable columns:

• Name and one-line description. Plain English. If you can't explain it in a line, that's information.
• Status. Pick a small vocabulary and stick to it: idea, building, pilot, live, in maintenance, archived, dead.
• Owner. A person's name. Not a team, not a squad, not "the platform group."
• Key dates. Started, next review, and — the important one — kill-by.
• Dependencies. Systems it reads from, data it stores, vendors it calls, people it would break without.
• Kill criteria. Written before launch, specific enough to be falsifiable.
• Links. Repo, docs, dashboard, whatever exists.
• Who uses it. A number and a short description beats a vague "internal users."

That's it. Eight columns, ten minutes a row, and you can answer questions that currently take three days of Slack archaeology.

The Two Columns That Do All the Work

Status and owner are hygiene. The load-bearing columns are kill criteria and kill-by date, because they're the ones nobody writes and everybody needs.

A kill criterion is not "we'll know it when we see it." It's "if fewer than fifteen people open the dashboard in a month, we shut it down," or "if the vendor raises prices above X, we stop." Specific enough that a stranger could apply it without asking the original team.

A kill-by date is a forcing function. It doesn't mean the project dies on that date — it means someone has to actively extend it, in writing, with a reason. That single mechanic eliminates most zombies, because zombies exist precisely because nobody is forced to make a decision.

Owners Are People

This is the rule that gets ignored and causes the most damage. "The data team owns it" means nobody owns it. When something breaks at 2 a.m., an org chart is not on call.

If a project has no individual owner, that's not a documentation gap. It's a finding — and usually the first sign that the thing should be wound down or formally handed over.

Keeping It Alive Is the Hard Part

Registries die of neglect more often than of bad design. The fix is to make upkeep almost embarrassingly cheap:

• Ten minutes in the weekly standup. Anyone who changed an experiment's status says so out loud. That's the whole ceremony.
• A quarterly sweep. Anything marked live with no review in the last ninety days gets flagged. Most of those flags turn into shutdowns.
• One editor of record. Not a committee. Someone who likes tidiness and has permission to nag.
• Automatic on creation. No experiment without a row. Add it to whatever your kickoff checklist already is, so it isn't a separate ask.

If maintaining the registry takes more than fifteen minutes a week, it's too complicated and it will be abandoned. Cut columns until it survives.

What It Actually Prevents

Duplicate work. Two teams building the same integration is a classic, and it's invisible without a shared list. The registry doesn't stop it — but it makes someone notice in week two instead of month seven.

Zombie projects. Things that were never killed and never adopted, still consuming a server, a license, and someone's attention.

Offboarding disasters. When the builder leaves, the dependencies column tells you what just became fragile.

The outage conversation. "Who owns this?" answered in ten seconds instead of an hour, during the one moment an hour actually matters.

Repeat mistakes. A dead row with a written post-mortem link is worth more than a lesson learned in a meeting nobody attended.

Don't Buy Software for This

Not yet. Start with a spreadsheet or a simple Airtable base. The tool isn't the point, and buying a platform for a practice you haven't proven is how you end up with an empty innovation management suite and a renewal invoice.

If the registry outgrows a spreadsheet in a year, that's a good problem and you'll know what you actually need. Most teams never get there, and that's fine.

Make "Dead" a Respectable Status

The cultural half matters as much as the columns. If killing an experiment is treated as an admission of failure, people will quietly keep things running to avoid the conversation, and your registry becomes fiction.

So say it plainly, and say it often: ending an experiment on schedule is a successful outcome. It means the lab learned something for the price it agreed to pay. Put it in the retro. Put it in the all-hands. Make it boring.

That's the whole pitch, honestly. A registry is a boring tool that makes an entire lab legible to itself. Nobody will ever thank you for it, and it will save you from at least three avoidable messes a year.