Interview with Synthace
AMA-style interview with Co-Founder and CSO, Markus Gershater, and Michael Sadowski, Head of Bioinformatics
This is reposted from a Q&A we did in March 2023. Check out our Slack for more.
We were lucky to have the opportunity to interview Co-Founder and Chief Scientific Officer, Markus Gershater, and Head of Bioinformatics, Michael (Sid) Sadowski from Synthace! Synthace is a digital experiment platform that lets you design powerful experiments, run them in your lab, then automatically build structured data. No code necessary.
Read more to learn about:
Coding large-scale wet lab experiments in a structural manner
Automation challenges with instrument integration
Bio SaaS tool integration
and more!
Nicholas: Welcome, everyone, to our q&a with @michael! big thanks to sid for joining us. as always, i’ll get us started with a few questions but please chime in with your own.
Michael: Hi, great to be here and thanks for the invite!
i’ve got my good friend and colleague @markus here with me, might get him to chime in here and there.
Nicholas: Even better!
Question 1:
Nicholas: How did you get interested in bioinformatics?
Michael: It was back when i was doing my undergrad in pharmacology. i got really interested in proteins and in particular the sequence/structure/function relationship.
this was around the time they first released the draft human genome sequence so there was a lot of interest in the field as well: people started to realize that although it was a huge milestone it was really only the tip of the iceberg.
anyway, i was learning about various receptors, ion channels and such and the versatility of proteins finally really hit home with me. the thought that underneath that was a language of some kind, a pattern you could recognize got me really interested in what you could do with software in biology.
Michael: Also i was a big fan of douglas hofstadter at the time, some of his stuff was a huge influence
Bradley: Geb changed my life
Michael: Totally. metamagical themas i read even earlier and it probably was the single biggest reason i wanted to try and exist in the weird, difficult space between disciplines.
the chapter titled “the genetic code, arbitrary?” in particular really piqued my interest
Question 2:
Nicholas: Tell us what you’re building at synthace these days
Michael: I’ll let @markus handle this one as i’ll probably get far too in the weeds!
Nicholas: Getting into the weeds is good! we want that
Michael: Fair enough! i’ll let markus kick us off
Markus: Haha, yeah i can't help too much with the weeds (except real ones- i was originally a plant scientist :seedling:), but let's start high level and go from there
Markus: We're building what we call a digital experiment platform. which immediately prompts the question "fine so what is that?!"
Markus: The problem with experimentation today is that the only place where a detailed model of everything that's going on is held is in the mind of a scientist.
Markus: This places a huge burden on scientists and ultimately limits the experiments that are possible.
Markus: So we're building a platform where the experiment can be defined digitally, where that definition is used to make a low-level detailed model of what needs to happen in the experiment.
this digital experiment model can then be used to drive automation (or give manual instructions) and also is the framework on which the data from that experiment can be hung.
Markus: In this way, the full experiment is generated, tracked and analysed digitally meaning that:
• experiments can be a lot more expansive, as our planner takes care of a lot of the tedious and demanding details
• data can be dynamically auto-structured using the structure of the experiment generated by the planner
• write-ups are now just a matter of annotating the model
Nicholas: This is great! i think it segues nicely into my question about the details of how you think about implementing this: https://bitsinbio.slack.com/archives/c02sav8du2j/p1678733996742439
Question 3:
Nicholas: Can you explain how you think about doe? where is it most useful/where is it not useful?
Michael: Wow, big question! this may not be well-structured, i have a lot of possible answers.
Michael: So first off i think doe has a bit of an image problem: it’s become synonymous with quite a narrow implementation which i’d say is better termed rsm. that is aiming at quadratic linear models and fairly simple optimization.
but i think of it much more generally: it’s just about trying to pose your experimental questions in the best possible way given your available resources.
Michael: (don’t get me wrong, i have a lot of time for rsm, it works surprisingly well in lots of cases, but doe is much more than this)
Michael: So to me it’s often an unfortunately neglected piece of the data puzzle: people typically think that the way to get better data is just to add more measurements. however it’s essential to also consider how much you’ve explored the system’s state space, so to speak. good experimental design gives you a great deal more perspective which is crucial, particularly for complex stuff like biological systems
Nicholas: Can you give an example of a time you’ve seen doe be useful outside the narrow bounds of what people typically think it is used for?
Markus: In the end, doe is a pretty generic framework, which can be used for the optimisation or characterisation of pretty much any biological system.
where i was personally most surprised was its effectiveness in navigating genetic design spaces. check out publications from atum (formerly dna2.0) for some brilliant examples. https://www.atum.bio/resources/archive/presentation-publications
Jon: Used doe for a catheter manufacturing line and i kid you not...yield increased 38% immediately after implementing from the factors.
massively underused skillset within the pharma manufacturing world.
Question 4:
Nicholas: How do you think about expressing the design of a wet lab experiment in a structured way that’s friendly to code? in particular, large scale experimentation is often difficult to describe using a ui.
Markus: So the way the think about this kind of problem is by thinking of levels of abstraction.
Markus: The lowest level that we currently expose is what we call elements: blocks of experiment functionality that are relatively atomic, like "mix", dilute, aliquot.
these can then be composed into higher level assemblies like "build standard curve"
and in turn these can be made into full protocols.
Markus: The beauty of this kind of approach is the definition can be the same for 1 run or 1000, the planner works out the logistics of scaling a protocol as needed.
Markus: Sorry if that's not completely clear- turns out writing clearly about deep concepts on the fly isn't so easy!
Nicholas: It makes sense — i think the concept is approachable, but the implementation can be tricky. for instance if i wanted to have a “standard curve” across 30 plates, but everything slightly different (e.g. down shifted by a row) — that’s easy enough to express in english but can be very tricky to build a ui around
Markus: I think this is the trade off- with abstraction you inevitably get more power, but less fine-grained control.
the main trick for us is working out which of those fine-grained details are actually irrelevant/inconsequential and abstracting them away.
Question 5:
Nicholas: What are some of the automation challenges you’ve encountered when trying to integrate with instruments?
Michael: Oh where do i start?
Michael: So first off there’s the simple fact of life that pretty much every device exists for a reason: they’re all different, so there’s an immense diversity of capabilities to try and cover. aiming to find the right balance between simplicity, consistency and completeness in providing a device-agnostic interface has been pretty tricky
Michael: And on top of that there’s the huge variation in the level of information and control different devices offer. it’s often surprising what kinds of questions you just can’t ask of a device, or what critical functionality you only have access to via the gui
Michael: And then there’s the simple question of access - devices which only let you program them via a touchscreen, or a usb stick in the actual machine, or they do have software but you can’t actually write a program on it unless you are directly plugged into the device itself.
Question 6:
Vega: Does the synthace platform integrate with some of the know bio saas tools that fall under the umbrella of eln and/or lims? have you seen any real use cases where this was done?
Michael: So if you have a look at @markus’s response above about what we’re building he talks about synthace as a digital experiment platform. the key thing about this is that it means covering an enormous space where lots of people legitimately have existing tools, often with good reasons for wanting to use them.
clearly we can’t be everything to everyone so integrations are critical to the success of this.
Michael: To answer the question more specifically though, we’re in the process of scoping out exactly how we integrate with different parties. we’ve already got customers who have rolled their own, so to speak, creating synthace workflows which include the required processing. but we want to build on this to give a better experience.
Luis: That's great, i feel like if you don't give customers that flexibility then it'll just alienate them. plus you get to see the creative amazing things they build that maybe internal teams didn't think were possible.
Vega: Organizations (even the smaller ones) rarely pick just one software tool. integrations across software tends to be pretty common. specially using apis. any company that invests in apis and great documentation is going to do very well imo
Question 7:
Bradley: How much has your platform increased the velocity per experiment and the number of parallel experiments?
Markus: What a great question!
Markus: It in turn brings up the question of what we should be aiming for.
Markus: The ideal would be "the most scientific progress, as fast as possible"
Markus: But how do we measure that? eureka moments/month? :smile:
Markus: But we have comparisons where we look at a process that has been done a lot, such as assay development in early drug discovery, or media development for cell line growth and differentiation, and it's normal for us to see months of difficult, uncertain work turned into weeks of definitive decision making.
Markus: So time savings of 50-75% are not unusual
Markus: and you tend to get to a better end point.
Markus: This is usually a result of the combination of:
• multifactorial methods (e.g. doe)
• automation
• software (i.e. our digital experiment platform) that brings those together and makes it all work
Bradley: Have you experimented with number of papers published per month as a root metric? number of discoveries pre using your platform* vs after?
Question 8:
Nicholas: One thing that’s tricky here is that platforms work well if everyone is using all of the parts. that’s often not the case (especially at the beginning) — how do you think about incremental/piecewise usage?
Michael: Yeah i think that’s something we didn’t get right initially: wanting to get the whole thing done in one go and not thinking about how to decompose it into different segments of value.
Michael: So more recently we rearranged our product team into cross-functional ‘cells’ which aim to cover the main stages of the experimental process from design through to data analysis. this was a great start on really thinking about how to get value from each subcomponent individually.
Markus: What i've been really gratified by is how an incomplete version of our platform (and it will frankly never be "complete") can nonetheless be very scientifically valuable.
the moment you enable the scientist to run a powerful experiment that would previously have been untenable, you're delivering huge value to that scientific effort.
Question 9:
Jesse: What's the hardest part about introducing doe into a lab and what have you found works best to lower these barriers?
Michael: I’m not sure if there’s a single hardest part as such: there is diversity in culture at all levels and a lot depends on the specific individuals you’re dealing with.
Michael: I think the most common issue is time pressure though: most scientists have to grapple with a lot of diverse tools and they end up having to use them only very narrowly. this means they often use a particular tool only infrequently, and rarely have enough time to learn any more than the bare minimum required to do a specific job.
Luis: The narrow use of tools is also true for automation.
Michael: That’s a huge challenge for adopting something as potentially flexible and open-ended as doe - you can only go so far in making something like that pick-up-and-play
Noah: From a more academic/knowledge standpoint, the synthace doe masterclass videos have been very useful for me (
in trying to adopt doe in my lab work i feel like what's missing is a specifically bio-focussed explanation of doe. there's quite a lot of material out there, like the nist handbook, that's great at the theory, but all the examples are baking cookies or optimising flow rates for a chemical reactor.
Michael: Yeah i’ve heard the same several times - examples of how controlling particle size gets your process within spec are really not compelling to biologists.
we’ve been writing lots of blog posts recently aimed at addressing this sort of thing, as well as doing webinars.
always looking for topics so if there’s something anyone is curious about or thinks is missing we’d love to hear about it.
Michael: Also thanks for the kudos!
Question 10:
Maximilian: When looking at synthace demos, i usually had the impression that the software controls a single liquid handler (with potentially additional integrated instruments), do you also see yourself controlling “work cells” that integrate several instruments with e.g. robotic arms?
Luis: It really does feel like it’s heading toward that space doesn’t it?
Markus: Haha, yeah ideally we'd control everything!
Markus: But more realistically we're finding that for the time being we can deliver a load of benefit even "just" on decks like tecan and hamiltons.
the problem is that the more you include in the platform, the more the problem explodes somewhat exponentially, so being very deliberate about how we increase our hardware integration is critical.
Markus: I'm very interested in looking at how synthace could interplay with software like cellario or green button go.
Markus: I'm completely convinced that we have to tackle this massive problem space together as an industry. collaboration and integration will always be our primary straegies.
Question 11:
Bradley: How does synthace define success for customers? what does the world look like when you have accomplished your mission?
Michael: For me (and this is perhaps more personal opinion than speaking for synthace) i imagine a world where scientists from different disciplines are able to contribute their expertise to the experimental process. you have all the best tools available, be they computational or physical
Markus: I define success as better science. which can be hard to measure!
our customers often want faster timelines and clearer conclusions. which—excitingly—we've seen to be highly tractable with this new way of working.
Markus: Anything that can definitively cut through the complexities of biology is success in my book.
Question 12:
Maximilian: With regards to the protocol language: do you plan to have the method sharing on an open platform similar to http://protocols.io|protocols.io or is it targeted at sharing between groups in the same enterprise?
Michael: We did originally plan to have a more open platform for method sharing, however it’s not an idea we’ve really put serious time into.
fundamentally i do think basic methods are precompetitive and there’s definitely mileage in the idea but there’s a lot of work to do in getting the definitions right and making it worthwhile for people to contribute to such a thing.
Question 13:
Maximilian: Currently the protocol language seems only graphical - has the need ever arisen to have a textual domain specific language (dsl) in parallel so more “programmer-like” scientists can track their execution in git, maybe plug-in some custom tools into on-the-fly decision making etc.? (tl;dr what’s your take on the gui vs. textual programming debate? :slightly_smiling_face: )
Luis: Your last question could fuel a whole bib talk series :joy:
Maximilian: :sweat_smile: wasn’t aware this is so shocking / controversial haha
Nicholas: We should do a set of talks on this! that would be super fun
Michael: Well. what a question. so i refer back to @markus’s description of the levels of abstraction here. where he stops is in the individual elements that compose a workflow. what he didn’t mention is that these elements are indeed written in a sort of dsl we created a long time ago
Michael: Now, when we started out we were all about making a web ide for biologists to write in. and we very quickly learned that a good fraction of biologists (at least the ones we managed to sell to) didn’t want to do that. mostly because they didn’t have time to get into things at that level. coding was a distraction from getting things done
Michael: Now like all experiments in the world of startups you have to take this finding with a bit of a pinch of salt: we didn’t have the resources to fully do justice to the idea by any stretch.
Michael: We later did some more research which suggested that with a few tweaks there was definitely mileage in the idea of a dsl but it’s not something we’ve seriously pursued. i think it’s fair to say there’s still a lot of biologists out there who don’t really want to get into text-based coding, however much it is (for me at least) such an obviously more efficient way to do things. i am aware the tide may be turning a bit on this but i wouldn’t like to guess how long it will take.
Maximilian: Thanks for the elaborate response! great to hear about the journey - i also made the experience that text-based coding is really hard (impossible?) to sell currently - but i also feel that the “fear of coding” srsly holds the field back, but that’s not something a startup can bet on …
Michael: Yes it’s a bit of a catch-22
Luis: I think the "currently" is 5-8 years from now, younger scientists are being exposed to at least basic fundamentals of coding more and more... their managers and directors tho... that's a problem.
Noah: Is it on the roadmap to let customers write code for their own custom elements, so that a company might have more code-savvy scientists/engineers to write/modify the elements, and all the non 'codey' scientists have to do is use them?
Michael: Not currently - however we’re always thinking about ways to make the interface easier and more powerful so i wouldn’t rule it out if that’s a good way to achieve that.
Jack: We explored a dsl for late stage development. crazy powerful but no scientist wanted to use it because "it was code". :cry:
Jack: Would love to work more on such a thing if there is appetite.
Question 14:
Nicholas: What are some of the trends in the bio space you’re most excited by?
Markus: I wouldn't be me if i didn't say the upswell of use of multifactorial methods like doe.
it's been a long time coming, but finally there seems to be a real interest in using these approaches! which is good, as they're way more suited to investigating the emergent complexities of biology than more "standard" methods.
Markus: I'm also excited by the utter transformation of the research into underlying biology that has been enabled by ever-more capable omic technologies and high-throughput application of crispr.
in the drug discovery space this has opened up a universe of new targets for example.
Andrew: I started my career in drug discovery when the human genome project was wrapping up, now i work in a lab where basically everything we do is mediated by technologies that didn’t exist 10 years ago, like crispr. it’s routine now, we just buy kits and reagents.
Question 15:
Nicholas: What are some of the trends in the software space you’re most excited by?
Michael: You mean apart from llms? :grin:
more seriously of course the continuing question of how far the current developments in ai/ml will take us.
it’s something i perpetually debate: i’m old enough to have grown up in the period when ai was a bit of a joke because of the abject failure of knowledge based systems.
and i’ve seen various hype cycles around later advances come and go. and yet we’ve now seen progress on two problems really close to my heart (go and protein structure prediction) which seemed unimaginable only a few years before.
i still think that in the world of biology there’s a long way to go in terms of how we collect, annotate, enrich and standardize data and without advances there we won’t really get too far but i’m sure the current tide will leave us somewhere interesting and i’m quite fascinated to see where it is.
Nicholas: This has been a fantastically fun q&a! really appreciate the time from @michael and @markus. please keeping leaving questions and continuing the discussions
Markus: Thanks so much for having us, it's been really fun. what a great community this is.
Michael: Yes 100% - some fantastic questions and great discussion. hoping to continue this discussion in the near future!