Flagship Pioneering Lessons Learned Launching Biotech Startups

By Allison Proffitt 

May 23, 2024 | John Damask is a cloud proponent; he makes no apologies for that. And his experience has mostly been with Amazon Web Services; he is clear on that too. With those disclosures out of the way, Damask offered a “Choose Your Own Adventure”-style tour of cloud best practices and the most common startup cloud mistakes at last month’s Bio-IT World Conference & Expo, letting the audience choose the topics he dug into during the talk.  

Damask is VP Data & Systems Engineering at Flagship Pioneering. Flagship raises money like a typical venture capitalist, he said, but then deploys that money to fund its own ideas, generally not bringing in other investors until Series B. Among Flagship’s successes: Moderna, Generate Biosciences, and Seres Therapeutics.  

Startups have a unique phenotype, Damask pointed out, highlighting their scrappy personas; limits to time, money, and people; and steep learning curves. Established companies have their own constraints, of course—inertia, ingrained culture, and legacy systems, for example—but the cloud is often viewed as a unique solution to startup challenges.  

Flagship has experience shepherding small companies through the cloud growth process, but there have been missteps along the way as well. Damask highlighted several of Flagship’s first cloud assumptions that ended up calling for more nuanced approaches. In each case, the “easiest” solution turned out to be too narrow or shortsighted for the young companies in Flagship’s portfolio.  

For instance, Flagship originally believed that outsourcing cloud expertise to a managed service provider was the most efficient way for a startup to grow. But in reality, service providers are most valuable when they are also helping build institutional knowledge within the company specific to the company’s science, people, and goals, he said. Flagship set up its own center of excellence to help startups build their own strong foundations.  

On Taming Cloud Cost Chaos 

Cloud costs are a particularly sneaky challenge for companies as they grow. Brand new companies with only a few users start using the cloud to facilitate research. Everyone is an admin; everyone can create resources.  But as funding comes in and headcount grows, that approach to cloud usage can lead to skyrocketing costs and a disorganized cloud environment with no one keeping track of costs. Instead, Damask recommends being careful to organize workloads and tag resources. Very early on, he says, companies should appoint a competent Head of Cloud Operations of oversee cloud use.  

Although he promised to stay out of the pulpit, Damask did save one slide for a sermon of sorts on the major Dos and Don’ts for controlling cloud costs. Don’t focus only on workloads and ignore the accounts, he said. Don’t think good DevOps practices in your engineering groups negate operations. And don’t assume you won’t have long-lasting cloud servers—you will, he says; treat them as “cattle, not pets” he advised.  

Instead, do create a multi-account strategy with a simple landing zone that makes it easy to scale and conduct regular housekeeping of cloud space. He advocated using the cloud service provider’s security and cost explorer dashboards weekly, and looking for new-business savings plans and spot instances to maximize value. Finally, he stressed the importance of setting up—and regularly responding to!—budget alarms. The cost threshold doesn’t need to be so low that the alarm is frequent and inevitably muted but should be high enough to protect new businesses from overspending, either in-house or, “if you get hacked and somebody tries to set up Bitcoin farms on your dime!” He suggested setting an alert at $1,500 a month to start and adjusting up or down as needed.  

On Standards for a Multi-Cloud Environment 

Even the most careful startups can quickly find themselves in a multi-cloud situation, Damask said. They start with research computing on AWS, add the Office suite from Microsoft with access to Azure, and then add a data science platform built on Google Cloud.  

“You’ve got problems to deal with,” Damask said. “You can’t answer simple questions like, ‘What’s your total cloud spend? What’s your security posture across all of these? What’s your support strategy for the people who are working in these clouds? You run into situations where you lose track of your data because there’s duplication that happens across clouds, but it’s not managed strategically. And you have problems because there’s no decision tree to decide: ‘When do I do something in Google? When do I do something in Azure? What do I do something in AWS?’” 

The solution calls for a shift in thinking. While he concedes that a multi-cloud situation is generally inevitable, he advocates for choosing one cloud vendor as the source of truth for critical company data and thinking about cloud as a service provided by the company’s IT, digital, or data science department, he said. 

Startups should take advantage of services offered by cloud providers to maximize agility and productivity. Yes, there is some vendor lock-in when you don’t engineer services yourself, but that’s a worthwhile cost compared to business goals, he said. Tie cloud budgets to business units, he advised, and prioritize continuous employee training, building internal expertise in security and financial operations.  

At its most basic, a company’s cloud strategy should outline standards around who can set up cloud accounts and when, configuring a landing zone, assigning administrator roles, choosing support tiers (Damask recommends AWS Developer tier for most startups), visibility, and the core cloud services with which to begin.  

On Empowering Your People  

We know empowered people are free to be productive and creative, and—especially for startups chasing their next funding round—productivity matters. But in his experience, Damask has not found that everyone needs full freedom to be productive. “If you’re thinking, ‘Oh, the people who use the cloud want to have full control,’ that’s only part of the story. We also run into people who don’t care about their freedom. They just want the solution; they want it to happen quickly.”  

Rather than pure freedom, Damask suggests empowering your teams with training. Flagship initially believed that simple AWS onboarding was sufficient for new computational employees at portfolio companies. But they’ve since realized that the vast majority of new employees—more than 90%—have little to no cloud experience, he said.  

Instead, he recommends onboarding on the top services computational employees will use: your main cloud storage, your main virtual compute, your main parallel compute. “All of these cloud vendors have hundreds of services now, and it’s a very difficult learning curve to manage,” he said. “But honestly, if you focus on [these], you’re going to cover probably 80%, 90% of the use cases.” Other use cases are edge cases, he said, specifically highlighting engineers and infrastructure-as-a-code.  

On Operations 

Many of the traditional IT Service Management best practices apply to the cloud too. Operations are still needed to support people, manage incidents, and handle big changes.  “DevOps will not save you. I believed it would at one point; I was dead wrong,” Damask said. A great operations person may be an engineer, but he or she may also come from a more traditional operations background and really like process automation and coding.  

Quarterly reviews are crucial to check in on spending, accounts, active users, performance, and other metrics. At Flagship, they find the two-by-two review matrix of Highlight, Lowlights, Opportunities, and Risks to be a useful framework.  

Sandboxes and Playspaces 

“Sandbox accounts are now considered standard. I personally don’t think they’re useful.” On this point, Damask was definitive. “The challenge with sandboxes that I’ve found is that when people want to learn how to use the cloud, they actually want to do it in real work scenarios… I think people learn through their projects; they learn from using real data.”  

The real data is the challenge. Inevitably using real data means doing real work in the sandbox. If there’s company-critical data in the sandbox, “it’s not a sandbox; it’s a workload account,” Damask warned.   

Don’t segment your cloud into “play” and “real work,” he advised, quoting NASA’s Jet Propulsion Laboratory: Today’s toy is tomorrow’s tool.