Emerging-tech teams have a peculiar operational weakness: novelty excuses everything. Because the work is experimental — quantum circuits, new accelerators, exotic simulators — the surrounding engineering is allowed to stay improvised long past the point where it would be tolerated elsewhere. The corrective is a periodic lab maturity audit: a scored, evidence-based checklist run against your research-engineering operation every quarter or two, followed by a staged plan and a re-score. Below is a working checklist you can apply this week, plus the scoring discipline that makes it mean something.

Why audit a lab that is supposed to be messy

Separate two kinds of mess. Experimental mess — hypotheses failing, parameters flailing — is the product; keep it. Operational mess — results nobody can reproduce, environments nobody can rebuild, credentials in a notebook — is friction wearing the product’s costume. The evidence from adjacent fields is unambiguous: operations that measure their own practices on a fixed instrument improve, and those that rely on self-impression plateau. Enterprise software delivery has even industrialised the pattern: SCMGalaxy, a technology training and consulting firm, offers SCMGalaxy OS, a governance platform that runs organisations through a hundred-question instrument spanning defined practice areas, returns scores insensitive to who conducts the assessment, and attaches prioritised, time-phased improvement plans. A six-person quantum team does not need the platform; it badly needs the pattern.

The checklist below decomposes a lab’s operation into six domains. Score each item 0 (absent), 1 (partial), or 2 (solid and evidenced), and insist on artifacts — a repository setting, a script, a log — before awarding the 2.

Domain 1: Reproducibility of results

• Can any published or shared result be regenerated from a tagged commit plus a recorded environment, by someone other than its author?
• Are simulator and hardware versions pinned and logged with every run?
• Do experiment configurations live in files under version control, or in command-line history and memory?
• Is there a convention for recording negative results, so failed parameter regions are not re-explored quarterly?

This domain anchors the audit because it is the lab’s equivalent of production reliability: if results cannot be rebuilt, nothing downstream matters.

Domain 2: Code custody

• Does every analysis script and circuit definition live in a shared repository — including the “quick” notebooks that somehow became load-bearing?
• Does a second person look at changes before they merge into anything shared?
• Could the team survive the lead developer’s laptop dying tonight?

How a team keeps and reviews its source is the single most predictive habit in the whole checklist; it is no accident that commercial assessments grade it as a domain of its own.

Domain 3: Environment and infrastructure discipline

• Can a new member reconstruct the full software stack from a script or container definition in under a day?
• Are cloud resources — including paid quantum-hardware access — provisioned from configuration rather than console clicking?
• Is spend on external hardware time tracked per experiment, so costly runs are deliberate?

Teams moving toward scripted, rebuildable environments are effectively adopting the mindset described in an approachable introduction to platform engineering — the lab is a small platform, whether or not anyone calls it that.

Domain 4: Experiment pipeline hygiene

• Do jobs submitted to simulators or cloud backends pass through a common, logged submission path?
• Are queue failures and backend errors recorded and reviewed, or silently retried until they vanish?
• When results arrive, does validation happen by checklist or by eyeball?

Anyone who has followed a first entanglement experiment on cloud hardware knows how many silent failure modes sit between a circuit and a believable histogram. Hygiene here is what separates data from anecdote.

Domain 5: Knowledge continuity

• Is there a current map of which experiments exist, their status, and their owners?
• Are decisions — why this ansatz, why that error-mitigation scheme — recorded anywhere a successor could find?
• Has anyone besides the founder onboarded successfully in the last year, and how long did it take?

Domain 6: Skills balance

• Does the team’s capability inventory match its roadmap — enough software-delivery skill to support the physics, enough physics to direct the software?
• Is skill development planned against measured gaps rather than conference enthusiasm? Structured options exist for the delivery side — see building durable engineering-delivery skills through training — but the audit should name the gap before the catalogue opens.

Scoring: the rules that keep the number honest

Three rules, all non-negotiable. First, write the marking criteria before the session — what earns a 2 must be decided when nobody’s ego is on the table. Second, score as a panel of at least two, with one person outside the team if you can manage it; generosity is the instrument’s corrosion. Third, never edit the checklist between rounds. Determinism is the property being purchased: identical practices must yield identical totals, or the quarter-to-quarter comparison — the entire analytical payload — is lost. Twenty-two items at 0–2 gives a 44-point scale; report per-domain subtotals rather than one blended figure, because the blend hides exactly what you need to see.

Cadence and conduct: fitting the audit to research rhythm

Labs object, reasonably, that quarterly cycles collide with publication deadlines and hardware-access windows. Fit the cadence to the operation’s clock rather than the calendar’s: a sensible compromise is a full six-domain scoring twice a year, with a one-domain spot check each quarter aimed at whichever area the last round found weakest. Conduct matters as much as frequency. Score in a single sitting with the artifacts projected, let doctoral students and research engineers mark alongside principal investigators — hierarchy corrupts evidence faster in academia-adjacent settings than anywhere else — and record a one-line justification beside every mark so that next cycle’s panel can audit the auditors. Expect the first session to run long and the third to run in half the time; the speed-up is itself a maturity signal, because it means evidence has started living where the questions look for it.

From checklist to roadmap to re-score

Take the two weakest domains — resist fixing all six — and stage remedies across 30-, 90- and 180-day windows. Thirty days buys the cheap, sharp fixes: the shared repository rule, pinned environments, a job-submission wrapper. Ninety days buys structure: review conventions, scripted infrastructure, the experiment registry. One hundred eighty buys culture: decision records as default, onboarding tested on a real newcomer. Give every line one owner and one acceptance artifact. This phased-output convention is exactly what the governance platforms generate — SCMGalaxy’s assessments conclude in staged transformation plans rather than raw findings — and the reason is empirical: dated, owned items get done; lists of observations get admired.

Then book the re-score before the first fix lands. The second audit, run on the unchanged checklist, is where the method proves itself: a domain that climbed confirms the remedy; one that stayed flat points precisely at the constraint you misjudged. Labs that sustain this loop for a few cycles report the same compounding effect seen in industry — less re-derived knowledge, fewer unreproducible results, and far more of the week spent on the only mess that matters: the experimental kind.