In my last post about development principles for Biotech data teams, I wrote about the importance of getting data into FAIR systems and noted that it’s not enough to have FAIR data systems; your lab teams need processes that ensure they use them. This week’s principle makes this a more general point:
Technical tools can only be effective when deployed in the context of good processes and communication patterns.
This is a more wordy version of a mantra I’ve repeated a number of times in this newsletter: Bad software is a symptom not a cause. A team can only use software effectively if the ways they work and think about their work are effective. If you try to fix a team’s problem by swapping out the software without addressing the processes around the software, they’ll just find a way to continue the ineffective processes with the new software, or they won’t use the new software at all.
So one option is to throw up your hands and give up - If a technical solution won’t solve the problem, then it’s someone else’s problem. But if that’s the option you choose then you haven’t been reading the earlier principles in this series. Adopting broader, scientific objectives over immediate technical goals means that this is very much your problem. And developing better communication with your colleague teams gives you the tools to do something about it.
Whatever tools you’re working on right now, or whatever you’re going to work on in the future - Don’t just build them to reflect the existing process if that process is flawed. But also don’t just build for some new, idealized process that is completely foreign to the target users. Instead, before you start building, work with your colleagues to identify processes that work for both your needs and theirs, then work with them to roll out the new process along with the tooling.
Don’t just treat the symptom. Solve the problem.
Concerns with FAIR process mgm't are valid. Typically, there are executive or client mandates to deploy one method or another, and more typically the task is handed off to an underperforming member of the team. This can be fatal, as layer upon layer of paper trail is now generated, along with infinitely recursing signature cycles. Better to have the most productive team member tackle it. Biology is not cheap to do well, and reproducibility (the younger sibling of scalability) is key. A little 'deliberate empathy', as you've mentioned, won't hurt either in getting to pragmatic and functional processes.