{"id":6569,"date":"2023-03-15T19:42:57","date_gmt":"2023-03-15T23:42:57","guid":{"rendered":"https:\/\/ptp.cloud\/?p=6569"},"modified":"2025-06-15T22:31:16","modified_gmt":"2025-06-16T02:31:16","slug":"avoiding-biotech-data-team-stall-a-review","status":"publish","type":"post","link":"https:\/\/ptp.cloud\/avoiding-biotech-data-team-stall-a-review\/","title":{"rendered":"Avoiding Biotech Data Team Delays – A Review"},"content":{"rendered":"
by Scott Scheirey<\/em><\/div>\n
<\/div>\n
<\/div>\n
In between work, bombing ski runs and taking my dog out to play, I had the opportunity to read Jesse Johnson\u2019s recently released Leading Biotech Data Teams<\/a>. His message really hit home for me, and if you\u2019re interested in early-stage biotech research, I\u2019d highly recommend giving it a read. Jesse\u2019s suggestions that \u2018perfect is the enemy of good\u2019 and that often \u2018data driven biotech\u2019s experience bottlenecks\u2019 both triggered thoughts that lead to this blog. This is not a full summary of the report, rather a highlight of common trends I see among data teams that create friction and contribute to the delay of progress.<\/div>\n
<\/div>\n
Before I offer my perspective, it will be helpful to review the three main sections Jesse outlines in the report that create an impediment to progress.<\/div>\n
<\/div>\n
<\/div>\n
    \n
  • Defining Objectives<\/strong>: Technically your job is to advance your company\u2019s scientific research first and foremost.<\/li>\n
  • Building Collaboration<\/strong>: Biotech to Wet Bench and Data Teams need to collaborate to be a successful biotech.<\/li>\n
  • Deploying Tooling<\/strong>: Collaboration is important throughout the process, and perfect is the enemy of good. You need your team\u2019s input to deploy tooling that is useful to your team.<\/li>\n<\/ul>\n

     <\/p>\n

    The Smart Factor<\/strong>
    \nJesse refers to \u2018data teams\u2019 as any mix of individuals specializing in the bioinformatics, computational biology, machine learning, data science, software and data engineering disciplines. I find that each individual that makes up a data team is bright, has advanced degrees, and has dealt with and overcome the trauma and hierarchy drama that\u2019s often involved with graduate education in STEM. However, when everyone in the room has a different idea of what steps are needed to drive research forward, the room divides. If you\u2019re not on \u201cmy\u201d side, you must not be that smart after all.<\/p>\n

     <\/p>\n

    Role Identification<\/strong>
    \nThis is a major issue I notice on many data teams. Team members enjoy learning new things, creating new things, and seeing their efforts turn into something they see as purposeful. The question is SHOULD they be investing on the side quest? To explore this, I offer common traits your data team members share:<\/p>\n

      \n
    • Tremendous pride in building something cool.<\/li>\n
    • Passion for learning.<\/li>\n
    • Willingness to say \u201cyes\u201d (and possibly over-commit).<\/li>\n
    • Experts in their discipline.<\/li>\n
    • Independent and accountable (and limited collaboration).<\/li>\n<\/ul>\n

       <\/p>\n

      I\u2019ve encountered the side quest dynamic many times relating to pipeline building and implementing AWS technologies, among other scenarios. For example, a computational biologist is excited to build new pipelines from scratch but has over-committed to their projects. There is excitement in the challenge to build something that requires additional learning, but likely is not the avenue that provides the most business or scientific value to the company. This can cause significant friction in teams and is why companies leverage technologies, platforms, and tools to accelerate this process (i.e. Nextflow).<\/p>\n

      Another example would be people building shiny new dashboards that took entirely too long, without enough input from other team members, which ultimately gets canned for a much less pretty dashboard that was done quickly (matching the demand \/ scientific needs of a company) that took incorporated a broader input.<\/p>\n

      Sometimes the side quests your team are on have been facilitated by other scientists who \u2018need this data really quick\u2019. In more extreme scenarios this causes the data team to explore more ways to help other less code-friendly folks \u2018self serve\u2019 on their data. Building new things in house, that hopefully the team likes, or paying for some sort of platform to achieve this to the best of their ability \u2013 they\u2019re never perfect.<\/p>\n

       <\/p>\n

      Cloud Architecture<\/strong>
      \nOther scenarios we see at PTP involve AWS cloud architecture. Teams with a scientific focus are spending time to learn more about AWS, provisioning new resources, and spinning up instances. This could be a useful skill, but not a skill they plan to have as their \u2018main focus at their company\u2019. Which inherently allows your teams to be more self-sufficient in using compute, with a lack of oversight, driving up costs at organizations.<\/p>\n

      Ultimately the architecture that has been built works, but has points of failure, and costs entirely too much. We\u2019ve started working with companies where we were able to reduce spend by 70% by implementing an appropriate architecture.<\/p>\n

      It reminds me of my organic chemistry courses where you\u2019d lose points on a synthesis diagram if it could have been done in fewer \/ more efficient steps. The reasoning behind it is that industry wants scientists to get results quickly and reduce spend wherever possible.<\/p>\n

      Reading Leading Biotech Data Teams<\/em> certainly stirred up thoughts and emotion in me, something a lot of people in our industry share. My belief is that building a successful data team requires people to be laser-focused on their goals, to effectively collaborate with different team members, and that perfect is the enemy of good when deploying tooling (and in a lot of scenarios). Get that prototype out there, perfect it, and best of luck on the path to IND!<\/p>\n

      <\/h4>\n

      <\/h4>\n

      How can PTP help with CloudOps Services?<\/h4>\n