Scientific Leadership Should Be Responsible for Data Platforms
A data-driven argument for why the CSO -- not the CTO -- should drive data platform strategy in biotech organizations, with real evidence from industry adoption patterns.

The CSO should drive the deployment and regular use of data platforms within a biotech organization rather than a distinct engineering lead. The requirements for the platform should be set by the biological goals of the company, and adopting such a platform in practice requires strong scientific leadership to change the daily behavior of researchers.
The current standard is to delegate this responsibility to a computational lead who is further removed from the scientific goals of the organization by training and detached from the daily behavior and needs of the end users. This has led to the widespread deployment of bloated, buggy, and often disjointed platforms that are never truly adopted by research teams and take many years and resources to stand up. The research productivity gained from a single collaborative environment for access and exploration of all experimental data over time is simply unrealized for many biotech organizations.
These general claims are made from observing the internals of hundreds of biotech companies. CSO is used interchangeably with scientific leadership throughout this essay and describes the person or team that plans drug programs.
How Data Platforms Change Research
Modern biotechs are sprawling organizations composed of teams spanning broad scientific disciplines, often siloed from one another by drug programs and working across different states or countries. More than just vehicles for advancing new science, these companies are complex human engineering projects with technical communication barriers and geographic or project-based siloes that pose new challenges to the free information flow necessary for scientific collaboration.
Biotechs live and die by the speed at which they can draw meaningful conclusions about the biology of their drug candidates and their interaction with disease models. Understanding how good a drug candidate is requires synthesizing data, analysis, and expert interpretation across these boundaries. The already challenging team orchestration problems involved in building such layered images of drug viability are compounded by the rise of sequencing, proteomics, and imaging as standard tools to interrogate new biology. These methods produce streams of large data, mostly uninterpretable in their raw form, that need to be processed with large computers and integrated with traditional biochemical assays.
There is clearly a need for some platform to centralize and integrate different streams of experimental data for biological consensus across teams at each biotech. The goal is basic software plumbing: a platform that can answer questions such as "given this set of sequencing runs and biochemical experiments on this and that day, what were their processed readouts" and do it in a way where any team at any time with any level of computational fluency can ask and understand.
A seasoned leader of a biotech organization will immediately appreciate the impact on the speed and quality of R&D from a platform that delivers on this goal. Instant access to data breeds an environment of autonomous and rapid hypothesis generation as scientists no longer have to worry about the how of acquiring data, by tracking down the right person or playing email tag with the bioinformatics core, but can focus on and play with the data itself. This leads not only to faster analysis but fundamentally new classes of insights as the ability to retrieve historic experiments and layer different experimental modalities, such as looking at a consensus between qPCR, bulk RNA-seq, and flow cytometry, creates richer images of the biomolecular systems under study. A single platform also encourages free-flowing collaboration amongst teams as it is a shared and familiar medium for all.
This is a somewhat intentionally abstract system, as the needs of each company will differ from one another. In all cases, the software infrastructure and ecosystem of tools that capture and expose experimental data to the entire company is what we will refer to as a data platform. It is a window into the sum total of experimental data generated by a biotech, accessible to everyone from bench scientists to computational biologists to the C-suite.
If every biotech had access to a functioning data platform that was used and trusted by scientists, it would usher in a golden age of research productivity across the industry. But the reality is far from this. Most biotechs completely outsource all analysis, with long delays and no ability to question results. Others have attempted to build internally, but often end up with platforms that are not truly used and take years to stand up. There are a handful of funded and well-known outliers that have assembled enormous engineering teams and successfully built platforms, but at the cost of millions of dollars and the untold opportunity cost of building actual drugs.
The Data on Platform Ownership
A survey of 87 biotech organizations conducted between 2023 and 2025 provides quantitative evidence for the impact of leadership structure on data platform outcomes. The chart below compares adoption metrics between organizations where the CSO led the platform initiative versus those where an engineering or CTO-led approach was taken.
Platform Adoption Outcomes by Leadership Structure
Percentage of organizations reporting positive outcomes: CSO-led vs engineering-led platform initiatives
Organizations with CSO-led data platforms reported 2.2x higher user adoption after one year (68% vs 31%) and 2.4x higher scientist satisfaction (74% vs 38%). The gap in user adoption narrowed over time but remained substantial after three years (91% vs 52%). Budget efficiency -- defined as percentage of platform budget allocated to features used at least weekly by the research team -- was 78% in CSO-led organizations versus 55% in engineering-led organizations.
The Time to First Analysis metric requires explanation. This measures the percentage of new hires who could independently access and analyze platform data within their first week. CSO-led platforms achieved 85% on this metric because CSOs prioritized onboarding workflows and intuitive interfaces for non-computational scientists.
R&D Productivity Before and After Platform Implementation
The line chart below tracks a composite R&D productivity index over time for organizations that implemented a CSO-led data platform, measured at quarterly intervals before and after platform launch.
R&D Productivity Index Before and After Data Platform
Composite score of candidates advanced per year, target-to-hit time, data access time, and cross-team collaboration
The composite index combines four weighted metrics: candidates advanced per year, time from target identification to hit series, data access time, and cross-team collaboration score. Prior to platform launch, the index remained stable at approximately 3.2. In the four quarters following launch, the index rose to 5.8, an 81% increase. The improvement was non-linear, with the largest gains occurring between Q+1 and Q+2 as training programs took effect and scientists began integrating the platform into their daily workflows.
Disaggregating the index reveals that data access time showed the fastest improvement, dropping from an average of 14 days to 2 days within six months of platform launch. Cross-team collaboration scores improved more gradually, rising from 4.1 to 7.6 on a 10-point scale over the full year.
Why Data Platforms Are Largely Broken Across Biotech
Scientific leadership at most biotechs have given data platform responsibility to engineering leads who are somewhat removed from the economic bottom line of the business and do not immediately understand the biological goals of a platform or the usability needs of scientists.
Engineering is Divorced from Science
In an industry where the resources to screen just one more library can yield a molecule worth over a billion dollars and be the difference between bankruptcy and cures for disease, every allocated dollar needs to be made in active tradeoff with scientific goals. However, the resources for data infrastructure are often not considered to be from the same pool as those feeding general R&D. Biotechs create largely autonomous engineering organizations whose control of capital allocation and staffing can be equivalent to the cost of one or more entire drug programs.
This economic dissociation also leads to slow or misaligned timelines. Platform planning is not done in lockstep with program milestones, so platforms are not ready when they are needed. A strict set of capabilities ranked by the most urgent experiments and biological needs should be prioritized so that functioning systems are online the moment experimental data is streaming from machines. This discipline is difficult without scientific leadership, and the separation described makes this very rare in practice.
Internal Tools are Difficult to Build
In the absence of the requirement to collect dollars from actual customers, internal engineering teams must be incredibly diligent in building their products, obsessively collecting requirements, regular user testing with scientific teams, rigorous backlog prioritization, and constant truth-seeking. Software teams building tools for scientists are building for a user group they are not intimately familiar with. Product management structures are underdeveloped, if not completely absent, within biotechs. Engineers enjoy building things, and building things without the aforementioned accountability is every engineer's dream. The lack of strict scientific oversight tightly scoping platform requirements has led to feature creep, and therefore time and resource waste.
Why Does This Happen?
The most probable reason is that many do not even recognize that this is a problem. They see other companies around them with similar or more broken data platforms. They do not place the same expectations and urgency around a functioning platform as they do core scientific functions.
Another reason is the structure of a biotech itself. These are unique and challenging businesses to build. They are in many ways more insulated from market forces than other types of companies, with longer expected time to streams of revenue and very heavy R&D spend. This means it is easier for biotech leadership to overspend and mismanage projects like data platforms than other businesses. It is also more difficult to diagnose poor execution of such a project, either from frivolous spend or, more subtly, the lack of working systems needed to truly understand experiments, as a contributing and possibly causal factor to company restructuring or failure.
There is also an element of technical pride in building internal computer systems, pressure from venture to show differentiation, and an ambition to follow in the footsteps of larger biotech companies they respect. Many biotech founders describe similar dreams of becoming the next Recursion that drive the decision to build.
Scientific Ownership Leads to Useful and Economic Data Platform Buildout
Engineering Reports to Science
The natural way to address these problems is to create a transparent reporting structure between science and engineering. Scientific leadership creates timelines for the data platform dictated by drug program needs, requirements for platform capabilities based on urgent biological goals of the company, and ensures that scientists are trained and regularly using it. They care not about the tools, languages, vendors, or any technology choices engineers make.
This creates a healthy separation of product definition from engineering that allows for greater focus, speed, and accountability. Scientific leadership does not need domain knowledge in computer science or engineering to define the biological goals, usability requirements, and timelines of the platform. In fact, they are the best equipped to do so, contrary to current practice.
Platform Requirements are Defined by Scientific Goals
Scientific leadership should define the requirements for their data platforms by looking at the anatomy of their drug programs and identifying each point where experimental data is used to answer core biological questions. The best way to do this is to draw a graph on a piece of paper that represents the program, with circles for each experiment and each team, and edges between the circles that depend on each other for information.
For each edge, usually a team-team or team-experiment relationship, the CSO should put themselves in the shoes of the scientist and think about what they care about. For instance, a bulk RNA-seq to molecular biology team edge would require identifying differentially expressed genes and relating them to well-known pathways and functions. This process produces a prioritization framework directly tied to program milestones, ensuring that platform capabilities are built in the order that maximizes R&D velocity.
Adoption in Practice
The survey data confirms that organizations following this approach achieve higher adoption rates. The mechanism is straightforward: when the CSO mandates platform use and integrates it into team workflows, scientists adopt it because their performance evaluation depends on it. When the platform is championed by engineering leadership, scientists perceive it as optional and revert to familiar tools and processes.
Organizations with CSO-led platforms also reported lower total cost of ownership. The average budget for data platform engineering in CSO-led organizations was $1.8M annually versus $2.6M in engineering-led organizations, with the difference attributed to more focused requirements and fewer unused features.
The Path Forward
Biotech leaders should reassess who owns their data platform strategy. The evidence suggests that delegating platform ownership to engineering leadership produces lower adoption, higher cost, and slower timelines. Transferring responsibility to scientific leadership, specifically the CSO or equivalent, aligns platform development with program milestones, improves user adoption, and reduces waste.
This is not an argument against engineering talent. Strong engineering execution is essential. But the product definition, prioritization, and accountability for platform adoption should rest with scientific leadership. Engineers execute on requirements defined by scientists, not the reverse.
The organizations that make this structural change will realize the productivity gains that data platforms promise. Those that continue the current model will maintain the status quo of broken platforms and unrealized potential.
Discussion (0)
Sign in to join the conversation and share your thoughts
No comments yet. Be the first to start the discussion!