What data teams can learn from the reference interview librarians perform to identify and serve true information needs
If you’re an analyst on a data team, the following scenarios are probably very familiar to you:
New project requests can come from many sources: an email to a shared inbox, a DM from a former stakeholder, a verbal request from your boss, or even just a jira ticket created by your project manager. No matter how you get the request, once you’ve received it, you will need to choose how to respond.
Perhaps your team is already over maximum capacity and you get requests like this every day. You could choose to ignore the request, or mentally bookmark it to respond to later, only to forget about it
You’re on a data team, and in today’s world that meansselect * from some_perfect_table_that_does_not_exist
? You don’t have enough time to clean up the data going into the dashboard the executives supposedly look at every day (they don’t), you certainly don’t have time to model the data used in 1 project into a star schema!
Let’s all stop and take a deep breath. In… out… in… out. If you are very lucky, and you have always worked on a fully staffed, well-managed data team with a reasonable number of projects and minimal interrupts, perhaps the above situations have never happened to you. But for the rest of us (and, I bet, the vast majority of us), these situations are familiar (and perhaps slightly triggering). And I’m about to give you some advice that you really won’t want to hear: you need to talk to your stakeholders more.
“What? Didn’t you hear that half my day is already filled with meetings and I can’t find the time to do the work I’ve already been assigned? I already talk to my stakeholders every week and they never tell me anything helpful. They’re just not data people
I hear you. I understand your doubts. I know you don’t have enough time to dive into each project as deeply as you want to. I know how frustrating it can be to talk to “non-data” people who just don’t understand why their seemingly simple ask isn’t reasonable. Trust me - I’ve been there, and I get it. But I want to zoom out for a moment, and look at the bigger picture.
What is the role of a data professional? What is the purpose of a data team? What is the function of data in an organization? What even is data?
Pause. Take just a few minutes to really think about these questions. What are your answers? I really want to hear! Wherever you may have seen this posted, please let me know in the comments.
No really, come up with your own answers before you read what I think - then come back and hear how a librarian would approach this dilemma.
My background is in Library & Information Sciences, and I also have a deep fondness for philosophy, which informs my opinion. You may have a totally different answer informed by your own background and expertise, and that is awesome! If we put together all of our perspectives, we can arrive at a more complete picture.
What is data?
When I think of what data is, I think of it in the context of the DIKW (data-information-knowledge-wisdom) pyramid, which is a foundational concept in the field of Library & Information Sciences. Rather than try to explain the DIKW pyramid myself, I’m going to pull quotes from this excellent encyclopedia page
On data:
Data are symbols that represent properties of objects, events and their environments. They are products of observation. To observe is to sense. The technology of sensing, instrumentation, is, of course, highly developed (Ackoff 1989, 3)
.
On information:
Information is relevant, or usable, or significant, or meaningful, or processed, data (Rowley 2007, Section 5.3 “Defining Information”)
.
On data vs information:
The vision is that of a human asking a question beginning with, perhaps, “who”, “what”, “where”, “when”, or “how many” (Ackoff 1989, 3)
; and the data is processed into an answer to an enquiry. When this happens, the data becomes “information”. Data itself is of no value until it is transformed into a relevant form. In consequence, the difference between data and information is functional, not structural (Ackoff 1989, 3) .
Information systems generate, store, retrieve, and process data. In many cases their processing is statistical or arithmetical. In either case, information is inferred from data. (Ackoff 1989, 3)
On knowledge:
Knowledge is know-how, for example, how a system works. It is what makes possible the transformation of information into instructions. It makes control of a system possible. To control a system is to make it work efficiently. (Ackoff 1989, 4)
On wisdom:
Wisdom adds value, which requires the mental function we call judgement. […] The value of an act is never independent of the actor [… ethical and aesthetic values] are unique and personal. […] wisdom-generating systems are ones that man will never be able to assign to automata. It may well be that wisdom, which is essential to the effective pursuit of ideals, and the pursuit of ideals itself, are the characteristics that differentiate man from machines. (Ackoff 1989, 9)
All organizations collect and store data as a by-product of doing business. However, this data cannot be used beyond its functional purpose of making the widget work until it is processed into information. That information can be used to help the people in the organization gain a better and more accurate understanding of how well the organization is functioning. Knowing how an organization is functioning helps the people serving the organization make decisions, which will then affect how the organization functions. Leaders making these decisions should have a vision of the organization’s ideal state, and we consider these leaders wise when they can effectively move the organization closer to that ideal state.
The purpose of a data team is to turn data into information, so that their stakeholders elsewhere in the organization might gain knowledge and make wise decisions. The role of a data professional is to navigate this process of turning data into information in the most efficient and useful way possible. An excellent data professional will partner with stakeholders to see through the process of generating knowledge from the processed information, and the most effective data leaders are those empowered to make decisions alongside other leaders.
In order to provide information that will increase the knowledge of your stakeholder and help them make wise decisions, you must talk to them in order to find out what the decisions they need to make are, what their current understanding of the knowledge landscape is, and what information they need in order to enhance their understanding. This conversation requires time, empathy, and trust. Most likely, your stakeholder has already thought about this… and then gone the extra step of trying to translate this into a request for a data team.
Their idea of a data professional is probably just that - someone who only operates at the level of data. But it is your job to demonstrate that while you have the technical know-how to work at the data level, you also have the business acumen to understand and converse at all levels of the DIKW pyramid. You can do your best work at the foundation when you have the entire context. The translation from a business-oriented request into a data-oriented request should be on the data professional, not the stakeholder.
This is where I’m going to introduce another concept from the field of Library & Information Sciences… and the primary topic of this blog post: the reference interview.
The reference interview is designed to solve a problem common to most information professions - one that you have undoubtedly encountered before and may have already developed techniques to address. My hope is that by learning how librarians approach a reference interview you can add another set of techniques to your toolbox, and perhaps even adopt a new perspective that will help you approach one of the most frustrating aspects of your job.
Before adapting the reference interview for data teams, let me first explain it in its original context: that of a librarian responding to patron inquiries. Have you ever walked into a library with a research question, but weren’t quite sure where to start? Soon after walking in, you probably saw a circular desk with signs above it proclaiming “Reference Desk”. Behind that desk are one or two librarians, next to computers with the catalog ready for searching, ready to help you with your research quest. You walk up to the desk, ask your first question - and what happens next is the reference interview.
My primary source for this section will be the Reference and User Services Association (RUSA) Guidelines for Behavioral Performance of Reference and Information Service Providers
The importance of the reference interview is founded on a simple assumption: that patrons rarely start out asking the librarian for the information they actually need. The goal of the reference interview is to identify what the patron really wants to know, so that the librarian can then more efficiently search the system for resources that will fulfill the patron’s true information need. Librarians should take the time to establish rapport with the patron, engage in active listening, and confirm that the information provided is what they actually needed - in the end, this will save the time of both patron and librarian (compared to jumping straight to the search and repeating through trial and error until an adequate resource is found).
While on the surface the reference interview is a structured format for going from initial question to identifying resources that can fulfill the true information need, the real magic is in the empathetic communication style and active listening that underlies these techniques. Excellent interpersonal skills and emotional intelligence are key for the librarian to build trust with the patron, cultivate an inclusive and collaborative learning environment, and work towards a mutual understanding of what the patron really wants to know.
Reference interviews generally follow these 6 steps:
A reference interview is most successful when the librarian and patron share a common purpose: finding materials that will fulfill the patron’s information need. It is the librarian’s responsibility to find out what the patron wants and guide the interview in order to achieve this goal. The modern reference interview comes from the perspective that libraries are primarily service-oriented, and should provide information in the manner that is most useful to its patrons.
Of course, there are plenty of opposing viewpoints in the LIS literature - that the reference interview is not always necessary, that it is only useful for certain types of inquiries, that libraries shouldn’t be service-oriented, that the reference interview can only be performed in person… and the dominant viewpoint in the literature has changed over time. If you’re curious, feel free to explore the literature, but I’m not going to dive any deeper in this post beyond noting the fact that the importance and role of the reference interview has been contested and evolved since it first became a thing over a century ago.
It should also be noted that even when librarians are trained to always conduct a reference interview, studies have shown that a majority of the time they do not conduct a full reference interview, or default to the “question-oriented model” (answering the patron’s original question) rather than the “needs-oriented model” (addressing the patron’s information need - the initiating problem). Being empathetic, curious, and patient all of the time for every patron query is hard work, and nobody is perfect - but the reference interview provides an ideal guideline for these engagements.
Before we move on to how this translates to the work data teams do, I want to spend some time on the different roles that a librarian takes on during the reference interview. My primary source for this section is a chapter in the book “Leading the Reference Renaissance: Today’s Ideas for Tomorrow’s Cutting Edge Services”, called “Inventing the future by examining traditional and emerging roles for reference librarians”
The most dominant role of the reference librarian is that of the “information provider”: the highest priority for a reference librarian is to provide answers to questions - the more complete the better, whether that be through directly telling the enquirer the answer to their question or helping them find the information resources they need (e.g. books, journal articles, news articles, magazines, etc). After all, the ultimate goal of the reference interview is to fulfill the patron’s information need. But while “information provider” is the most obvious role, it is far from the only (or even, arguably, the most important) role that a reference librarian fulfills.
The other major role for a reference librarian is that of the “instructor”. No reference librarian wants to be the sole provider of answers - think of all the questions that would never get answered simply due to time and resource constraints! Instead, reference librarians can instruct users in library and research skills, so that they can be self-sufficient and navigate the library to find the answers and resources they need on their own. While reference librarians can lead classroom-style teaching sessions, instruction can also occur during the reference interview.
Read the first sentence of step 5 again: “Conduct a search of the system collaboratively, sharing your screen/resource and explaining each step of the process.” By the end of the reference interview, the patron should feel more comfortable conducting a similar search on their own next time. While this may mean the current reference interview may take slightly longer, it will save time in the long run.
There are some further minor roles that are implied by, or overlay, these two major roles, such as:
The final role I want to focus on is that of the librarian as an expert: this is the foundation for all of the previously outlined roles. A librarian is an expert at navigating (and cultivating!) the system that organizes the library’s resources. That expertise allows the librarian to quickly find needed information, and some portion of that expertise is what the librarian is attempting to transfer with instruction (though much of the expertise is likely to remain as tacit knowledge
The parallels between data professionals (especially analytics engineers) and librarians have been drawn before (many times), albeit usually by those on the data side of the divide. If you’ve read this far, I’m hoping that by now it is obvious that this is because both data professionals and librarians are really information professionals. And while data (engineer/analyst/scientist/etc) is a relatively new profession, librarianship is not, and there is a lot for the data professional to gain by considering themselves part of the wider information profession - and the larger body of knowledge and practice that comes with it.
One such practice? The reference interview.
Before I give my take on how data teams can learn from and adapt the reference interview, I once again want to ask you, dear reader, to pause and consider for yourself: based on everything you’ve learned so far, how can you borrow from the typical reference interview the next time a stakeholder comes to you with a new request for the data team?
Remember, the difference between data and information is functional - it is only by processing data into information that we give it meaning, purpose, and value. Which level do you want to be operating at? Which level does the rest of your organization think you are operating at? What do you need to do to get to the next level?
So how can data teams learn from library science, adapt the reference interview, and elevate their practice from being data practitioners to information practitioners? I want to approach this from two perspectives: that of an individual contributor on a data team who has the power to adjust how they interact with stakeholders, and that of a data team leader who has the power to make structural and process changes that affect the environment that the individual contributors on a data team work in.
Let’s start with the individual contributor perspective. Remember the pithy and unwanted advice I gave near the start of this post? You need to talk to your stakeholders more. Beyond that, the attitude and emotional presence you bring to those interactions matters. Your stakeholder has an information need. They know you are busy and have a dozen other projects that need your attention, and they likely have already formed some opinion about what you know and are capable of doing.
So in an effort to be helpful and efficient, they have likely already taken that information need and refined it, restricted it, reshaped it in a query or request that they think you can do/answer in order to fulfill their information need. So here is my first and most important request to you: don’t accept that query at face value. It is your job, not theirs, to dig deeper and discover their true information need before you try to fulfill it.
Here is an abbreviated and reframed version of the 6 steps to the reference interview, which you can use and adapt in order to uncover their true information need. Think of this as a formula for a structured or guided conversation:
Conversations like this (in which you are trying to unearth their true information need) will generally be more successful when you approach them with empathy, non-judgement, and genuine curiosity. Take the time to establish a rapport first. Apply the techniques of active listening. Intentionally cultivate an inclusive and collaborative space. This means that your language matters. Erase words like “simply”, “just”, and “easy” from your vocabulary
Remember: the interpersonal skills and empathetic mindset that a librarian brings to the reference interview is just as important (if not more!) to the ultimate success of uncovering the user’s true information need as the structured interview process that they follow. I want to acknowledge that this is hard, and it is a skill to develop just as vital as any technical skill, so give yourself grace and time to reflect as you start to adjust your approach. And if you feel like this is already how you engage with stakeholders, that’s fantastic! Make sure you are collecting feedback - from your stakeholders, your peers, and your managers/mentors - so you can continue to improve your approach (everyone has blindspots!).
If this sounds preachy, I apologize, but I genuinely think this is both the hardest and most impactful skill you can develop. It is a skill I know I will need to continue to practice and improve on throughout my entire career, and it is a skill that is almost never taught in professional contexts (unless, perhaps, you were a therapist in a previous life). If you are struggling to make the jump to senior, demonstrating this skill will be one of the most important things you can do to show your manager and your team that you are someone who can handle the more nebulous projects - the kinds of projects typically given to seniors.
Ok, so what do we have so far?
What else can we adapt from the reference interview?
I want to pull your attention to step 5 of the librarian’s reference interview:
Conduct a search of the system collaboratively, sharing your screen/resource and explaining each step of the process. Check in with the patron to see if they want to do the search themselves at any point in the process, and if so, continue to offer assistance as needed. This is the phase where you can offer instructions or advice, guiding the patron with your special expertise and knowledge.
I also want to remind you of one of the major roles the reference librarian plays: the instructor. Most likely you already assume the other major role of the “information provider” when you receive an ad-hoc request, but how often do you assume the “instructor” role? What would that look like for a data analyst?
Let’s revisit the first scenario:
A stakeholder you’ve worked with before comes to you with a new request. They saw what kinds of questions could be answered with a dashboard in the last project, and now they have some new questions to try and find answers for
After some investigation (read: asking a series of open-ended and then clarifying close-ended questions, rephrasing their ask, and then repeating until you understand their underlying information need), you realize that this stakeholder is trying to do some exploratory data analysis (EDA) for a new project, and they want to gut check whether the trends that they think are happening are actually happening. They don’t actually need a dashboard (or at least, not yet), but that’s how they’ve been doing EDA for the other project, and they figured another dashboard for this new dataset would let them see whether these numbers were actually going up over time.
Do you want this stakeholder coming to the data team every time they want to do some EDA? Go that route, and you will soon have a graveyard of unviewed dashboards, not to mention the opportunity cost of devoting valuable analyst time that could’ve been spent on higher value projects. Why is the stakeholder asking for a dashboard when the underlying information need could be fulfilled more efficiently with some SQL queries? Likely, because dashboards and interactive visualizations are familiar. For the sake of this example, let’s say that this stakeholder knows some basic SQL. How could the data analyst approach step 5 of an adapted reference interview?
The first step is to invite the stakeholder to be a partner in this EDA. Assuming that this stakeholder is not an executive, if they are asking for the data team to invest time in answering their question, they should be willing to put that time in themselves, as well. Who knows - they may even be excited at this opportunity to learn some analyst skills from an expert! Set up some pairing sessions, and use those sessions to time-box the project - you’ll only work on it during those pairing sessions. During those sessions, you will be sharing your screen and narrating your process.
Don’t try to prepare a cleaned up version of the process - let the stakeholder see and participate in every messy step (yes, that includes googling for how that window function works again, and running queries with typos). The ultimate goal here is for the stakeholder to feel comfortable going through this process by themselves, and that includes knowing what to do when something goes wrong
Start from the very beginning - the first thing you’ll have to do is identify the right datasets to query. You are an expert at navigating the data warehouse - you know how it is organized, the naming conventions, and how to identify high quality ready-to-use datasets. You know how to search the data catalog (or whatever other documentation there may be), and you are all set up to query the database. Your stakeholder is also an expert
The next time this stakeholder has a question, hopefully they are more comfortable performing some of this process themselves - and maybe in some future request, they will ask to drive in the pairing sessions, with you providing support when needed. By inviting the stakeholder into your workflow and process, you are enabling and empowering them to use the data resources available to them more independently, freeing up your time to focus on more complex analysis.
This is one of the foundational building blocks of true self-service - not only making the data and tools available, with the data documented and findable in a curated data catalog, but also providing the training, support, and guidance for users so that they are empowered to navigate the system by themselves or in partnership with a data expert if they so choose. Sorry, but no magic BI tool is going to be able to provide self-service if those core fundamentals aren’t in place.
Generally, the first step in a new project is to gather requirements. This phase is often responsible for most of the frustration and angst you experience while working on a project. How many times have you thought you reached the end of a project, only to be told that the report or dashboard you delivered does not actually meet the stakeholder’s expectations? This needs to be tweaked, that needs to be reworked… but sometimes that little tweak is a change to a fundamental assumption that requires overhauling the entire product!
How does your team gather requirements? When does the requirements gathering start? (Likely during the initial intake phase!) Who typically performs the initial requirements analysis? Does this person have the necessary context and technical skills to gather all requirements? Is there a handoff? What problems typically occur during this handoff? When does the individual contributor who will be doing most of the work for the project get involved? How much of the requirements gathering process do they typically need to re-do? Crazy idea: draw a process map and start identifying waste in your requirements gathering process. How can you improve the experience of gathering requirements for both the data team and the stakeholders?
As you may have guessed, I believe the reference interview has something to offer here. First, the individual contributor(s) who will be directly working on the project should be brought into the requirements gathering phase as early as possible. While a project manager or data product manager can direct and guide the process, they should not try to collect all of the requirements in a vacuum and then hand off those requirements to an analyst/engineer. Second, the analysts/engineers/managers involved in the requirements gathering should be conscientious about the emotional energy they are bringing to these stakeholder conversations: adopting an empathetic, non-judgemental, and curious mindset. Third, they should try to follow the key principles of the reference interview in these conversations: that the stakeholder is not likely to start with their true information need, to utilize active listening techniques, and to approach the process as a collaborative exercise in which all parties have special expertise to offer. The data team should iteratively develop a set of requirements and seek consensus on those requirements and the true information need.
If you were to make one change to your typical requirements gathering process to align it closer to a reference interview, what would it be?
If you’re a data team leader, I hope that you haven’t just skipped ahead to this section - because your whole job is to cultivate an environment that encourages and supports all of the suggestions I made in the previous section for the individual contributor. So let’s review some strategies that will allow your team to start acting more like information professionals, and implement their own version of a reference interview.
Let’s start with the most significant environmental change you can make: creating the data team’s equivalent of a reference desk. When you walk into a library with a question, do you ask the first person you see with a name tag? I mean, maybe - but any trained library page should know to then direct you to the reference desk. But most likely you look for the big desk with signs above it and a reference librarian ready and waiting behind said desk. This librarian isn’t (usually) doing other activities like cataloging or purchasing new books - if they are at the reference desk, their sole job is to help any patron who walks up to the reference desk. How can we replicate this experience for stakeholders reaching out to a (e.g. remote) data team?
First, someone needs to be “at the reference desk”
On the flip side, team members who are not currently on-call/at-the-desk should not be expected to respond to ad-hoc requests. The goal here is to minimize overall context switching, account and plan for all types of work (after all, we all know ad-hoc requests are inevitable), and better serve the data needs of the whole organization without sacrificing the needs of the data team itself. What virtual “signs” can you put up to direct stakeholders to the data team’s “reference desk”, to hopefully minimize the number of redirects that are needed? What culture changes are needed to shift and enforce this new social norm?
Next, you’ll need to consider training: how can you enable data team members to be successful when it’s their turn to serve at the reference desk? Unless you have a librarian on your team (which, honestly, you should consider!), this is going to be a learning experience for everyone. Consider pairing two team members to be at the reference desk together, so they can observe and learn from each other. Collect and encourage feedback, from each other as well as stakeholders.
Here’s a crazy idea: try going to a library with a research topic in mind, and ask a reference librarian for help. Experience the reference interview for yourself as a patron! Your experience may vary depending on the library that you go to, so try visiting a few different libraries (especially if you’re lucky enough to be close to a research university!) - try to pay attention to the overall experience from entering the library with a question to (hopefully) leaving with some resources and/or answers.
If you’re willing to try this data team reference desk idea out, I fully encourage setting it up as an experiment. What are you trying to improve? What metrics can you track? How can you test whether this change is actually improving processes for the data team and your stakeholders? What surveys should you send out before, during, and after the experiment?
For many data teams - and data “thought leaders” on LinkedIn - “service” is a dirty word. You don’t want your data team to be like the typical IT service desk, where data team members are just ticket takers who fulfill stakeholder requests. No, you want your data team to be working on strategic high-value projects that will drive measurable impacts on the business. After all, how can you focus your limited resources on driving the highest impact if your team is churning out dashboards and emailed reports by the dozen?
Let’s reframe the word “service” from an IT context to a librarian context. Going back to “Conducting the Reference Interview”, Chapter 1, the authors state unequivocally that “this book is founded upon the principle that libraries must take a service orientation.”
We are convinced that the institutions that will survive in the twenty-first century are those that serve their clients and give them the help they need. If libraries don’t provide helpful information services, users will turn to other service-providers who are more service-oriented… librarians provide a professional “value added” knowledge component that is lacking in many commercial services. The RUSA (Reference and User Services Association, 2000) “Guidelines for Information Services” state: “Provision of information in the manner most useful to its clients is the ultimate test of all a library does.”
Some useful context for this quote: there was a significant contingent of LIS researchers convinced that search engines would render the profession obsolete. While the role of librarians and the value they provide may have shifted, librarians are still around and more vital than ever. 20 years later, a similar debate is ongoing… this time focused on generative AI. The conclusion to this debate seems even more obvious than the one over search engines.
A side note in the book elaborates on this idea with a further citation from the literature:
Herbert White (1992) says that librarians need to emphasize their strengths. As computers increasingly take over clerical tasks that computers are good at, librarians should focus attention on aspects of service involving human communication that computers can’t do well. Let computers get involved in document identification, document delivery, overdue notices, interlibrary loans and cataloging, White argues, and let librarians take a proactive role in information intermediation.
Reframed: a service-oriented data team is focused on providing information in the manner most useful to its stakeholders, and is a proactive human intermediary between the organization and its data resources. (I’ll posit that this approach is not opposite of a product-orientation, but rather complementary.)
As a data team, you acquire, organize, curate, and retrieve data resources. The team’s collective expertise is vital to interpreting and analyzing these data resources. However, the data team is rarely (if ever) the one making the decisions (or the ones accountable for the results of said decisions). Data teams can be as strategic as possible, working directly with the C-suite on the most important objectives for the organization, but by virtue of their raison d’être, data teams will serve a supporting/helping role.
For some, this can grate - you may want to be the “hero” data scientist, crafting machine learning algorithms that make the decisions for the business, rescuing the organization from heuristics-driven (poor) decisions and instead achieving the lofty goal of data-driven (smart) decisions. Rock, meet hard place - given human nature and organizational realities, your hero aspirations are likely a pipe dream, and the sooner you realize that humans will always be in the loop, the faster you can start making a real impact.
How does your data team currently operate? How do you want your data team to operate in the future? What does your organization currently need out of the data team? What are your organization’s goals for how to use data in the future? How does the data team need to operate in order to help the organization achieve their data goals?
As a data team leader, it’s your responsibility to consider these questions and create a strategic plan to ensure not only that the data team is adding net value, but that the rest of the organization recognizes that value. Do you think that the librarian’s frame for being “service-oriented” should be a part of that strategy? If analysts start new projects or respond to ad-hoc requests with some version of a “reference interview” (vs immediately building out a dashboard based on the description field in a Jira ticket), how do you think that will shift both the actual and perceived value of the data team?
At the start of this post, I gave a few examples of scenarios data teams may encounter:
If you made it all the way to the end of this extremely long blog post, then I hope you can start to brainstorm how you might approach these scenarios as a librarian would. The point of this post is not to say that all data teams should adopt the reference interview for all ad-hoc requests and requirements gathering activities for longer-term planned projects. Rather, I hope that you have a new perspective on how your data team’s processes and procedures might be shifted - that you have a new hat you can wear, a new lens through which to see the world, another tool in your toolbox… whatever metaphor floats your boat.
There are 2 key things you should remember about the purpose of the reference interview:
The idea that stakeholders rarely ask you for what they actually want is hardly a new one or unique to the reference interview. Just ask your product managers, or anyone with a few years of experience interfacing between the people who want things and the people who have to deliver those things. Hopefully this is not a revelation for you either - though if it is, it’s a valuable lesson to learn
Far more important than realizing that stakeholders rarely state outright what information they actually need, is the perspective switch that it is your role to uncover their true information need. You will always be handicapped if you blame your stakeholders for not accurately translating their information/business request into the data team’s language.
The reference interview provides a structured way to accomplish this vital discovery process, and it really doesn’t take too much translation to go from a librarian-performed reference interview to a data analyst-performed reference interview.
To review (in short), this structure is:
If you have the time, take a moment to think about each of these 3 scenarios. How would your team approach them today? How would a reference librarian approach them? Role play is an extremely effective way to learn and practice new skills - grab a partner and try conducting a reference interview for each of these scenarios!
This post had a lot of questions for you, the reader - many of which were left unanswered, because every reader will have a different answer. I hope that you put some time into considering these questions, and the next time you get one of those annoying ad-hoc requests your memory might be jogged, and something will prompt you to put on your reference librarian hat. (There are certainly worse hats to wear!) I hope you will experiment with the reference interview method - adapt it and make it your own. And I hope that you consider the time that you spent reading this post well spent - thank you for reaching the end!
If after reading this post you are intrigued enough to try any of these strategies for yourself or your team, I would love to hear about it! Please reach out via email, on socials, or by leaving a comment on this post. I would love to hear your story.
Most students in an MSLIS program take a class called “Reference & Information Services”. It’s a core part of the curriculum, if not required. Many MSLIS graduates go on to work in a library and gain experience in conducting the reference interview. Unfortunately, neither applies to me - I veered hard into the “information management” side of my program, and then kept on veering straight into the data field. However, I do have the great fortune of having a group of friends from my cohort who did take Reference, and who did go on to be librarians who conduct reference interviews. When the idea for this blog post was first taking shape, they were the first people I went to for help and resources. They sent me their class syllabus and readings, and patiently answered all of my questions about the reference interview based on their knowledge and experiences. Thank you for the references and the conversations - I wouldn’t have been able to write this without you. To Yvonne Freebourn, Taylor VanTryon, Adam McConville, and Christine Willson, UIUC iSchool Class of 2020.