The librarian's reference interview for data teams (abridged)

What data teams can learn from the reference interview librarians perform to identify and serve true information needs

Note: this is an abridged version of the original blog post. You can find the unabridged version here: https://jennajordan.me/blog/reference-interview-for-data-teams

Would you like some unsolicited advice for working on a data team? You’ve started reading this blog post, so I’m going to assume the answer is yes. Here it is:

You need to talk to your stakeholders more.

I can already hear the shocked gasps and cries of denial, but my role here is to convince you that not only do you, indeed, need to talk to people more, but you should also borrow a framework from librarians to do so: 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.

The (original) reference interview

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.

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:

1. Establish contact with the patron and listen to the initial request, without interruption or judgement

2. Paraphrase the initial request, to demonstrate you were listening and verify you correctly understood the question

3. Ask open-ended questions first that encourage the patron to elaborate on their initial request (focusing on the big picture), followed by clarifying close-ended questions to understand the specifics of certain parts of the request

4. Verify the patron’s request by restating the question and asking for confirmation, incorporating what you have learned during the question phase. If the patron verifies this rephrased request is accurate, start the search. If not, repeat the question phase until the patron verifies the restated question is accurate.

5. 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.

6. Follow up with the patron to verify that the patron’s information need was met. You may need to review the resources found and identify different/additional resources if needed, repeating the search phase. It may also be necessary to explain when a request is beyond the scope/capacity of the library, in which case the patron should be referred to an external resource/institution. This final phase is also the appropriate time to ask for feedback on the process.

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.

It should 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.

Roles of the reference librarian: information provider, instructor… expert

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.

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:

• Communicator: librarian as the human connection between a user and the resources

• Relationship builder: librarian building a long-term relationship with the user

• Guide/advisor: librarian guiding the user in selecting good and appropriate resources

• Counselor: librarian mentoring users in the research process, and treating the user as a holistic person

• Partner: librarian and user act as a team, each bringing their own knowledge and skillsets

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). This expertise is what the librarian brings to any research partnership, and what allows the librarian to be a guide for users.

The reference interview for data teams

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.

For the individual contributor: practice the reference interview

Let’s start with the individual contributor perspective. Remember the pithy and unwanted advice I gave at 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:

1. Listen to the initial request without interruption or judgement

2. Paraphrase the request back to them

3. Ask open ended questions first, followed by clarifying close-ended questions

4. Restate the request yet again, now altered by their responses to your questions. Repeat until the rephrased request is confirmed as accurate

5. Collaborate to find an answer to the rephrased information request, using the interviewer’s expertise in navigating the information system and the interviewee’s guidance and background knowledge. Depending on the need/relationship, either can be the “driver”.

6. Verify that the true information need was met. If not, the process can be repeated, or the requestor may need to be directed to further resources if their information need is beyond the capacity of this process. Finally, you can ask for feedback on the process.

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. When you ask questions, show that you are paying close attention to their response by rephrasing and restating what you heard. Ask yourself first what assumptions you are making, and at the very least verify/clarify those assumptions or don’t bake them in to your first round of (open-ended!) questions.

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 takeaways do we have so far?

• Talk to your stakeholders more (especially at the start).

• Never assume that their initial request matches their true information need.

• Make it your goal to uncover their true information need.

• Cultivate an empathetic, non-judgemental, and curious mindset.

• Practice active listening techniques.

What else can we adapt from the reference interview?

Assuming the Instructor role… and a path to self-service?

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. You want the stakeholder to lose the perception that the skilled technical data analyst is able to magically produce a dashboard with a few precise keystrokes!

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 - they may or may not know what the data looks like, but they do have a lot of knowledge in this domain. You need to use your expertise to guide the stakeholder in the research process, and you can lean on your stakeholder to know what information they expect and want to find. You might find that by working together, you can fulfill your stakeholder’s information need better and faster than going off on your own… a 1 + 1 > 2 effect.

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.

Gathering requirements with the reference interview

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?

For the data team leader: build your team’s reference desk

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” - a dedicated analyst/engineer/etc whose only job during that shift is to respond to stakeholder requests. We can borrow from “on-call” best practices for software engineers here as well - while a reference librarian is typically responding to new information requests and an on-call software engineer is typically responding to active issues/outages, the assigned data team member is likely to encounter both of these situations. Regardless, the data team member who is on-call/at-the-desk should not be expected to complete any typical project work during their shift, and it is your job to organize sprints and/or project planning around this.

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?

Wrapping Up

There are 2 key things you should remember about the purpose of the reference interview:

1. A stakeholder’s first stated information need is rarely their true information need

2. The best way to uncover their true information need is by approaching the conversation with empathy, nonjudgement, and genuine curiosity, as a partner who acknowledges everyone’s respective expertise, and by utilizing the techniques of active listening

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.

Special Thanks

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.

Also, special shoutout to Amalia Child for citing this post long before it even existed, and fighting the good fight with me to spread the wisdom of Library & Information Science to the data world.

Citations

Reference and User Services Association (RUSA) Guidelines for Behavioral Performance of Reference and Information Service Providers  [link]. American Library Association. 2008.

Conducting the reference interview: A how-to-do-it manual for librarians  [link] C.S. Ross, K. Nilsen, M.L. Radford. ALA Neal-Schuman. 2019.

Inventing the future by examining traditional and emerging roles for reference librarians  [PDF] A. VanScoy. Leading the Reference Renaissance: Today’s Ideas for Tomorrow’s Cutting Edge Services, pp. 79–93. Neal-Shuman Publishers. 2012.