Being an industry research scientist

I recently became the head of research at Tableau and thought it would be a good time to reflect back on the decade since I joined the company. I’d like to spend some time talking about my personal experience being in industry research, covering topics that have been helpful in my own personal journey — crafting a research portfolio, following through on research ideas, setting up productive collaborations, listening, communicating, and writing as a way to organize my thoughts.

I come from a rather eclectic research background, a mixed skillset of seemingly disparate disciplines — computer graphics with natural language processing (NLP). When I joined Tableau Research back in 2012, I had limited experience in data visualization, with the only visualization-related projects being map displays and navigation at Nokia Research. Folks were perplexed by my unconventional research background and what I was doing here; the computer graphics experience somewhat justified my existence at that time. Fast forward ten years later, with the help of wonderful collaborators, I have carved out an exciting research area that combines these two disciplines, essentially looking at the semantics of the data with user intent to inform the meaningful visual depiction of data. It’s also heartening to see how this work is still evolving in terms of innovation — inspiring interesting research papers from the academic community as well as products and features from the Tableau development teams. The work also provided me an opportunity to be an engineering manager on the Tableau NLP product team for a couple of years, shipping production code to customers. As I reflect back on the 17 years of my research career, I thought I would document my personal experiences during my time here at Tableau, and what it takes to do impactful work as an industry research scientist. So here goes.

Managing a research portfolio with a point of view

While it is helpful to have a set of high-level research goals to guide one’s work, translating that to day-to-day research tasks can feel a bit abstract; a common problem for any research scientist, be it in academia or industry. Over the years, I have found that developing a collection of short- to long-term research ideas (i.e., a research portfolio) helps one take a crack at a bigger, abstract problem and identify smaller nuggets of ideas to help move the research forward. Let me walk you through a few project examples from my research portfolio to illustrate what I mean.

When I started at Tableau Research, one of my goals was to identify how NLP and semantics can help support meaningful visual encodings for data. I started off working with Jock Mackinlay on a project to automatically generate semantically relevant icon encodings for categorical dimensions of data points. The algorithm employed NLP to find relevant imagery from the Internet, such as the example below where each animal is automatically associated with a semantically meaningful icon, making a chart becomes more useful to understand and follow.

A natural segue from that project was exploring with Maureen Stone how linguistic information about the data could be used to generate semantically meaningful color palettes. For example, here is a color palette automatically generated based on the ice cream flavor names in the data.

While these projects did not lead to specific features in the Tableau product per se, they did accomplish two things: (1) the projects got researchers thinking about interdisciplinary research where NLP techniques could be applied to different aspects of data visualization, and (2) got leadership at Tableau excited about the opportunities where concepts from NLP can bring value to its customers.

These little initial successes led to bigger and more impactful projects, such as the deployed map search feature in Tableau 9 to explore conversational interfaces like Eviza later. Eviza was a research prototype that supported vague natural language queries in the context of a visualization, such as, “Find large earthquakes near California.”

While it was Eviza that ultimately excited executive leadership to seriously think about investing in NLP, every project in my research portfolio played a little part in helping communicate my point of view as to how and why semantics and user intent are important in supporting Tableau’s mission of helping people see and understand their data.

A well thought out research portfolio consists of a variety of short to longer-term creative projects that try to solve a set of problems that are important to the company’s mission. The ideas need to be adequately discussed with peers, managers, and product teams, to validate the approach along with understanding the applicability and value for the research in the near future. Having a coherent research portfolio also provides an effective communication medium for demonstrating a specific point of view to relevant decision-makers in the company like product owners, engineering managers, and senior tech leads, along with establishing a track record for doing interesting research.

Prototyping to demonstrate an idea

Ideas are cheap, and building something helps determine how viable that idea is. Most of my projects involve developing a prototype. I have found that prototyping is an effective way to clarify one’s thinking, demonstrate a research idea through an algorithm or novel experience, show the benefits of the approach, and even convey the limitations. These proofs-of-concept provide a tangible window into the bigger picture of your work. There is also the visceral thrill of building something that feels real, getting people to use and play with the system for feedback. I often demo to product teams — be it a new way of implementing auto-completion for search or a novel way of handling ambiguity in Slack and chatbot interactions. Prototyping is a tangible way to elicit their reactions, followed by additional iteration.

A prototype also gets product teams excited, particularly engineers, as they are able to identify pathways for taking the idea forward more concretely in their own code and feature ecosystem. It also helps foster creativity, aimed at solving important problems that inspire the engineering teams to innovate. Videos of prototypes are also an effective medium to keep colleagues informed of my progress and share my own excitement of chipping away at the bigger picture.

While Eviza was a prototype that inspired the formation of the Ask Data product team, I will say that prototyping is an effective tool for even smaller ideas. For example, SneakPique was a prototype that explored visual autocompletion techniques to help users during data exploration. Aspects of that work inspired the Ask Data team to think about ways to improve the product’s autocompletion experience, particularly using a calendar widget for formulating temporal queries that filter to dates. In addition, a software engineer from the Aerospace Corporation reached out to me and said that they found SneakPique to be useful for validating their approach for users to query their systems (SQL-like syntaxes being too limited and natural language being too free). However, to make prototyping part of one’s research practice, it is important to be fluent in programming languages and libraries that can be used to realize these ideas. Whether it is a programming language or a design tool, I think that it is important for research scientists to invest in themselves, being adept at picking up a tool and using it quickly to realize an idea.

Value productive collaborations and keep them time-boxed

Over the years, I have considered myself to be very lucky, having worked with a range of amazing internal and external collaborators. Many of my collaborators come from backgrounds different from mine, including software engineers, product managers, visualization practitioners, and UX researchers. I have always found that a good mix of different perspectives makes for a really enjoyable and fruitful end result. I also like to observe how people work on a given problem, their approaches, “secret sauce,” and bag of tricks. I often feel inspired to pick up some of these traits and skills, and improve my own way of working as a research scientist. I have found that the best collaborations are time-boxed with clear deliverables and role clarity.

I worked with the Tableau Maps Team for a period of six months to develop a search relevance algorithm that would rank places in the data domain higher than just place prominence. For example, when users search for “Paris” in a map of the US, “Paris, Texas” would be ranked higher in the drop-down list than “Paris, France.” In other words, I was tasked with researching a search relevance algorithm that took into account the domain of the data rather than just based on how popular the place is. Engineers carved out a separate module for me to work in, as I iterated and tweaked the ranking parameters. Beyond being part of shipping the feature, it was a valuable learning experience. I closely watched how a product team operated, prioritizing decisions, and writing production code. The expectation was that once we were happy with the results, the code-reviewed algorithm, along with relevant unit and integration tests would be integrated into production. The work expectations and timeline were clearly defined at the beginning of the collaboration and my value-add was known to the team, making for a very pleasant and productive collaboration all around.

For collaborations involving paper deadlines, setting such a timeline comes (almost) for free. However, it is equally important to have self-imposed deadlines when consulting with feature teams, developing strategy road maps, vetting startups for acquisition, and other community service obligations, including being on conference program committees. I often explicitly ask the other party what timeline they have in mind so that I can load-balance my work accordingly to suit their expectations. Deadlines also help me prioritize my time, work on what’s important, pacing myself without burning out.

I will also add that a time-boxed collaboration can help bring a less effective group project to a close if it isn’t going too well. For example, I started looking into mobile interfaces for search with the UX Team at Tableau. After a couple of months, midway into the project, we realized that the project was no longer a priority to the product roadmap at that time, and as a group, we were spinning and not moving forward. We made the decision to stop continuing, document what we learned till then, and decided as a group that we would revisit this if and when the timing was right. No bridges were burned, and everyone was in fact relieved to move on.

The importance of having good mentors

I believe that mentors are a critical aspect of one’s professional journey where you can have grounded and often candid conversations to shed light on new opportunities and overcome challenges in a way that feels actionable. Radical Candor is a great book that I have found helpful in both identifying good mentors and deriving value from such a partnership.

Over the years, I have been fortunate to have had mentors who have helped shape my career in different ways, providing guidance and instilling confidence as I continue to grow professionally. One of my earliest mentors has been Pat Hanrahan, who really supported and nurtured my love for semantics and graphics from my early Ph.D. days. I can still count on him to talk through research and work over a good cup of coffee. Jock, who was my first manager here at Tableau has evolved to being a mentor and a friend who provides sound, technical advice, and feedback. Mentors are also helpful for offering their perspective on other soft skills that are required to grow professionally and personally. Being a woman of color, I regularly seek guidance from other women who have navigated similar issues in their own lives.

Having great role models as mentors has also helped me pay forward and mentor upcoming research scientists and young women in the field. I find it immensely satisfying now to spend time and work through topics that my mentees bring to the conversations. Reflecting on their questions and struggles helps me introspect on my own experiences, helping me be a more empathetic, sensitive, and effective leader to my team and colleagues.

Listen, listen, listen

While part of a research scientist’s job is to give talks and communicate their ideas to a broader audience, the most important skill that I have learned over the years is to listen and observe what people are saying. Whether seeing how others react to my ideas or how they animatedly talk about their own, I follow body cues, voice intonation, and language to calibrate my thoughts as I make sense of my world. Being part of a bigger company, I like to listen to people from different parts of the organization — product managers, architects, UX designers, engineers — understanding what matters to them and to their team and how that translates to my own work. I am also a voracious reader (yes, that’s part of listening too) and try to stay abreast of what is going on in the market and industry at large.

Tableau has an annual customer conference, which is fantastic as it provides a close-up view of how customers react to new product feature releases, presentations, as well as concept ideas. For example, in 2019, we ran user studies for various chatbot interfaces (voice- and text-based) to 30 study volunteers at the Tableau Conference. Feedback from these studies provided valuable insights regarding people’s expectations and interactions to a chatbot and which modalities are worth pursuing. While voice-based chatbots seemed rather cool and novel at that time, we realized that their utility for users conversing with data was very niche and limited. Text-based interactions turned out to be promising, and the ideas are even more relevant now given that Slack was recently acquired by Salesforce. So, keenly listening and observing actual people who would potentially be the ones using these ideas, brings ecological validity to your work, functioning as early assessments when formulating and identifying longer-term projects to tackle.

Writing as an organizing principle for communication

Publishing for the sake of publishing has never been a priority for me, and that is one of many reasons I shied away from academia. However, writing is an effective way to help organize my thoughts and clearly describe why a certain approach was taken and what research problem it solves. For deadline-driven people like myself, submitting academic papers is a great way to make progress on research ideas and have that work peer-reviewed. Having a paper that addresses customer needs and the company’s mission and is accepted at a top conference can be a rare “ double-word score.” Even during my stint as an engineering manager on the Ask Data team, I published several papers with folks on my team, articulating the thought process that went into the feature. These included work on handling ambiguity in the input utterances, visually representing vague concepts like “high” and “low”, and supporting an analytical conversation through pragmatics. Research-inspired engineering is not new to Tableau; after all, it is a company that was founded on a set of award-winning academic papers such as Polaris and Show Me.

While academic papers can demonstrate external thought leadership, it is just as important to work on relevant problems that don’t feel esoteric. In fact, white papers and blogs are also effective ways to communicate and share ideas with a less academic audience. Working at Tableau, I also enjoy writing technical specifications, state-of-the art survey writeups on a topic of interest like natural language generation, or how ElasticSearch APIs can be used for search. The exercise keeps me abreast of what is going on in the industry. The art of good writing is to clearly convey the intended message to the audience at the right level of detail to help with action-driven decision making at a company. I often study good exemplars of writing as inspiration — maybe it’s a strategy document that was well received by leadership or a best paper at a seminal conference. Often conferences publish author guides that I have found useful, such as “​​How to Write a Successful UIST paper.”

Closing thoughts

Industry research is invigorating and constantly keeps me on my toes. I find myself continuously recalibrating and balancing longer-term blue-sky ideas while trying to stay relevant to the company. As an industrial research scientist, one needs to be flexible and adapt to whatever makes sense to push that idea forward in a way that fits the mission of the company. Being passionate, creative, and persistent with an entrepreneurial mindset also helps. These characteristics have served me well at Tableau, particularly with my unconventional background. I embraced various opportunities, learning and evolving along the way; from collaborating with research scientists who have strong visualization or NLP backgrounds to working as a partner to the Maps and Search product teams, or jumping headfirst into being a production-coding scrum-attending engineering manager embedded for several years in the Ask Data team, being part of all the sausage-making was incredibly educational and shaped who I became as a research scientist. Each journey has given me something to carry forward, whether it’s the art of writing quality software, crafting persuasive strategy documents, or compiling beautiful LaTeX for research papers. Most importantly, I have found a community of amazing people who continue to inspire me.