Data Insights bring everyone to the table (Guest: Julie Lemieux)

Julie: Data insights are not things that you just deliver to somebody. Right. They are open doors so that people can keep asking questions and explore new paths to insights as a group, as a community. Right? And if you share data that's live and can be further explored in new ways, well, that effectively is a data conversation that leaves nobody behind.

Ben: Welcome to the Masters of Data podcast. The podcast that brings the human to data. And I'm your host, Ben Newton. Welcome everybody to another episode of the Masters of Data podcast. So I'm really excited today to have Julie Lemieux on from Sigma Computing. She's the VP of User Experience, Design and Research over there. Welcome to the podcast. It's good to have you on.

Julie: Thank you, Ben. Nice to be here.

Ben: So what we always do on the podcast, Julie, is I love just to learn more about you. I know you have... I've found that designers in general have always have interesting backgrounds of how you came to it. So tell me a little bit, what's your story? How'd you end up in design, how did you end up at Sigma Computing? Kind of what's driving, what's got you to where you are?

Julie: I love a good origin story. So when I left my undergrad, I thought I was headed for medical school. And lots of things happened in those intervening years and it turns out medical school really wasn't for me. But I had spent a lot of time as a kid exposed to computers and especially exposed to spreadsheets. My father is a mineral economist, or was a mineral economist for the Government of Canada. And he had a desktop computer really early on at the house. And his job was really to work a lot of data to understand, and to track mineral reserves in Canada and then mineral rights from Canadian companies outside of the country. Different mineral rights in Australia, all over the world. And the vast majority of his work was database driven and then working it all in spreadsheets to basically do the numbers. And then I started doing things like desktop publishing and business cards and whatnot, to make it a little bit of extra scratch when I was in high school and in university. And then the years when I, in the year that I left this whole pursuit of becoming a physician, the internet was really starting to take off. And I was moping on my dad's couch and he suggested that I look into this internet business.

Ben: Go find a job.

Julie: Yeah. That was nice dad speak for go find a job. Yeah, go check out this internet business. Maybe you can make a career out of it. So I started doing some research and it turns out that I found a great post grad program in Toronto to do digital design. And very quickly after graduation, I found myself here in California working my tail off during the last half of the dotcom boom, which was, those were my formative years in the business. But design for me was one of those things that sort of made sense because I really like to break down problems, I think very systematically and very architecturally. So when I encounter a need, when I encounter a desire, it's just intuitive for me to start to break it down and think about how to sequentially build that task up. How do I work backwards from the goal in order to get somebody to achieve that thing that they want? Sometimes it's huge. Sometimes it's a little bit like the deconstruction of that problem and then rebuilding it back up in a nice environment that's pleasant to use. That to me just, I mean, that's what makes my day go really fun, frankly.

Ben: Yeah. And that makes a lot of sense. And how do you approach design particularly where you're at now with Sigma Computing? How are you thinking about it? What problems are you trying to solve?

Julie: So in short, the problem that we're solving is that data analytics and BI fundamentally have left the vast majority of people in an organization kind of behind, or at least severely underserved for that.

Ben: Right.

Julie: And the idea with Sigma is to conceive of design and build a BI and analytics product that breaks down some of these barriers and allows the folks that have been underserved in their organizations to not only have access to data, but also have the right tools required to answer their data questions and to derive their own insights. And the company in and of itself is built on the premise that people don't need to know SQL or Python or R or complex statistical models in order to explore data. And so everything that we're doing is to remove all of that business from the view of the user. We take care of all the heavy lifting. We talk SQL. We know how to do that. But the users that are engaging in using the product for their own data driven insights don't need to do that. So we're kind of in the business of absolution in a way, right. We're absolving organizations of having to hire people that know SQL, R, et cetera, and absolving business users of needing to learn those skills in order to access and to participate in data conversations with their organization.

Ben: Yeah, no, that makes a lot of sense. And so I'm assuming as part of that, particularly are you, I expect that you're having to take a different approach than what's been normally taken. Cause I'd almost say that in the past it's really been focused on flexibility and powerful super users that know how to, like you said, know how to write these query languages. And now you're trying to connect with people that are not experts that are, that you need to take approaches that's really making it easier for them to get it today without learning all these things. Kind of a human centric approach. So I mean, how are you having to do things differently, you think, than what was done before?

Julie: So there's a couple of things that we're doing differently. The first is that we are very concerned with making sure that all of the features and functions that we deliver are accessible to people who don't have sort of a deep technical background. But that in a way is sort of like the second or third phase of what it is that we're doing. The fundamental anchor of our design practice at Sigma is that we are actually going out and talking to people about their feelings as it relates to data, data analysis. And we're trying to empathize really, really deeply and connect with our users to understand needs, feelings and challenges that people encounter, not just when using software, but what's preventing them from engaging fully and actualizing their needs and objectives as it relates to data. Many organizations, especially technology organizations have made it a corporate mandate that the data should decide. The data has to lead. Data has to inform your decisions. Data insights should drive. Okay, great. But when you make a corporate mandate, that means that you're also telling everybody in the organization, people who don't know how to code, might not have had statistical or analytics backgrounds in school, you're telling them also that their business or their work should be data driven.

Ben: They have to engage. Yeah.

Julie: They have to engage. So one of the things that we're deeply concerned with at Sigma is that if an organization chooses us as their BI and analytics vendor, we have to fulfill on giving everybody in that organization equal access to being able to participate in the conversation. And the old world, the world that we have emerged out of, data happened to people.

Ben: Yeah.

Julie: Reports were delivered- It's true, right?

Ben: I like it. I like that. Right.

Julie: So reports were delivered via email every day. You got a PDF. Maybe if you were lucky, you got a CSV file, but effectively those things were a cul de sac. It was impossible to be curious and explore data from that. So you got an answer. Okay. Well the answer to this morning is 12. Okay. But why? And if you're looking at a PDF, there's just absolutely no way to answer that question. And so Sigma's view is that data insights are not things that you just deliver to somebody. They are open doors so that people can keep asking questions and explore new paths to insights as a group, as a community. And if you share data that's live and can be further explored in new ways, well, that effectively is a data conversation that leaves nobody behind.

Ben: Yeah, no, I like that. In simple, if I'm getting a bit of your metaphor there, is that if you make the door easier to open and the distance is smaller for them to travel, then people will do more and open up new avenues that might not have even been thought of before. Because the people that had originally been using the data didn't even have those backgrounds. Cause I, there was a, we brought a guest on the podcast that was, he started a data science team at a furniture company or manufacturing. And it was really interesting to hear him talk about it in the sense that you could really being able to connect with the decades worth of experience with these people that are in business units designing the furniture, but didn't know how to connect that to the data. You make that connection and suddenly innovation springs up where you'd never seen it before. And that seems to be a lot of what you're talking about there, right?

Julie: That's exactly right. I mean, in the end, in talking, when I first met Jason and Rob, the founders of Sigma, one of the first things that Jason said to me was" we believe that everybody is smart and everybody has the capabilities to find insights and explore that data, no better or no worse than anybody." So if the premise is that everybody's smart and everybody has the capacity to find, derive and explore data, well, you're going to build a tool that levels the playing field and doesn't necessarily favor a specific kind of person in the organization. So when you think about building a tool that fulfills the data needs of an entire organization, you can't build a super complex tool that relies upon technical knowledge that you would have gotten out of a CS degree. You have to build the tool based on interest, desire, and inherent consumability of data so that everybody can see.

Ben: Yeah. Yeah. And one interesting thing that, I'd be interested as to how you think about it. Because in the past as with a lot of technologies in this space, is that because of the way it was developed, typically the people that were developing and building these data tools were not the business users. They were in the IT organization, sometimes even security organizations, maybe some sort of business operations organization. They kind of held the keys to the kingdom. So how have you guys seen, what does that actually look like? Because in some sense, those people don't leave the equation. They're still very important. They're going to be an important part of enabling these other business users. But how do you balance between the people that are still going to, I expect are still an important part of the process, versus the end users who are actually closer to the business? How do you balance that whole conversation? Data conversation back and forth and data ownership.

Julie: That's actually a really good question. We've been doing a lot of research in- house on that very topic. And what we essentially see is that in the past, data teams themselves were the ones that were the business's primary interlocutor when it came to asking questions as the data. So a typical, in my past with SAP, we saw this a lot, which was that business users would have a question. It either came from a mandate from an executive, a supervisor, a board member, whatever," find me the answer to this," or" show me the data on that." And the business user didn't really have the agency to open up a tool and to go formulate that question and those answers themselves. So they had to go talk to somebody on the data team and explain to the member of the data team what the business case was for what it is that they needed and why. And while people on data teams are very intelligent and are incredible stewards of data, sometimes they don't necessarily understand the business context of the data, how the data should be interpreted. And so what you would get was a business user making a request of somebody on the data team, the member of the data team doing their level best to understand the question, understand the data that was required to answer the question, but more difficult, how to shape that data and visualize that data to actually answer the business user or the stakeholder's question. And so what you would get would be sort of this frustrating game of telephone." I want this."" Okay, I gave you that."" Well, that's not quite right. Can we tweak this?"" Ooh, that data's not right."" Ooh."" Oh, are you using the right calculation for this particular metric?" And the process of actually getting those answers or getting that view of the data was very long and quite frankly, pretty frustrating for most involved. And so the idea here at Sigma is that when you put both of those groups and you look at them and you start asking questions about what it is that their needs are, you wind up seeing things essentially in basically three camps. There are business users who are very interested in finding answers to their own questions. And so they have need in the moment to understand some kind of metrics, some kind of trends, some type of whatever. There's a business need. They need to go find it. You have a second group, which are members of the data team. And their role is, in a way, it's fairly altruistic in that they receive requests from business users and they essentially adjudicate those requests. They get stacked in priority and they crunch reports and chuck them back over the wall. And then there's a third group of people who are even more altruistic. And these are like data team leaders, offices of the CIO, Chief Data Officer, Chief Technical Officer, whoever is running that particular part of the business. Those people, their role is to help elevate the data conversation and facilitate data access and grow data literacy in their organization. And so when you talk to people and you realize that this is a continuum, and that if you can start absolving members of the data team from constantly adjudicating ad hoc requests, they can start thinking about the data landscape in bigger terms, more strategic terms. They can advance their data posture, governance, storage, what have you, and not have to adjudicate so many reports constantly. And our research is showing that if you support the business user's ability to not only ask the question, but then to safely explore, access and shape the data, you sort of de- conflict the data team. And they can start doing the things that they really want to do rather than creating reports in an ad hoc fashion.

Ben: Yeah. That's a really interesting way you put that, Julie, because that actually makes a lot of sense. Because it's putting the data team in an odd position where they're having to make value judgments and priority judgements for things that really aren't part of their purview. By doing that, they can focus on things that are clearly in their purview, and actually make it better. That actually makes a lot of sense. As part of that, partly what you're talking about here is kind of reducing the friction and allowing people to... Because I know having been in this industry like you for 20 years, a lot of times what the problem was is the back and forth would take so long. It was just kind of the nature of the beast is that you would, they would ask a question, you think you're getting it right. I was kind of sometimes on that other side where I'm trying to help people get data, it was like," Oh, well, that's not quite right." Okay. Well now we have to go back and do it again. Oh. We don't have that data. And you had this. And it's so painful to get at the answer that nobody wants to go through that process again. You reduce the friction, then it's a lot more likely they should get the better answers, so you can get to what you want. But as you start to lower these barriers, who are you seeing? Who comes to the data trial first? What parts of the business are you seeing that are kind of the first in line? Is there any trend around that or is it really just kind of whoever is, it's just kind of by the organization. Are you seeing any trends around that?

Julie: We are seeing some trends. So there are definitely some organizations and some specific roles that are coming to mind. I'm going to start in the sales and marketing direction. So what we're seeing is that sales and marketing organizations, especially sales and marketing operations, are really, really hungry for this data and this ability to access it and shape it. And for them, at least the folks in sales and marketing operations that we've interviewed and talked to, they are ostensibly responsible for generating a ton of data. So when you think about somebody in sales operations, they're responsible for... their Salesforce. com instance and all the data that that generates, and any other tools that they're using in order to track sales, look at the pipeline, et cetera. Those people who are responsible for the generation and custodianship of this data effectively don't always have the best ability to go in and query that data, understand what's going on and to build their own view of the world. They're fairly limited to either the canned reports that come out of the tools that they're using, or a great deal of effort in order to customize those reports. So they're hamstrung in a way to access the data that they're responsible for. So that particular group of people is very, very hungry for the product. In addition, we're seeing a great deal of demand from product management. Again, another group of people who are effectively responsible for a great deal of data. So when you think about product teams, they are focused on understanding user behavior. So 19 for example, is very interested in that. They're very interested in understanding feature adoption. Who's touching a new thing or not touching a new thing. Is it succeeding, is it not. Product managers who are responsible for retail experiences, are interested in understanding card abandonment, or what products are doing better, et cetera, et cetera. Well, if you don't have a tool that's fairly ubiquitous for all of those groups to use, they're not going to do as well and have the insights that their business is looking for them to generate. So product management, engineering teams, design teams are also asking for the product because it has been notoriously difficult for those groups to get the right kinds of tools in order to do the analysis that they want.

Ben: Hmm. Yeah. It's really interesting the way you say that, because having been a product manager myself and now in marketing, one thing I saw is that when, let's say you have, because the kind of data you're talking about might be particularly controlled by engineers or maybe by some sort of like IT like organization or something like that.

Julie: Frequently, yes.

Ben: Yeah. And typically that siloed data is going to be used for a very particular purpose, which are hugely important, like understanding uptime and really like operational needs, maybe security needs. But then when you start talking about the things that a product manager and potentially product marketing and people like that care about, you're now having to connect very intricate, almost bespoke in a way, data about what your users are doing, which, as a product manager, I was obsessed with, because you had to be. But now you're trying to connect that to systems that seem miles away. Like you said, like Salesforce. Because now I want to see, okay, I know product adoption over here, but I need to connect that to this data over here that tells me what are we actually selling. Who's buying. How is that going? I'm seeing users over here do X, how does that translate to what's going on in the real world with salespeople that are actually talking to real people. And that has traditionally been very, very hard. And I can definitely see how you make those connections and suddenly new insights just explode that you would never have before. But those systems are often really, really hard to connect. I can see how that's a good place.

Julie: Here's a good example. So as part of our research initiatives right now, we're trying to understand how different sizes and different configurations of organizations are using the product differently. And that is virtually, when you're looking at product utilization data, it is virtually impossible to understand and segment that behavior and those users based on sort of organizational criteria. And so inherently, what I want to do is take Salesforce data, all of that great intelligence and understanding of the customer that our sales and sales engineers have done, and I want to take that data out of Salesforce, and I want to marry that to product utilization data and end user data, and some of the qualitative data that we have picked up in our interviews. And I'm going to mash that all together and understand at a higher level what my users are doing. And in the past that's been utterly impossible because the Salesforce data has never been accessible to me. Not because I shouldn't have access to it, but because the systems weren't integrated in such a way that allowed me to quickly and easily join data from seemingly disparate sources to make a new data insight or a new data conversation out of it. Sigma essentially breaks down those barriers. If you are able, and have been given permissions to access a certain data source, then the sky is the limit with how you can merge those sources and look at them in context one in the other.

Ben: Yeah. And I would assume like that's part of where the partnership between what you'd call the data teams and more these, call them business users or specific users, comes in. Because that use case that you just talked about, one of the reasons why that's complicated is not just access. It's also because there's this meat and potatoes question about how you connect the data, right? What is a... what is a user? Yeah, well, user, they're right there. I just talked to them. Well, what is that? Is that an ID number? Is that an email? You know? What's an account? I just talked to them on a call. But is it an ID? Is it a name? Do they spell it the same way? I remember when I started out with this, your customers would miss, would... these engineers were putting these weird names for their accounts and like lowercase, and then it wouldn't match. And I mean, there's a lot of complexity underneath there. So does that, is that how you actually see it play out? Is that now the data teams are worried about the mechanics and the flow and the connections of the data so that the business users can actually worry about the questions? Is that how you see it kind of come out?

Julie: I mean, there are deep participants in helping understand the data. Let's not kick them out of the conversation entirely. But their role with a system like Sigma is to make sure that those who need or want access to specific data sources in order to further their own work, have the ability to do that. So last year we introduced our visual modeling system. And the premise of that set of features was to allow data teams to build up pieces of data or building blocks of data, if you will, that had been prepared, that had been cleansed, that had been tailored and shaped in such a way to help business users understand it, and to be able to interpret it and use it much better. So when you think about... when I go into our warehouse, for example, I'm seeing schemas and tables, and they go on forever. There's literally hundreds of columns, tens, hundreds of thousands of rows of data. And that in and of itself is pretty intimidating. When I have a quick question I want to answer, going and spelunking through a warehouse in and of itself can sometimes be, well, it's a gate. And so the visual modeling system allows data teams to look at those tables, look at those schemas, and shape them in such a way that a business user will be able to consume it with the business context intact rather than just sort of the rows and columns. And then having somebody need to shape that further. So the data teams can take away some of the burden of initially shaping the data for a business context. And then that allows business users to quickly get in there, look at something that is purpose built, and then build their own explorations and take that into new directions for themselves. So the data team has an important role to play here because as the custodians and the stewards of the data, it is inherently in their remit to make sure that that data is usable and consumable by the people who will be making decisions with it.

Ben: Yeah, no, that makes a lot of sense. I don't know why for some reason this analogy is coming to my mind that the data engineers are gassing up the car and bringing it, or maybe charging the car if you want to be more eco- friendly, and bringing it around to the business users, but they don't have to chauffer the business users everywhere. The business users can drive themselves and bring the car back. But there has to be a certain level of, there does have to be a certain level of prep work and set up. You got to have gas in the car, you got to have it in the right place. But after that, you don't have to be the intermediary as these business users are asking the questions. Which is where the real value comes is being able to quickly and rapidly ask and reform your questions as you understand the system. Does that ring true to you?

Julie: Absolutely rings true. You know, the role of that data engineer in the organization not only is to make sure that the data is flowing, it's being stored correctly, that those pipelines are up and healthy, but to make sure that there aren't any encumbrances in the way of business users using that data. And there is a massive amount of data that goes unused. It's collected, it's stored. It goes through all sorts of gymnastics to get into the system. But a recent Gardner study suggests that only about 35 people, 35% of people are actually leveraging insights from the data. And when you think about that, so much data is being collected in all of our systems and it's collecting dust. Companies are not monetizing that data or getting out of it the insights that they need to take their businesses even further. I mean, it's a shocking statistic. When you think about how data centric we've actually become, especially in the technology industry, that so many people are being left behind in understanding the full value of that data and deriving every single morsel of value that they can out of it. I mean, to me it's a shocking number. And the whole point of Sigma is to start increasing that 35%, very, very fast. Get more people in the data conversation because that's the way the business is going to grow. The answers are in there. You just have to give people the keys to get inside.

Ben: Yeah, no, that makes a lot of sense. And it's something that I've definitely said before, and I've seen said other places is that I think sometimes particularly if you look to the foibles of the big data movement and how that was all about," Oh, I've got all this data and it's so complex and interesting." And they just would shove it somewhere and it's like," Oh, we've got the data now." And didn't know, weren't able to leverage it. And if you look at the companies that have been truly mind- blowingly successful with their data, it's not just because they collect lots of data, but it's how they can leverage that data and connect the dots and be able to do that in a agile, rapid way. Because I mean, a lot of these, there's the obvious examples like Facebook and Google and these like large companies that are focused on data. But in general, it's also about the smaller companies and your more mainstream companies that, if they can find a way to connect that core, valuable data that almost every company has and be able to connect those dots and inform their business decisions faster, if they can move faster, they're going to be the ones who win. And so that 35% there, I guarantee you, if you looked at how their success is from business perspective, it's probably significantly better than the other 65%. Does that makes sense to you?

Julie: It really does.

Ben: Yeah. And I think that's kind of, we've had a couple people on the show that have talked about that. I mean, we've talked about it from an artificial intelligence perspective, data perspective, and really all it comes down to is that we're having to move, kind of like bringing this all together, we're having to move from, it's not just about the data. It's not just about the flow of the data. It's not just about getting a bunch of data scientists and data engineers and building some monstrosity to store your data. But it's also about how do you actually empower and enable your organization and do it. And it was interesting as you were talking about it. One thing that comes to mind, and I saw this in the past, particularly where my background, is that a lot of these technology organizations, the teams within these companies, have to move from being gatekeepers, which really implies shutting and opening gates and keeping people out, to being enablers and empowerers. And that's sometimes a hard transition, but the companies that manage that both technologically and culturally, because there's a whole cultural angle here that we barely touched on. The ones who can do that, those are ones that are going to succeed.

Julie: I completely agree. We're seeing, in a number of our customers, we're seeing the emergence of individuals within those companies whose role is entirely that. It's to facilitate access to data. We have a number of customers where their heads of data, once we interviewed them and really understood how it is that they were going to be working to grow data literacy at their company, their entire remit is not about system construction and data storage. That's part of it. But their remit is really to take those systems and expose the data that's inside to everybody across the company who wants and needs access to it. It's a mindset shift. And that kind of comes back to the inherent humanity of all of this. I truly believe that as product teams, as software companies, yes, our job is to build software and we design stuff and we write code and do research and we build business cases. But at the heart of it, there are human beings that have to access these systems and to fulfill the goals of their jobs, to grow in their skills, to get promoted, to drive their companies to greatness, to meet KPIs. But there's a human being underneath all of that, that has challenges, fears, lack of knowledge. Like a common fear that we hear across our user base is that people are afraid of breaking the data or overwriting the data. So if you can take a group of people and you can understand the humanity of what prevents them from feeling comfortable and open to exploring data in systems, we have the opportunity to continue designing and building a product that will embrace them and teach them the skills that they need to succeed. And that success comes from easy access, easy exploration, and easy sharing of data across the organization. But in the end, these are not technology problems. First they're human problems. And after that, as technologists, then we can sit down and push pixels to our heart's content, think about semantics and architecture and develop tools that are going to help them. But fundamentally, if we don't approach the problem as an inherently human problem, we're going to leave a lot on the table and a whole lot of people behind. And that is in fact an antithesis to what we want to do as a company.

Ben: Well, I think that is a fantastic note to wrap this up on Julie. Because I absolutely agree that literally you could set that music, you could set the story of the technology industry to that music for the last 20, 30, 40 years. It's not about the technology, it's about the people. I love that. I think that's a great way to wrap this up. Wish you all the luck and thank you for coming on the podcast. It was good having you here.

Julie: Thank you, Ben. It's been a pleasure.

Ben: And thanks again everybody for listening. As always, you can find us on iTunes. Rate and review so other people can find us. And take care of yourself and stay safe.

Speaker 3: Masters of Data is brought to you by Sumo Logic. Sumo Logic is a cloud native machine data analytics platform delivering real time, continuous intelligence as a service to build, run, and secure modern applications. Sumo Logic empowers the people who power modern business. For more information, go to Sumologic. com. For more on Masters of Data, go to mastersofdata. com and subscribe. And spread the word by rating us on iTunes or your favorite podcasts app.