R&D teams spend a lot of time and thought keeping up with the latest tools to apply to the newest biological frontiers, but employee training initiatives often focus too much on increasingly specialized individual skill sets and less on overall team structure. It’s not hard to imagine why: big-picture processes like managing team dynamics are tricky when there’s so many moving parts, from tools, to projects, to people. Here’s how to keep up by breaking work into shareable and extensible units, owned by the team.
Shareability
People are drawn to bioinformatics because it can be rewarding to work between disciplines, constantly learning how to apply what you already know to an area that’s new to you. The work is notorious for being “routinely unique”, and as an unfortunate result, shareability — the ability to hand off a self-contained piece of work for someone else’s reuse — often suffers.
The mindset that each project is unique, combined with a near-constant need for results yesterday can lead to default behavior where day-to-day work and tooling is also treated on the fly. We end up with code written to be individual, immediate, and one-use only. Once a project has met the basic milestones, bioinformaticians are rushed on to the next project.
Trying to tie together legions of tools purpose-built for highly specific problems after the fact is incredibly difficult. Just like the large-scale biology questions they help answer, bioinformaticians have a massive variety in style, expertise, go-to tools, and skill sets.
Ways to make code shareable include commenting it thoroughly, writing documentation, tracking version control, and using containers. Investing in tools to make these practices automatic lets your bioinformaticians focus on solving the biological problem at hand rather than spending time trying to get things to run. An up-front focus on shareability is a short term investment with long term gains as switching between projects and onboarding new team members become easier.
Extensibility
Extensibility builds on shareability. It’s common that team members end up attacking similar biological problems but from different angles — although there’s a lot of overlap, the intersection between projects is not perfect and while code is similar, changes have to be made for practically any analysis. Making those changes easy is the core of extensibility.
On a practical level, extensible work means designing well defined, contained code blocks to execute everything needed for a defined process step (“separation of concerns”), and interfaces to allow these blocks to connect. One example of how to make work extensible is standardizing input and output data formats, and another is to surface as many variables and processes as possible. Another way to approach this is to build code blocks as templates, or as components to be connected using a pipeline scripting language (learn more about automated pipelines).
Getting input standardized might involve conversations with your data management or procurement departments. This is also a great place to have discussions with biological experimentalists, and to integrate with their experimental planning process. You may already have meetings for power analysis and experimental design, so consider fitting data formatting into these as well. If you don’t already have these planning meetings, data ingestion standardization is a nice and neutral place to start. These integration meetings will go better if you can show that feedback is valued, and that the changes you’d like for data ingestion are a part of your broad plan for analytical speed and efficiency.
Standardizing output overlaps more with biology and clinical teams – eventually this democratizes a lot of time-consuming “data feeling” and allows biologists to contribute meaningfully. An actionable goal is to get biologists and managers to come to your team’s platform for their analysis and metrics, without ever knowing or needing to write code. Instead of doing their own analysis in non-traceable tools like Prism or Excel, they will be empowered to load their data into a standardized module and run it. This provides the team with needed quality assurance on their work, and saves the biologists time. It also keeps data flow continuous and ready to be used in the next project, ensuring the long-term impact of your work is traceable.
Leaders also have to consider how to extend work into their company’s business practices. Ensure that improvements are tracked using business-critical metrics by maintaining powerful and meaningful analytics dashboards. Teams can measure how many times and by what teams their work is re-used, and can track time-to-analysis completion of projects. You want a team that is not only excited but incentivized to think as a team.
Team Ownership
Together, a practice of shareable and extensible work allows for team ownership, where everyone should feel not only responsible for their own work but the success of the entire team. Leaders can enable ownership by making people responsible for process improvements, and empowering them to make those changes. Empowering team members means investing in the resources they need to succeed. It also means a mindset shift — in this paradigm everyone genuinely feels ownership over team-wide successes. Every team member should be encouraged to think about what their “team” is, and how to involve them. To get buy-in, emphasize long term gains: each time team members are doing something, they’re also working to ensure that next time, it will take five minutes.
Once this system is in place, have a plan to monitor it as well, including what maintenance tasks need to be considered and how frequently. We suggest having these check-ins early and often. The specific benchmarks and reporting/informing structures here will vary from place to place, but the important thing is to have the conversation once everyone is invested in your system and give everyone a genuine voice and support to truly own and direct their work towards meaningful insight, whatever that means within their job function.
Scope modular components broadly. They can center around biological, technical, or support and maintenance topics. Proteomics could be a theme to own, or genetics, dimensionality reduction, clinical data cleaning, standard plot type formatting, and so on. Then, the team should match areas with those interested in and capable of owning them. Those individuals will create the group standard for specific analyses and project components, will train others in using them, and provide support and updates. Care should be taken to ensure this standardization isn’t just everyone abiding by a dominant team member’s standards. Rather true consensus is a feedback loop, where all users have a meaningful voice.
Give people ownership, resources, and structure to effectively contribute at the team level, and everyone’s life will be easier. Workers will be more engaged and also much more capable of responding to inevitable change and scale. Start where you are and make a plan. Hopefully this has given you a good outline to start from!
