One of the interesting side-effects of having a done a PhD, aside from some unwanted flashbacks whenever I come within view of a flow cytometer and the uncanny ability to know where the mouse facility is in any research facility based on smell alone, is my iterative approach to pretty much everything. Having spent a good portion of my career in research science, I naturally approach everything as an experiment, gather the data, analyze the data, re-adjust my hypothesis and approach and run another experiment. It’s become so ingrained into my problem-solving methodology that I don’t realize I’m doing it most of the time. How that translates into the managerial work I’m doing now is that it appears that I’m in a constant state of process improvement. This is basically true, I’m constantly running little experiments, trying to solve a bigger issue or achieve a larger goal. I’m sure this drives some people on my team nuts as they are constantly hearing, “can we try this another way”, and I’m also sure that there’s little chance that I will fundamentally change this behavior anytime soon. My task is to make sure that the end goal is always in sight and that the team knows why we are iterating and the results of the iterations, etc. But I think that’s a topic for another post.
My objective in leading off with an explanation of my general thought process is because that is how I came to a new initiative with my team that is very relevant to what I’ve been discussing here. I recently obtained the DAMA Body of Knowledge (DMBOK) and am casually studying it with an eye toward certification. The Data Management Association International (DAMA-I) has been around since the 1980s and is comprised of data management professionals from around the world. They offer certification as well as annual conferences. Anyway, the excessively large book began with a discussion on the definition of basic terms. At first I thought this was a little too basic until I delved deeper into the reading. It wasn’t that the definitions of basic concepts like “data” and “metadata” were so profound that I thought they encompassed all possible scenarios for the use of those words or anything transcendental like that. While I was reading through the rather dry text, it occurred to me that my team hadn’t set these definitions for us. We hadn’t laid the foundation for our data management practice by collectively agreeing on what we meant by “data”, “metadata”, “data management” and “data management principles”.
I decided to start an Intro to Data Management information sharing series with the team. It’s a once a month session in our team meeting that will go through fundamental data management components, starting with the basics. I call it information sharing rather than “training” or “education” because I truly want it to be a discourse on best practices and a re-imaging what these dry, textbook definitions and theories mean for us in our practice of lab data management. This is probably iteration #3 of our team meeting and I know we’re getting closer to a framework that is meeting the team’s needs.
Sidebar: This brings me to another iteration of practice that I introduced recently that is gaining some traction. I came across an article about silent meetings. (See resources here: https://hbr.org/2019/06/the-case-for-more-silence-in-meetings and here: https://www.businessinsider.com/better-idea-silent-meetings-work-2019-1, just to name a few.) The concept struck me at once because of the mix of participation and non-participation that happens in most of the meetings I facilitate. OK, let’s be honest, mostly non-participation. Having come from an organization where participation in meetings was considered an essential skill and the CEO valued “a good dust-up”, this culture of passively listening and head nodding was totally foreign to me. I knew people had good insights and ideas, they just weren’t coming out in the meetings. When I saw an article about silent meetings in a daily email digest I get, it was a definitely a light bulb moment. You can read the links for details but the benefits of this type of meeting are that those who tend to be quiet in meetings can offer their ideas and you avoid the bias of everyone echoing the opinion or thought of the first person who speaks. So far the results have been good in the meetings and the feedback from the team has been overwhelming positive.
Now, after that rather large squirrel, let’s get back to data. So, defining the term data may seem like the most obvious thing in the world and not worth the time it takes to write data. Let me offer this anecdote to illustrate why the time might be worth it. Where I currently work, we get a large number of data requests. We have formal procedures in place now but not too far in the past, email requests would come in from a researcher asking for “the data”. We would email back and say, “OK, here is the raw data you asked for.” Nope, that was not what the requester wanted. Attempt #2: “Here is the processed, standardized data set.” Nope, that wasn’t it either. Attempt #3: “Here is the exact analysis data set used with the metadata attached.” Nope, that wasn’t it either. Attempt #4: “Here are the results (interpreted data)”. That was it!! Finally!! Now of course there are a number of issues with this anecdote including communication, intake processes, triaging of requests, etc. What I would like you to take away from it though is the importance of having a shared vocabulary and how much time it saves in redone work.
Defining terms such as data, metadata, data management, etc is extremely important no matter what kind of work your organization does. Obviously, for a data management and analysis organization, this is absolutely critical. But, I would argue that this is critical for all organizations. If you do not define what “data” is for your organization, all sorts of assumptions can be made about how data moves through the organization, how it is secured, how it is managed, how it is retained. The DMBOK defines data as an asset, “an economic resource that can be owned or controlled and that holds or produces value.” As such, it should be defined and managed. The organization I work for has done an immense amount of work doing just this, defining data, and metadata and data management. It had not trickled down into my team yet. We hadn’t taken those definitions and translated them into ones that were specific to the lab data we manage. Using the silent meeting structure, we defined what data meant to us in the context of the lab data we manage, what metadata was, how data management was defined and what data management principles aligned with how we (and the whole organization) work. I got feedback after the meeting that both the format and content were well-received.
Now is where this post comes all together. Getting back to basics means:
- Defining what “data” and metadata” mean to your organization. What do you include in your definition of data and metadata?
- Be comprehensive here. Assuming that data has to numerical or electronic can be misleading. There is a lot of “data” that we would have included in the definition not so long ago, names, addresses, the number of times someone visits a website, personal preferences for clothing, etc.
- Define what data management means to your organization and decide on your data management principles.
- What are the key components of how the organization should manage data?
- Outline your data management principles
- These should guide the data management practice
- Reflect on how your data assets are used or can be used to reach your organization’s goals
- You don’t have to do this from scratch. There are lots of good resources out there to use as a starting point.
You can use a number of different types of meetings, asynchronous communication, etc to get at these definitions (hey, why not through a silent meeting in there?). Laying out this foundation for data in your organization and making sure the whole organization (here I mean group, team, whole company, whatever you have influence over) is clear about this foundation, ensures a solid ground on which to build any data project.
So, care to run a little experiment with me? Can you define data for your organization? Do you have clear and consistent data management principles? If not, join me in enacting a bit of change, one little iterative experiment at a time, starting with the basics.