Today is my last day at Merantix Healthcare.
While I am very sad to leave behind a stellar team which I helped build, it’s the right thing for me to do. Why?
At any company, there are multiple projects going on: Developing a product, getting regulatory approval, recruiting for a team.. you get it.
Whatever project, in the beginning, it needs builders, pioneers who come up with clever ideas and execute upon them fast. They improvise a lot along the way. They are opinionated people who prefer to make their own decisions on the fly. They don’t see any need for meetings. At this early stage of a project, there’s no one to meet with anyway.
These people are at their best when degrees of freedom are high and the problem statement is clear. It could be “Build an image viewer which runs in the browser”, “Get regulatory approval for this product” or “Hire a team of Clojure developers in Berlin”. Of course, there’s some ambiguity regarding details but the big picture is clear enough for the brain of the pioneer to automatically start coming up with ideas. Pioneers are best at building new things, and they love building them fast.
I was that pioneer.
Later, when a company grows and matures, its focus shifts. A typical post-early-stage startup now has a product which needs a lot of incremental improvements, nitty-gritty regulatory details which need to be figured out and a developer team which works well and only needs some fine-tuning. This is done by different people than the pioneers. For lack of a better word, I call them process people.
Process people are very important for a company at this stage. And, more importantly, having pioneers around now could be bad. Why? When you have a product, all efforts should be directed towards improving, marketing and selling it. You probably shouldn’t have some people walking off in random directions, developing other great products they just came up with. A startup at this stage can’t afford that. It needs focus.
I am not a process person.
And that’s fine – because that’s one of the many things I learnt at Merantix, later to become Merantix Healthcare.
When I interviewed at Merantix in October 2017, there were quite some funny situations. Remember, they only were a few people at the time – eight, I think. I was still in Heidelberg, figuring out what to do after graduating from medical school and working part-time as a frontend developer, writing React and not particularly enjoying it. In my spare time, I was learning ML and trying to apply it to mammograms, the DDSM dataset (ugh).
I got introduced to the later-to-become Merantix Healthcare CEO and he had the idea of having a “research collaboration”, given that both of us were working on mammograms. Except that they were a team of eight, with engineers from Google and Facebook, located in Berlin, and I was a doctor dude sitting in a dark apartment in Heidelberg, writing bad python code.
It occured to me that it may make more sense for me to join them.
At one of the interviews, they asked me whether I saw myself more in the business team or as a coder. I said “business” because I was fed up with writing JavaScript and React code. Then they asked me how much business experience I had. I said none. We then had a hard time figuring out what I should be doing at Merantix.
However, they repeatedly mentioned that they really needed a frontend developer. I repeatedly mentioned that writing frontend code was physically painful for me.
On my way home, it occured to me that that was the only thing I could contribute. They seemed like a great bunch of people and that was my only way in. So I changed my mind and offered to write some frontend code until we’d have hired someone to take over.
No one took over for quite some time.
But that was perfectly fine because I re-discovered Clojure and ClojureScript in the meantime which made writing frontend code fun again. And I guess it was good that it prohibited me from “contributing” to business decisions.
Writing ClojureScript is fun. I recall that Paul Graham said that Lisp is a good choice if you’re solving a hard problem from scratch, and that’s what we attempted. Writing a browser-based medical image viewer is a really hard task, especially in the beginning, when it’s entirely unclear if it’s possible at all, given the performance and memory constraints of browsers.
And that’s exactly what made it exciting for me. Posing the question Can it be done?, diving head-first into building it and building it fast.
Turns out, it could be done. Having the opportunity of tackling such a problem, choosing an interesting technology like ClojureScript along the way and successfully showing that it could be done was an exhilarating experience for me.
It reminded me a bit of my doctorate thesis, in which I was locked up in a window-less room for year, with Matlab and a dataset of MR images in front of me, with the goal of solving another hard problem. Doesn’t sound fun, but it actually was (really!).
At Merantix, our software continued to grow and I was increasingly consumed by regulatory work. We needed to hire Clojure developers who would take over. But was that even possible? Could we, as a startup, hire a bunch of senior developers, writing Clojure, in Berlin? Can it be done?
Everyone was saying how hard recruiting was. I had no clue how to do it. This was again very exciting for me.
Turns out, it could be done. Now we have a first-class team of five Clojure devs working here. Looking back, I’d love to say that I figured out how recruiting works, but that would be not true. I still feel clueless, a bit like the guy in high school who gets together with the hottest girl without knowing how he got there. Along those lines, I got the hottest girl – five times! Except that the “girl” is a guy, behind a computer, writing lisp.
Maybe the explanation is simple: If you offer great, non-mainstream technology (Clojure), working on an impactful project (breast cancer screening) and you’re a non-creepy, friendly dude who writes code (not a recruiter), then developers are really happy to meet you. Developers are always happy to talk about code, software development and war stories. Recruiting becomes an afterthought as most great developers are already working on something; but great developers always remember interesting projects. And they’ll get back to you once they’re looking for one.
While setting our eyes on developing radiology software, it became clear that this would be a medical device. Medical devices need to be certified by an external auditor to ensure safety before you’re allowed to use them on patients.
While achieving patient safety is unquestionably important, the current process of getting certified includes a ton of bureaucracy which is so opaque that it spawned an entire industry of regulatory consultants. Unfortunately, they not only charge significant fees but are often also quite clueless.
But could we just teach ourselves? Read the relevant rules and certify our own product? Can it be done?
It could. Learning the ropes of getting medical software certified was interesting as much as it was foreign. It’s a parallel universe of bureaucracy which is inhabited by very few enlightened people who are able to navigate it (mostly consultants).
While learning it was interesting, executing upon that knowledge was one of the most boring and frustrating experiences of my life. It was mostly about writing documents, filling out forms, creating spreadsheets, all day long, for months [1].
And then, a familiar pattern emerged: Just as I had handed off development work to the Clojure developers we’d hired, I now handed off regulatory work to our regulatory affairs people I had interviewed in the meantime. As soon as it had been shown that it could be done, I was ready to move on to the next project.
But this time there was no next project. Technically, I was still coming to the office and working, sort of. There’s always stuff to be done and people who took over my work always have questions which need answering. But I no longer had a project which I owned, a project where I was a pioneer, a builder.
And that’s fine. A company at this stage doesn’t need pioneers, or maybe even shouldn’t have pioneers. Because now it’s time to focus.
Leaving a company feels very similar to breaking up with someone. And when you break up on good terms it’s simply a statement that, right now, your differences outweigh your commonalities. But people change constantly. Who knows who we’ll be in a few years time?
[1] I wrote up some of our experiences getting certified on Medium: Part 1, Part 2.
Leave a Reply