Yes, it is your problem
One of the assertions of the Reciprocal Development Principles is that data teams in biotech should set goals around, and generally be accountable for, the downstream impacts of their technical work. This week, I want to explore why that may be true for embedded teams in a way that isn’t true in traditional Tech. This will involve some broad generalizations, but bear with me.
Big tech companies with millions or billions of users can rely on fairly consistent statistics about their user base to determine how technical changes to their product will affect (aggregate) user behavior: They know what percentage are early adopters who will try a new feature on the first day it appears, and what percentage will wait until they read about it on their social media feed. They know how much ad revenue will increase if they shave 10 milliseconds off a query. So if a developer focuses on accomplishing their technical goals, they know it will take care of the business goals.
You, on the other hand, don’t even have thousands of users, let alone millions or billions. You have Joe in virology and Mary in translational genomics (or whatever their names are). So you can’t rely on statistical trends to ensure that your technical goals translate to business outcomes. If you aren’t accountable for the scientific/business outcomes, they probably won’t happen.
In other words, you goal shouldn’t be to build the thing that allows Joe to process samples twice as fast. Your goal should be for Joe’s sample output to double. Which means not just building the tool, but making sure Joe can and does start to use it. If Joe is an early adopter, that makes your life easier. But if not, then that’s your problem too.
And if Joe doesn't see the point in using your tool---it might just be that the tool shouldn't be there.