Perf review — Apr–Jul 2026
Working note. Menu of raw material per question — cut down, don’t add.
Cycle = full tenure (start 2026-04-06).
Q1 — What did you own end-to-end, and what changed?
What did you own end-to-end this cycle, and what changed as a result? Describe the customer or business impact and how you measured it.
1. Cell binding + blocking robotics DRI
- Owned robotics end-to-end for both cell-based assays — deck buildout, instrument integration, protocol bringup, and the production runs themselves.
- Built out ml1-052 (cytometer) and ml1-056 (spin/wash) from bare decks into the two instruments the campaign runs on.
- Brought the Agilent NovoCyte flow cytometer onto the fleet from zero — sim asset to api integration to robotics behaviors.
- Integrated the rest of the instrument line for 056 and 052: EL406 washer, centrifuge, Tempest, 8-channel pipetting, AMR handoffs.
- Rebuilt the wash process mid-campaign when Lynx replaced the plate washer as canonical, without stopping either assay.
- Published the assay-development report that closed out the binding work.
Impact
- Cell-based assays were the differentiator Irving treated as a must-have to sign with Medra.
- We delivered data on both. Irving has been very excited about it.
- Flow cytometry is now well supported in ml1 protocols.
2. Robotics stack improvements that fell out of it
- Analytic IK for the Cobotta Pro. Replaced a seed-dependent random-restart search with a closed-form solve that returns every branch, deterministically, in under a millisecond.
- The planner now picks the joint-space-nearest configuration directly instead of relaxing tolerances until the solver finds something.
- Seed-joint coherence. Pipetting on ml1-052 (the start, but expanded to all other LH decks) was resolving to inconsistent IK branches — the arm would spin a joint ~2π to move the tip a few mm.
- Pinning all 21 pipette anchors to one coherent branch cut joint travel 67% and flip motions 91%.
- Same root cause elsewhere: an intermittent empty-lid-grasp on ml1-052 that recalibration only appeared to fix, and that I closed properly rather than re-teaching around.
- Vendored
medra_bcapinto the monorepo. Changing the arm C++ used to mean a release round trip through a separate repo; now it changes in the same PR as its Python caller.
Impact
- No more flung tips or fluid mid-transfer — that’s uniformity and reliability in the customer’s data, not just cleaner-looking motion.
- Every LH deck in the fleet inherited the fix that had seed joint optimization run on it.
- Arm-level C++ fixes now ship at normal speed instead of waiting on a cross-repo release.
3. Deck 6 modernization + AMR loops + other misc
- Revived deck 6 as a working demo deck — new fingers and sleeves, full recalibration, verified under repeated stress runs rather than a single pass.
- Built the multi-deck AMR round trip: a plate shuttled ml1-013 → ml1-026 → ml1-023 and back, each deck exercising a second plate in parallel.
- Ran 20+ consecutive loops without failure.
- Calibrated AMR tongue waypoints on 8 decks by hand, then wrote the calibration guide so the other assay owners could do their own instead of queueing behind me.
- Shipped the keyboard jog script, replacing the prompt-based waypoint flow with live jogging. It’s now the default tool for teaching waypoints, and the substrate the IK-branch and seed-coherence work plugged into.
- Wrong-deck guard. After a collision caused by selecting another deck’s job, the planner runner now refuses jobs whose target deck doesn’t match the machine.
Impact
- The lab running end-to-end is what investors, the board, press, and online actually saw — the demos were the artifact, and they held up.
- There were multiple close ups of deck 6 in promotional materials we used and interviews Michelle did, and the AMRs running around with plates was also a big part of the demos.
- Keyboard jog and the AMR guide made calibration easier and more accessible to the whole team
- Wrong-deck execution is now impossible fleet-wide, preventing a whole class of collisions before they happen
Q2 — Operating principles (2–3)
Situation / context · Result · Tradeoffs Principles: We are on the customer’s team · Why not faster? · We Refuse to Let Each Other Down · Challenge all constraints (except physics)
Night shifts appear under both P1 and P3 below, with different emphasis — customer timeline vs. covering the team. Probably pick one.
1. We are on the customer’s team 🧑🔬
Situation. Production runs against a hard customer timeline, and a subset of plates came back QC-failed. The default read was that those plates had to be physically rerun — more robot days, more cells, more calendar.
Result
- Ran the night shifts for cell binding, roughly 8pm to 6am through two stretches in July, so the runs kept going.
- Those shifts produced the first batch of genuinely good production data.
- The 5-run blocking round came off on schedule with no interventions: 5 runs, 10 plates.
- Pulled usable results out of the QC-failed plates by comparing them against passing plates, taking reruns from 12 antibodies → 6 → 0.
- The customer got an answer on every candidate without spending another run cycle to get it.
Tradeoffs
- Analysis time came directly out of experiment time.
- Nights cost me the following days, and it’s not a mode I could have sustained much longer.
2. Challenge all constraints… except physics 🧗
Situation. The EL406 washer was the assumed wash step and kept failing in new ways — clogs, detergent lysing cells, a silent dispense failure, and finally well-to-well non-uniformity. We were mid-campaign with the customer clock running.
Result
- Fixed each failure as it surfaced and got the washer stable.
- Then ran the experiment that settled it: manual samples with and without the washer. Non-uniformity persisted either way, so the washer wasn’t the whole cause.
- Rather than keep tuning a component that was structurally wrong for the job, switched the canonical wash to Lynx and moved to deep-well plates — mid-campaign, under time pressure, without stopping the assay.
- Uniformity resolved, and the open problem moved off uniformity entirely and onto dose-response.
Tradeoffs
- Threw away weeks of washer tuning right as it stabilized, and Lynx costs far more in consumables.
- Swapping instruments mid-campaign meant re-validating a protocol that was already producing data.
3. We refuse to let each other down 🧑🚒
Situation. By June I was the only person who could run the cell protocols end-to-end, and Andrew joined needing to get productive on a stack he hadn’t seen.
Result
- Onboarded and mentored Andrew onto the robotics stack, checking in frequently while he came up to speed rather than waiting for him to surface problems. Pushed him to get up to speed on the robotics stack and got him contributing quickly. Kept him unblocked when my own review latency became the thing slowing him down.
- Trained a broad set of people on the cell protocols — new hires, scientists, and the people covering my runs — and switched from lecture to shadowing once that clearly worked better. Leyton, Bhavaani, Andrew, Alex, Leon, etc.
- Wrote the docs to match: assay SOPs, cell prep SOP, AMR calibration guide, a running-plates standard.
- Set up remote access so scientists could drive the cytometer without me in the room.
- Took the night shifts and late nights during production so data landed when the team needed it.
Tradeoffs
- Paid all of this in hours rather than scope cuts, and ended July burnt out.
- Training and docs came out of build time.
Q3 — Biggest learning
What was your biggest learning from this cycle? What experience or decision led to it, and how will it influence how you work going forward?
Situation. Cell binding was the hardest thing I worked on, and the hard part turned out not to be robotics. Ajai and I got the assay to a place we believed was working, so I moved on to what looked like the remaining work — optimizing the robotics and making runs faster. When Bhavaani joined and brought a much higher bar for what counted as a valid result, we didn’t meet it. We ended up freezing robotics, spending a long stretch stuck on the science, and eventually not using a large part of what I’d built.
The learning
- Get the science working manually, to a standard someone qualified has validated themselves manually, before optimizing the robotics around it. I optimized a process that hadn’t been validated, and a lot of that work was thrown away when the process changed.
- Have the scientific expertise on the team before the campaign starts, not partway through. Bhavaani joined after we were already running, so the bar moved after the work was done rather than before it started.
- I’m not the right person to set scientific standards, and I should say so earlier. I don’t know what’s standard in industry, so I can’t judge whether a result is good enough — and I spent too long acting as a middleman on calls someone else was better placed to make.
How it changes how I work
- Treat “a qualified person has agreed this manual process produces valid data” as the gate that unblocks automation work, not something to establish in parallel with it.
- Name who owns the scientific decisions at the start of a project, and push for that person to be staffed before I start building.
- Say early and explicitly when a decision is outside my expertise, rather than absorbing it because I’m the one closest to the work.
- Already applied: when I was staffed onto Chai, my first questions were about timeline realism and who else was on it, before scope.
Q4 — Growth area next cycle
What is one meaningful way you want to grow next cycle? Identify one area where you want to meaningfully improve and describe what success would look like.
I want to start and carry an initiative in core robotics that helps everyone across the board. I’ve shipped core robotics features this cycle, but each one came out of whatever assay problem was in front of me at the time. I want to push a larger, more foundational change end to end — starting with taking my force-based movements RFC all the way through — collecting the data, and making principled, clean design choices that serve the company long term rather than the run in front of me.
Closing the loop further is the part that interests me most. Today the arm largely runs open-loop against calibrated positions and stops when it feels something. I want to get to motions that use what they sense to correct and continue, rather than halting and waiting for a person.
What success looks like
- The force-based movements RFC exits draft, gets real review, and lands as something protocols actually use.
- At least one motion in production corrects itself from sensed force instead of failing to a human.
- The design decisions are backed by data I collected rather than by what was expedient at the time.
- Other people build on it without me in the room.