7 Truths of Data Sharing
This is a series by David Goodman, VP of Learning and Impact, on data sharing. David shares what he's learned over the past decade about sharing data within and across organizations in a series of posts. The 7 Truths are based on David's work in research; evaluation; collecting, managing, and governing data for organizations; and leading collaborations to share and use their collective data.
Truth #1: There is No One Data Sharing Model "to Rule Them All"
The reason for this, however, makes complete sense: each agreement must be tailored to each organization's specific needs, requirements, preferences, and capacities. There are simply too many factors that influence whether two or more organizations should, can, or will share data. Consider the type and amount of data being shared (individual vs. aggregate; sensitive vs. confidential), the proposed uses of and access to the data, the experience and expertise of the organizations, and even the trustworthiness of your potential partners. All these factors will result in different requirements, permissions, conditions, and constraints for each participating organization. Once you have these for each organization, you must find alignment and agreement among your data sharing partners. This takes time and requires adjustments and considerations to meet each organization's needs—especially for organizations that haven't previously worked together.
Are there tools, guides, or templates that can help speed up the process? Of course, but even those should be used as guides or baselines to build from. Find a similar data sharing agreement or how-to guide (ask me for one!) and figure out what works and what doesn't, what can be leveraged and what needs to be changed or adjusted. This is an excellent exercise for aligning with your data sharing partners, as well as internal teams within your organization.
There's simply no way around this part of data sharing. Is it difficult, tedious, and sometimes frustrating work? Yes, but having this clarity and understanding—both internally and externally—will significantly improve and expedite the data sharing process. It can also be iterated upon and updated to make the process more efficient and effective over time. I promise it gets easier the more you and your staff engage in the process, especially if you choose to work with the same organizations repeatedly.
Even more important, however, is that this process of identification and negotiation is where the true value lies: the ability to learn and compromise builds trust, understanding, and appreciation among partners (and colleagues!) that can lay the foundation for sustained and respectful sharing over time.
Truth #2: Data are Shared at the Speed of Trust
Truth #2 may sound cliché, but there's no truer statement when it comes to sharing data between organizations: data sharing moves at the speed of trust.
Sharing data outside your organization can be scary and risky—not just because of potential threats to your organization, but in situations where data concerns individuals, groups, or communities, the threats to their well-being and safety are even more serious.
Threats of breach or unauthorized access are always top of mind when sharing data, but even more so when you've never shared data or had a relationship with your sharing partner. If trust exists—if you know the other organization's staff, if you've had positive, secure, and productive data sharing with the organization in the past, and the organization did exactly what they promised—data sharing can be relatively easy and quick, or at least more efficient.
Organizations that trust one another can move quickly, with the confidence to share even sensitive or confidential data, knowing it will stored and managed appropriately and be used appropriately and as agreed upon.
Keep in mind: you shouldn't be deterred from sharing data with a partner where you haven't established trust, where trust is limited, or even where there's distrust! It is important to look at these as opportunities to build and nurture trust, especially with a partner that possesses or controls data you know your organization will routinely need in the future. The key is to move forward cautiously, incrementally, and respectfully. Start small and share data or information that's less sensitive and complex at first. If that experience is positive and each organization follows through on what they've agreed to do, then leverage that trust to partner on a new project and explore sharing more complex or sensitive data.
Just like in other aspects of our lives, data sharing trust is fragile, so be patient, respectful, and build it over time. Learn about each other, be honest and transparent, find ways to support one another, and think about your work together more as a relationship and less as a transaction.
Lastly, when I use the term "trust," I mean the confidence one organization has that their data sharing partner will perform and share data as agreed upon in a manner that's both respectful and in the best interest of the other organization and the partnership. I added "respect" and "best interests" because too many organizations claim they're building or establishing trust, but are just attempting to impose, mandate, or engineer it. These organizations are often in positions of power and don't always have other organizations' best interests in mind. That's not trust—and neither is demanding trust that hasn't been previously negotiated, bargained for, or reciprocated. There's no shortcut to trust, but it's worth building and will often provide benefit and value beyond the data and initial sharing over the long-term.
Truth #3: Data Sharing Should Be a Selfish Practice
I know Truth #3 is going to sound weird following a conversation about building trust and respecting your data sharing partners, but the reality is that organizations can both trust one another and act selfishly when attempting to share data.
This makes sense when you think about it: sharing data is hard, involves significant risk, and takes valuable staff time and resources on top of the routine work an organization is already doing. Asking another organization to engage in additional work to share their data "altruistically" can be a lot, especially for those that are already spread thin or don't have many resources to begin with.
So one of the best ways to overcome these barriers is to find additional value or benefit in sharing your data. That's right: be selfish. Ask for something in return to justify taking on the additional burden and risk and, maybe most importantly, asking your staff to do additional work.
In the past, in the absence of purely altruistic incentives, my teams often tried to find common pain points, challenges, or goals that might compel organizations to work together and share their data to address them. While this was often successful, it also took significant time and energy to identify the common pain point and get everyone aligned on the goal and how to achieve it. Even under these circumstances, organizations struggled with commitments and buy-in, and sometimes they ended up not participating because of staff burden, risk, or limited resources.
It wasn't until we started asking about individual challenges or limitations to their work that we might be able to solve or support through this process and this is where their eyes lit up and staff really began to get interested. Miraculously, when you suggest that you can address one or more of their ongoing struggles, pain points, or limitations in exchange for sharing their data, many of their initial fears suddenly disappear or don't seem as insurmountable. Most staff never thought about asking for something in return and simply said "no" or "we can't" when asked to share data, except of course when leadership or a funder or the government mandated or imposed it.
While I often direct organizations to offer this "quid pro quo" there's no reason why this can't be a routine part of the data sharing process. Of course, we want organizations to share their data to do "good," but in instances where altruism just isn't incentive enough, partners should be open and willing to bargain for and negotiate their needs when discussing data sharing. Whether it's leveraging your partner for other resources, guidance, or staff expertise ("soft" infrastructure) or their systems, tools, storage, or software ("hard" infrastructure), finding something to incentivize another organization to share data is perfectly acceptable.
Truth #4: Start Planning Early and Meet Partners Where They Are
So far, we've talked about trust, why your organization shouldn't take shortcuts in data sharing, and how being selfish when asked to share your organization's data actually helps build valuable trust and understanding among partnering organizations (and your own staff!). But even when your organization wants to share their data, where trust already exists with your partners, and the benefits are evident, data sharing may be too complex, too time-consuming, or it may simply be the wrong time.
Despite all the signs pointing to "yes," your organization may not possess the expertise or proper systems to share data and may still be limited in time and resources. Data sharing is as much about capacity and burden as it is about value and benefit. Organizations looking to share data with each other must understand these critical factors before they agree to move forward as well as how and when to move forward. This knowledge and understanding will allow you to meet each other where you both are. Your data request should reflect what you and your potential partners are realistically capable of doing in general and at that specific moment.
The message here is to do your homework and plan early. If you know you're going to need data from another organization, connect and gauge not only their interest but also their capacities to do so. This is especially true for organizations you've never shared data with previously, or if there's a new person responsible for making and facilitating data sharing requests (and it's very likely these involve multiple people in the organization).
If the organization is interested, find out what their data sharing capacities are: Do they have staff experienced in preparing data for sharing? Are your data requirements aligned with their current configurations or do they represent additional time or complexities to prepare the data? Have they used APIs or upload portals to facilitate data transfer? Are the staff knowledgeable about facilitating data sharing when needed? This is also where you can attempt to sweeten the deal by offering services, capacities, or funds, if available.
The more time you can spend discussing these factors with another organization, the better. It will go a long way if you meet them where they are and begin to build the trust and respect that will get you closer to "yes". If you wait until the last minute to start this process, even if your data sharing request is mandated or part of a funding requirement, you will create animosity and frustration with the organization's staff. Be respectful of staff time and resources.
One last point about this truth: As much as this is about starting early and understanding the capacities of the organization you wish to share data with, you should also do this with your own organization. Your staff are busy, and requiring them to do last-minute data sharing or imposing requirements they're not prepared for or capable of—either from a "hard" or "soft" infrastructure perspective—risks creating animosity and frustration and does more to damage organizational culture than just about anything. No one's going to want to eat lunch with you or invite you to company events. You might even find yourself receiving some strange looks around the office or on Zoom. Be nice and courteous; plan ahead and give your colleagues a heads-up.
Truth #5: Data Sharing is More Efficient, Manageable and Sustainable When You Start Small
On top of meeting data sharing organizations where they are, it's always advisable to start small when working with new data sharing partners or with organizations you know to be capacity-strapped. Starting with a smaller data request—or one that includes less sensitive or complex data—provides an opportunity for staff to get to know one another and build valuable trust and understanding. It also allows staff to test your agreed-upon data and technical specifications and identify any issues that may delay or frustrate the data sharing process. Starting with a smaller or less complex request will minimize disruptions and frustrations as well as the additional burden data sharing puts on staff.
A smaller, less complex data sharing request also helps with any data sharing agreements your organization may need to spend time developing or adapting for a new or existing partner. This is an often-overlooked area: governance around data sharing is a critical component to this work and can be much easier with fewer and less sensitive/complex data or proposed uses that you can grow over time. This creates an opportunity to move away from one-off, transactional data sharing agreements and explore frameworks that enable ongoing, iterative partnerships that allow organizations to evolve, expand, and sustain their sharing and use of data. These "collaborative governance" frameworks are ideal for organizations and collaborations that intend to engage in ongoing data sharing, don't want their agreements tied to individual staff members, or don't want to start over every time they want to add new data, approve new uses, or extend the work beyond the initial timeframe.
Aside from the practical and operational reasons for starting small and with less complex data sharing requests, another important reason is that these smaller steps help build valuable trust and understanding that become steppingstones to more difficult and complex sharing and engagements between organizations. At a time when it's harder than ever for an organization to survive—with funding cuts and uncertainty, under more intense scrutiny by funders and government—they must find ways to do more with less.
This is where these small steps to sharing data can be leveraged to do more work together—whether to support each organization's individual goals and challenges or even deciding to work more broadly to address goals and challenges together. This isn't to say that organizations that haven't shared data can't or shouldn't explore these types of collaborations together, but those that have—and have begun to build trust and understanding—are going to be ahead of the curve and able to move more quickly than those that haven't worked together in the past.
Truth #6: Data Sharing Frameworks and Approaches Can (and Should!) Change Over Time
Here is yet another truth that may upset some folks, especially program officers and research and evaluation folks who have fought tooth and nail to keep their grantees/clients within the models that they know well and have experience with. These are folks get uncomfortable when they have to deviate from what they know. This truth is also likely to upset or frustrate those entrenched within the traditional data sharing environment. Too many folks believe (maybe "hope" is a better word) that once they spend the time and resources to develop and execute a data sharing agreement, they can simply put it on auto-pilot and the data sharing will just continue with little effort and minimal disruption. I know of a few legal counsels and legal consultants that very much want you to just keep doing what you're doing and not to ask any questions.
While it is definitely possible to successfully leverage the same agreement or framework over time, they're likely doing so out of convenience and at the expense of learning and evolving—both for your program, your organization, and the organization you're working with. The agreement you started with likely represented your thinking and understanding at the time, as well as your data, technology, and governance needs, realities, and assumptions. Things change, however: maybe your organization decided not to "ditch the final report" and actually learned something because of the work or found out that an intervention or approach didn't work; maybe new data, technology, or restrictions were introduced or became available; or maybe your organization built more trust with your data sharing partner and they're now more comfortable sharing more sensitive or complex data. In any of these scenarios, your approach to the work is likely to change and that may mean a change in the data you request or the things you want to do with the data. At the end of the day, your data sharing framework and approach should change over time; it’s the natural evolution of this work and the relationship with your data sharing partner.
One way to accomplish this is through periodic check-ins with your data sharing partner to review the work or your data sharing agreement. I suggest annual or bi-annual check-ins depending on the data, the specific work, or the relationship with your partner. Let them know what you're learning and provide evidence of the need for changes to the agreement. If your partner is also involved in the work or intervention, this is a great time to share your findings and improve their knowledge of what you're experiencing. These check-ins are also a great time to gauge how the relationship is going, discuss if any changes to staffing, structures, or procedures are needed, or to introduce and get new staff up to speed so you can minimize any disruption from future shifts in staff roles.
I get that this isn’t the most fun. It's work and requires you to monitor what's going on and adjust your data sharing as needed, but it’s an important part of the work. If you're requesting data and using it to examine critical societal outcomes and you are serious about improving the lives of the individuals, groups, and communities where you work, then this is definitely a worthwhile endeavor. The good news is that there are really smart people out there that can help here - provide you with new agreements or approaches and help you think through the evolution of your work, and how that can be incorporated into your data sharing. Definitely reach out if you'd like to learn more - we should be doing more of this sharing and helping anyway.
Truth #7: Data Sharing Needs a Champion & Comprehensive buy-in
I've saved probably the most important truth for last: none of the other six truths I've discussed here mean a thing unless you have input, approval, and buy-in from across all relevant teams in your organization. Obviously, leadership buy-in is critical, but there's nothing more disruptive and frustrating—and detrimental to organizational culture—than receiving a completed data request that you didn't have an opportunity to review and provide input on before it was agreed to. At the end of the day, you're going to do what your boss tells you to do, but the most effective, efficient, and appropriate data sharing agreements and processes engage relevant team members early (and often) and make them part of the process.
This isn't just the team data owner or the system administrator—it's also representatives from the research, IT, program, legal, communications, and admin teams. Each of these teams and departments has a role in the data sharing process, and thus the specifications that go into the agreement. Whether it's to provide input on data, technical, or governance specifics; the timing of sharing or availability of data; any internal or external legal or ethical restrictions or constraints; or simply awareness that data sharing is taking place, each of these teams needs to have the opportunity to participate.
The reality of this truth, however, is that this is hard to do. Engaging with each of these teams, finding out who on each team needs to be involved, and coordinating input, feedback, and ongoing updates, is time-consuming and often, it’s not a specific role in an organization. However, without a data sharing champion who understands the value and challenges of data sharing, initiatives falter when obstacles arise, and organizational culture suffers when a critical team or role is left out of the conversation.
The easiest thing to do is appoint a data sharing champion—someone who is the "go-to" person when data sharing is discussed or agreements are developed, reviewed, and executed. This is tough on a single individual who often has their day-to-day work to do, but that additional burden can be alleviated by selecting someone who's already part of the data sharing process—a researcher, administrator, etc. Another option is to convene an internal committee to facilitate data sharing needs and engagement. We've recently helped numerous organizations develop cross-team and cross-functional committees that take on this work, in addition to capturing and sharing other organizational communications, engagement, coordination, and knowledge sharing.