What shipping software taught me about running a lab

For several years I lived two working lives. By day I was a postdoctoral fellow studying breast cancer at McGill. In the evenings and on weekends, I was running my first company, a small software firm, as its chief operating officer. People assumed the two had nothing in common. They had more than I expected.

Someone has to use it

In software, nothing counts until a user can open it and get something done. A beautiful feature nobody finds is a failure. That changed how I think about research outputs. A protocol only another expert can follow is fragile. A figure that needs a paragraph to decode is not finished. I started writing methods and making figures with the next reader in mind, whether a new student or a reviewer.

Versions, not perfection

Software teams ship a working version, watch how it is used, then improve it. Labs often do the opposite: they wait for the perfect experiment and run it once. The software habit is better. Run a small pilot, find out what breaks, fix it, then scale. Most of the expensive mistakes I have seen in labs came from skipping the pilot.

Bugs are information

Every developer learns that a bug report is a gift. It tells you exactly where your assumptions were wrong. A failed experiment is the same thing, if you treat it that way. Writing down what failed, and why we think it failed, is as valuable as recording what worked. It saves the next person weeks.

A failed experiment is a bug report. It tells you exactly where your assumptions were wrong.

Deadlines are a design constraint

Products have release dates. Grants and papers have deadlines too, but labs rarely plan backwards from them. Running software projects taught me to break work into pieces with owners and dates, and to cut scope early rather than miss the date. I now run my lab projects the same way, and the people I train learn it too.

Talk to the people who use it

The best product teams I worked with spent time with their users before writing a line of code. In a lab, the users are the clinicians, the companies and the patients who might one day benefit from the work. Asking them early what they actually need changes which experiments are worth running. It is a conversation academic science has too rarely, and one I now try to have at the start of every project rather than at the end.

Where the analogy ends

Biology is not software. You cannot roll back a cell line, and nature does not read your documentation. Some experiments take months no matter how well you plan. But the discipline carries over: clear goals, small steps, honest testing and a record of every change.

Today I still build AI and software products, and I run research projects in a university lab. I no longer think of them as two careers. They are one way of working, applied to two kinds of problem.