Jason joined Fulcrum Genomics in January 2024, straight out of his PhD. In his doctoral work he built fast and accurate indexes for analyzing huge reference sequence collections. He has also developed matrix factorization algorithms for data imputation, and worked on mutational signature analysis in cancer. We recently sat down to chat about work and life as a bioinformatics consultant.
What’s your area of expertise, and what excites you about your work?
Jason: I think my area of expertise is in turning scientific and operational needs into robustly engineered solutions. One problem I often see are clients with projects or analyses that are not reproducible and/or difficult to maintain. For example, an exploratory or ad-hoc solution can outlive its intended lifespan and ends up in production. Or turnover on teams and lack of documentation make a system difficult to interrogate and understand.
I’ve developed a niche at Fulcrum in going into these kinds of situations and being able to a) explain what is going on and b) to find effective engineering solutions so that future work is more reproducible and more easily audited. With my experience in bioinformatics I’m able to navigate the levels of abstraction and explain why these engineering aspects are important for scientific needs.
It excites me about my work that I can do that independently and help teams in the long-term. We’re really invested and involved in these projects and trying to set up clients for success in the long-term.
What’s a common challenge in our industry that people don’t talk about enough?
I think the main issue that we see is that folks are too specialized! It’s challenging when business, scientific and engineering teams struggle to “speak the same language”. At Fulcrum we can wear the different hats and fill in some of the gaps because at Fulcrum we’re really good at doing more than one thing, so not only do we have a deep technical expertise, we’re also able to be the glue.
What’s one tool, tip, or mindset shift that has made a big impact in your work?
I have a favorite tool but it’s kinda boring. I think it’s really challenging because most bioinformatics people are not your “typical” or “traditional” engineers. I’d just say that Docker and AWS - infrastructure as code - is your friend. I think you’ve got to have some of that, it’s unavoidable the minute a project becomes more than one person. I use Docker and Cloud Formation and infrastructure as code A LOT, but it’s not very exciting.
I can share a more recent mindset shift, which was in conversation with Clint (Valentine, VP of Operations at Fulcrum), in which he had the ‘spidey-sense’ that my clients at that time were more transactional — I hop in and out, I give updates, but there weren’t really opportunities then for deeper connection. I think just being more open to unstructured/orthogonal conversations is useful because it opens up the possibility to work with clients on new projects and identify blindspots – it lets us sample more of the problem space. I was so focused on tackling the problem space as listed in “the spec”. However, our work is not only execution, which I was so obsessed about, but also identifying problems that the client has not yet articulated. I had been in a season of my career where I was prioritizing the execution piece over the listening piece, so it was really nice to think, with Clint, about how connecting with the clients more, listening, probing, sampling the problem space, is actually really fruitful! Even if it doesn’t turn into an immediate project it might spur an idea for the client, et cetera. And that makes us more fun to work with. Sometimes I might be kinda un-fun to work with, when I’m evangelizing Docker and infrastructure-as-code, writing READMEs, and all these operational things…. It was a mindset shift returning to fun and discovery!
What’s a recent project or insight you’re particularly proud of?
We’ve been mulling about pipelines for automations for a LONG time. We recently delivered a minimal viable pipeline for a client that required extreme rigor with the specification, and we did it, and it was awesome! And we realized the MVP can be non-trivial, and very useful. You can’t give a client a product that is scrappy and terse, because that doesn’t help. So even when you build a MVP it has to be robust, you have to very actively de-risk.
If you want to automate something you have to really understand its inputs and outputs. You have to ask yourself if you really need the automation. You can ask me to spend 25 hours building the automation. Or you can ask me to spend 25 hours teaching you how to build an automation in the future. I think the latter is both more fun for me and sometimes that exercise is more useful to the client.
If you could give biotech startups one piece of advice, what would it be?
Don’t assume that your inputs are good.
If you don’t have provenance don’t automatically believe your inputs. What are a project’s inputs and outputs? You don’t need to be a bioinformatician, computer scientist, or a software engineer, to answer (or ask) these questions. But that kind of “functional” thinking does help.
What’s something outside of work that inspires how you think about problem-solving?
One thing I think doesn’t get spoken to enough is that a lot of Fulcrum employees are very good communicators, which is not something that we sell, exactly. It’s more “problem solvers” or “whiz kids” or like “brains for hire”, but really what clients often need are domain experts that can speak their language. Communication is very important and it informs how I solve problems because if you solve a problem and can’t communicate about it then that solution is useless.
I’m trying to avoid the cliché but here’s the cliché: the rock climbing I do is really interesting because it’s all about how you map a path forward, once you map the path forward how do you produce it — and that’s how you problem-solve. It’s not only how do you do it once — it’s how do you do it once, well, and then do it well again, and again, and again? And a lot of that is just simply “can you do the basics well? Is your footwork good?” And that for us the equivalent is “are your day-to-day engineering practices good?” and I think this mantra, this philosophy, of doing the simple things well really pays dividends. That means I’m not spending as much time worrying about the day-to-day atomic things, I can keep space to learn, and when we work with a client we’re sure that the individual pieces we produce are good. It’s core competencies.