Unveiling the Secrets of Effective Data Collaboration with Mode’s Benn Stancil

Datamasters is the go to place for data enthusiasts. We speak with data leaders from around the world about data analytics and the emerging technologies and techniques data savvy organizations are tapping into to gain a competitive advantage. Our experts also share their opinions and perspectives about the hyped and overhyped industry trends we may all be geeking out over. Join the Data Masters podcast with your host Anthony Dayton, Data Products General Manager at Tamer.

Welcome to Data Masters. Today's guest is Ben Stancil, CTO and co founder at Mode. So welcome to the conversation. Ben. I thought maybe we could start a little bit with your career history and trajectory as you came into founding Mode. You know, you started your career at Yammer, which and was quickly subsumed by Microsoft and I think you had some pretty different roles there before jumping in and starting Moat. So maybe just share a little bit about the founding story and how you found yourself at Moat.

Yeah, for sure. So as you mentioned, I started my career in tech at company called Yammer. Prior to that I worked in dc. It's like a, in a policy research role, very different than, than things that go on in tech, but ended up in in tech at Yammer was on a data team there that was one of these kind of early incarnations of what has become kind of a modern data team. So it wasn't a BI team. Our job was not to produce dashboards and reports, but we also weren't kind of a capital D data science team that was responsible for building models that you know, generated like predictive algorithms or products and things like that. We were something, we're basically sitting alongside folks in the business. They're trying to make decisions about which marketing campaigns to run or which products to ship, kind of which strategic decisions we should make as an executive team. And our job as a data team was basically to advise them on those decisions or to give them sort of support around here's you know, what the data says about how different campaigns have performed, about how these products are performing with users, about what those behaviors might, might suggest, about what we should be building in the future, things like that. We actually so that team because we weren't just building dashboards, but because we also weren't doing like deeply technical work. We actually didn't have many tools that worked well for us. We ended up kind of in this middle ground between the traditional BI players like, like Tableau or MicroStrategy at the time where it wasn't just about building these dashboards, but also we couldn't use the kind of Technical tools that were designed for sort of proper data scientists. Because even though we knew some of those languages, like we had folks on the team who were very comfortable in Python, R and things like that, we couldn't send a, you know, a Jupiter notebook or a, an R Studio like file to the executive team. We couldn't be like, hey CEO, here's an R markdown file. This is their answer to the questions like, please don't give us this. We need something we can actually consume. Give it to us in a deck. And so we ended up doing a bunch of work kind of in, in tools that were designed for us and then having to kind of translate them into tools that were designed for other people around the business more easily consumed. And so we ended up building internally was a tool that kind of bridged this gap where it allowed us to work basically by writing SQL queries directly on top of our warehouse and then easily put charts and things on top so that we could work on kind of the technical flows that were the ones come from us and the rest of the business could, could basically consume them in the way that they wanted to and kind of these nice layouts and things like that. And again, the point wasn't to build just dashboards. It was like be collaborative with them, answer questions, help sort of this back and forth that goes into us trying to actually help them out with what.

They'Re trying to do.

And so we saw that basically it worked really well at Yammer. After Yammer got acquired by Microsoft, that product started to spread inside of Microsoft. We realized there was a bunch of other companies that built similar sorts of tools. So versions of these existed inside of Uber, inside of Facebook, inside of Airbnb, inside of Pinterest, inside of Shop, Spotify, rather, they all had the kind of same sort of query tools designed for data teams to solve exactly this problem. And so in seeing that, we basically realized that there was, there was potential value in building a product for this type of data team that again wasn't just building dashboards, but they also weren't doing kind of what was at that point the, the very popular, like data science, predictive, like the sort of magical work, but was doing a little bit more of just the sitting alongside the business, helping them answer questions. And so really we set out for, for mo to solve that problem and saying, hey, what if we build a tool that is designed for a data team? But recognizing that their job is to, to work with everybody around the business instead of their job is to just sort of, you know, do do interesting analyses that ends up sitting on their computer and slowly going stale.

Yeah, and so I think one of the challenges in thinking about starting a business like this, especially when you did, which was nine years ago, is you're entering a space that's relatively crowded and listeners may or may not be aware. But you know, my history is I spent many years at a company called Qlik, which I think reasonably would be considered to be in the space. And today, you know, you have Qlik, you have tableau, you have power bi. And so this is a relatively, it's crowded in an odd way, crowded with some 800 pound gorillas. And so that makes it an interesting or challenging place to launch a startup. So I'm curious how you thought about that at the time and how you think about it differently today.

So at the time I would, I would say there, there's a couple reasons why we still, despite there were certainly a lot of players in the space, there are more now why at the time, you know, we felt like this was a thing to do. One reason, and this is probably true for a lot of startups, is like youthful naivete is, is some idea that basically, hey, you know, all of these tools have, every tool has their problems, mode certainly has its problems, but every one of these are tools has their own problems and some belief that you can build something that's better, you know. And in those cases there were a couple big changes there that were happening that we were in the midst of that we felt like we could take advantage of like the cloud being the most obvious one that we started moat around the same time that redshift started to become popular. And so there was a big shift from data tools being very much oriented around on prem warehouses, people being very, you know, particular about data security and things like that to still being particular about data security but being much more comfortable with doing that in the cloud. And so we felt that there was a, there was an opportunity to build something that was more cloud native instead of trying to, you know, a lot of these tools were going to try to move to the cloud, but that was kind of a notoriously hard thing to do. And so we felt that there was, there would be an opportunity to, to, hey, we're going to build sort of a cloud first version of this that also opens up other markets where it's not just saying like hey, you know that the, the big players are going to want to, it's not that Boeing is going to want to go out and be like oh, we need a cloud tool we're going to go buy it. It's more that these tools are becoming increasingly less expensive. So what used to cost a million dollars a year to run like a teradata warehouse, you could now pay for, for one in redshift for a thousand bucks a month. And so now there would be a lot more interest in being able to use tools that can sit on top of those things that we felt like we could take advantage of and, and providing cloud software kind of give us the economic structure to basically be able to do that. The other thing that we thought was basically like those tools were for a, I don't want to say dated, but like a different version of the way that data teams were working and constituted, that they were very much designed around the idea of like reporting, dashboarding, that kind of stuff. What we increasingly saw were there were these teams that job were to be kind of strategic, that they were supposed to be, that they saw dashboarding as kind of like a necessary evil, but wasn't what they wanted to actually be doing. They wanted to be doing things where it's like, do more impactful analysis and those kinds of things. You know, I think 10 years into an end, you could talk about whether or not that actually has panned out, whether or not there's actually been like, how much have data teams really delivered on that promise of being these like great strategic advisors and help people make decisions and things like that, versus getting out of some of the dashboarding that they typically do. Like, there still is a lot of dashboarding, much more so than I think people would have thought there would have been 10 years ago, given sort of the trends we were on then. So, you know, to what extent has that worked out? Overall? I, I think data teams are still trying to figure some of that stuff out, but that was another thing that we really wanted to kind of push into was let's how do we enable teams to do more than, than the kind of like traditional reporting and BI type of work that they had done before. So actually back in modes very early days, we didn't see ourselves as a BI tool at all. We tried to like, you know, we try to avoid that characterization. I think over time we came to realize that all of these things are BI in one form or another. They just kind of take different cuts at it. And so we're much more comfortable with that now. But, but yeah, I think that at the time we saw it as more of like a data team productivity tool as much as a traditional dashboard in our BI tool.

Yeah, no, I think this challenge of the dashboard is. And even when, frankly I think Qlik struggled with, there's the sense that, and sort of like dashboards aren't enough. And also the sense that the data behind the dashboard is the thing. It's the thing that often people struggle with the quality of that data. So they're struggling with. They see the data in the dashboard and they're like, well, this is wrong. This column is wrong. These records are clearly duplicates. It's a problem clearly Tamer's trying to go after. But, and I used to say this, the most popular use case for these tools was as export to Excel. So people would go into Qlik, they would do a bunch of work and then they would dump the data in Excel often to fix it up, often to repair errors in the data, but also sometimes to mash it up with other data. And I think we struggled a lot with trying to think about how to in a sense avoid export to Excel as a way to sort of, you know, the theory being to keep people in the tool. That's a, that's better. I'm curious how Mode thinks about that. By the way, as a slight joke, I used to say that every time someone clicks export to Excel, an angel loses its wings. That was the, the internal and as a way to get people motivated to solve the problem. And I don't think we ever did, truth be told. But I'm curious how you think about it.

Yeah, I mean we, we had a similar sort of feel that Node's second most popular, most first most popular piece. Mode's like a query. It like it has a thing that connects to databases. You can run queries, build charts, things like that. The first most popular feature is connecting to a database because you can't use it unless you do that. It's second most popular feature is export to CSV. And like, you know, we had, we had some of the same anxieties, I would say, about that where it's like this feels like people are ejecting from the product. Clearly we are doing something wrong here. How do we like keep people in it? I don't think we've really solved that. I don't think anybody's really solved that. I think this is a little bit of like a, a unanswered phenomenon, honestly, in the data space where everybody has kind of the like, well, you want to be able to play with it, you want to be close to it and tweak it and all that. And, and no matter what, you can't keep people in it. Like no data tool seems to be successful in doing this. So our view has kind of been like, we have gotten a little bit past the idea of, of thinking that that's necessarily a problem. That if, if we are a path to people needing to get something to Excel and that's what they're going to do, okay, like that's fine so long as we, we can be a fast path for that. You know, my hope is over time that we eventually figured out like, what is it that that secret sauce inside of Excel is that. That nobody seems to be able to escape. But yeah, I think, you know, we, we have struggled with this or, or you know, had the, the existential worry of like, what is it that we're doing so wrong if everybody just wants to use Excel, don't people hate Excel? Like people complain about Excel, but everyone's using Excel. And so I, you know, I don't actually have a, have a great answer as to what that is. We all have like our half dozen theories as to what are the things that makes Excel so popular. But I do think that there's, there is something we still haven't, haven't figured out there.

The other thing that I notice as I look at Mode, and maybe this is a bit from the outside, so I'm curious on your reaction here, but the idea of collaborating around data and maybe this is part of your background from Yammer and thinking about how you create a collaborative space for people to interact and comment and that sort of thing. It does feel like the idea of working together with, I mean Excel by its nature is a single user tool. Maybe Microsoft had argued differently around Office 365, although it's window dressing at best. But anyway, so it's very much a single user tool. But this idea that we all want to work together on data seems very intuitive and seems like a place of maybe a fissure that Mode's picked off. Is that fair?

Yeah, I mean we have done some work on that and I think, I think one of the things that the, the tricky parts slash like interesting parts about this is what does it mean to work together on data versus something else? I think that, that you know, it's not clear exactly how like collaboration. I think it's easy for people to think like collaboration is comments and it's not exactly clear to me that that's or like co editing in the Google Doc style thing. You know, I think these things all have a sort of different collaborative modes. Basically the way that people want to collaborate on data and analysis is different than the way they want to collaborate on, you know, putting together a doc versus collaborating on a PowerPoint versus collaborating on, on like a design and something like Figma. And so I think that a lot of the like, success or failures and the collaboration sort of angle to data tools is less about, you know, do we implement comments in the right way, but more about, do you sort of actually identify the places that people want to be collaborative? Like, do you figure out the things that are actually the places that people are trying to collaborate versus just kind of tacking on the, the stuff that we assume to be, to be collaborative. And so honestly, for us, kind of the thing that we felt was the biggest pain point in all of this and the thing that prevented most of the collaboration that we wanted to have when we were at Yammer or sort of in the early days of Mode was less about like commenting and more about just people being in the same space. It was that, that data teams worked in one tool, kind of packaged it back up, shipped it over into another tool. And so there was this very slow sort of collaborative loop where it was, we would do work, we would send it to something else. You'd have to take screenshots of stuff, they would ask questions, you'd have to go through this process of recreating the thing. If you send it to somebody else who wasn't the original creator, they would be like, I have no idea what this chart is. I'm going to do the thing where I like measure the number of pixels between these dots and try to figure out what that number was, you know, like the screenshot of the PDF. And so it was, it was more about avoiding those things than it was about like commenting. And so that's that to us. The, the key part of it was how do we make sure that people can work in the same service? How do we make sure that, that like when a business user looks at a dashboard and they have questions about it, that the people who created it can very easily see how it was created, they can very easily update it and kind of follow the flow of what it was, they can follow the flow of how it actually got to the place that it got there, that can see the history of it. It's those sorts of things to us that are much more like what is important for collaboration and data as opposed to, you know, Google Doc style editing. Like, sure. Do you want to co write a SQL query? Probably not. Maybe there's some uses for that. Like it's a little bit more of Like a, like a training tool. But yeah, the, the like nature of collaboration is just very different depending on the types of work we're trying to do. And so, so our approach to this was much more, it's actually about connecting all these pieces together than it is to sort of mimic what say Google Docs does for Word.

I like that idea of the common surface, this idea that you're working in the same playground or on the same surface or on the same sheet of paper. Maybe you're doing different things. I think your point about co editing a SQL statement is very apt. I mean maybe two developers might do such a thing. But the idea that I might write a SQL statement and you might interrogate the result of that and creating a tight feedback loop between those two things does feel quite reasonable.

And there is something sort of interesting in that, that even on the SQL side, one of the things that we saw early at Mode that we did not expect at all, and this has been one of the like very kind of unexpected successes honestly in the product is when we first built it, we expected it to be something that would be closer to like a Figma type of product where you'd have very clear people who are kind of the creators, the in their case designers, in our case analysts who are writing SQL queries. And then you have people who are, who are just consumers and you don't really have that much overlap. And so we would sell to the data teams, they'd be creating stuff. Everybody else would be these kind of like passive consumers and would like tweak parameters or filters, but wouldn't actually go in and write anything. And one of the things we realized actually pretty quickly was because we were saying here's a chart and here's a SQL query that's behind it. Like SQL is relatively straightforward to understand. Like if you don't understand it at all and you read some big complicated thing, you're gonna be like, I don't know what this means, but if you see a fairly simple query that's got like where date is greater than 2020 and less than 2023, like you can figure out what that means. And people did, and they'd be like, oh, I can change this. And I bet, I know it would happen. You know, this currently says we're like account ID equals 10 if I change it to account ID equals 11, seems pretty obvious what's going to happen. I'm going to do that. And so we actually saw a lot of people who were not technical or not people who saw themselves even as people comfortable writing SQL, using this as a way to actually teach themselves how to do it, and gradually becoming these kind of like pseudo analysts where they weren't necessarily trying to write SQL to do a bunch of analysis, but they could read it well enough to be able to make tweaks. And so again that that type of like collaboration with someone unexpected, where we basically realized if we put a bunch of dashboards and charts in front of people, but showed them how they were created, people were curious enough, they were like very capable to be able to read it and be like, oh, this is a good way for me to learn what I'm going to do. And so that type of stuff actually made a big difference too, where it wasn't even just like how do you make put them in the same surface, but it's actually putting the two things side by side. A lot of people started to teach themselves things that they wouldn't have expected to teach themselves otherwise. Cool.

So shifting gears slightly, a question I've been asking lots of people. You know, it is very clear that in the public zeitgeist this idea of ChatGPT has entered our vernacular at, you know, people are using it, kids are using it for studies, et cetera. The general underlying concept of generative transformer models and large language models itself is sort of interesting from a machine learning perspective. And it would seem to me if one of the challenges modes working to solve is the interface to data, this could be quite relevant and interesting. But I'm curious from your perspective if GPTs and large language models overhyped, underhyped, what's your view?

My view is it is like short term overhyped, long term underhypes. So I think that, that the immediate things that we are doing with it are okay. So I want to take two, two examples like, you know, everybody sort of is trying to plug various, you know, like GPT plugins essentially into their products. Mode is in the process of the same sort of explorations and all those sorts of things. A lot of them take a couple of forms. There are three main forms I would say that I've seen so far. One is like write a question, get a SQL query that answers the question or some version of that. Another is kind of like a code assistant that helps you write queries or whatever, similar to copilot. And a third one is like summarize a bunch of stuff like give me the, the summer, like auto document type of thing. I think the first one is really tough and I think we're basically like, we it works as like a toy. But if you do that on top of like actual complicated data and stuff like that, there's a lot of stuff you got to figure out to make that work. There are some companies that are attempting to do this in like much more robust ways. I think they'll kind of get there. So I do think it will change sort of the interface for how we interact with data, but I think it'll take longer than, than we think because figuring out how to make these like models actually do that properly and stuff is like a much harder problem than just like here's a schema, write a query. They, they do not yet do a terribly good job of that, but I do think it can change things enough to be like a good enough interface that this is now going to be somewhat more of the norm of how we will think about interacting with, with stuff. The, the third, the, the other second point I'll make, which is about the third thing about the auto documenting. I think this is actually where stuff is like particularly interesting on the auto documenting thing. It makes sense initially to think about like, oh great, we create documents, we want to auto document it. We use document Chat GPT to do it. We'll spit out a bunch of docs. Great, that's what we're going to do it make but like it makes sense now. But the question it really raises to me is like if you can auto generate docs, why have docs at all? Like what's the point of creating a bunch of docs that are just you can create on the fly? Like why do we actually even need those things to exist? And I think that's where a lot of what can happen with, with chat GPT or with these models or you know, the whole collection of sort of AI tools that are now starting to emerge is the entire ways that we start to use products look different. Like we assume, oh, we need to have all these documents because people search for them, they'll read them, all those sorts of things. It's like that kind of foundational assumption about how tools work, how the Internet almost works, doesn't necessarily make sense in a world where all of these things can be created on the fly. And I think that's, that's the part where I think it's like very underhyped. Not necessarily in the sense it's not going to solve all of our data problems, but in the way that the world looks in 10 years isn't going to be like, oh my God, every website is buzzfeed, every data Tool is just like auto generated all its docs. It's like if everybody can generate buzzfeed, we stop caring about buzzfeed and we start actually like creating things that look entirely different. And so I think like it's underhyped because we are currently just kind of exploring the edges of the way that sort of the models of our world currently work. But at some point we'll sort of break out of those models and Neil will have like an entirely new thing that we have to build on top of it. Like sort of changes the foundational interfaces into technology in ways I don't think we've like at all really started to comprehend.

Interesting. Yeah, I think that's a. There's a lot of built in assumptions. Your point about documentation is a really good one because the reason we write documentation is the interfaces for a lot of these products are so arcane that they need an explanation on the side to guide you through the use of them. In this context, imagining that we simply just interact with them in a very natural way becomes much more reasonable.

Yeah. Yeah. And it's, I mean, exactly. It's like if we don't, it's, it's weird to think like, oh, we have to actually have the exact same documentation for all of our software because our software is going to look exactly this. It's like, no, we don't need to auto create a bunch of documentation for how to use an iPhone. Like the user's guide for an iPhone is like two pages of a picture book. And like because they made it so simple to use and so like if all this software ends up being the same thing, if we can just ask a question and get an answer, why do we care about documenting the data at all? Like I'm not going to ever read that. And even if I did, I'll just ask it to generate the documentation when I need it. And so it's like, I don't know, there is something that feels like we're designing that for a world that no longer existed. And I get it. Sure. It's a transition. It's not to say the people who are building that is building something wrong, but it feels like that's a, that's a transition into something that is totally new. Yeah.

That also speaks to things like commenting all your SQL code or schema, writing long paragraph definitions of what the schema means and things like that, which often are needed for compliance reasons or for government regulations, but don't actually have any utility. And just to your point, could just as well be Generated on the fly. So in that spirit and maybe the close us out a little bit. You know, I'm curious from your vantage point, having spent a long time thinking about data and analytics and how people consume and use this, if you cast your eye forward five, 10 years, which admittedly is a long distance in the future, how you, what are some predictions you make for the way the world's going to look and feel very different for how people interact and work with data?

I mean I do think that the, the chat style model, whether or not it's actually chat, like I don't know that it'll be chat bots. I think that, you know, we've, we've again, that's the easy interface into this stuff and, and Chat GPT released a chat bot that became very popular. So everybody's like, let's go chatbot. But I do think there will be much more like chatbot like things that become the traditional or like the, the expected way to do this where. And, and part of that is like there's a lot of reasons why that doesn't exactly work, right. There's a lot of things where you can say well, it's not going to be quite accurate enough. How we answer complicated questions, all those kinds of things. My, my view of that is kind of like, I think it, it pretty quickly, if we get that good enough then people say like the speed with which they can ask questions, the depth with that which they can potentially ask them is like, well, exceeds what they can do with data teams alongside them and stuff like that. And even if we're not getting as good of an answers, even if it's not good as like doing a bunch of in depth research, it's good enough and fast enough that we'll start to say like this is now what we want to do. So for instance, if I want to like research a subject, Wikipedia is not entirely right. Wikipedia is not as like in depth in a lot of cases. If I wanted to go like, you know, actually do real research on the thing, but it's so fast, it's good enough that like you could replace. I could basically just exclusively rely on Wikipedia. And I feel like that would be a place that's good enough for me to get most of the answers I need. And I can see the same thing basically happening with, with how we interact with data, which is yes, we recognize this isn't always exactly right. We recognize that there are problems with using it sometimes, but it is so much faster than the alternative that, that we come to accept that that's like, that's as good as we're going to get and we'd rather have that than, you know, the very curated personalized answers that require a bunch of in depth work. It's just not worth the cost.

That's an interesting point. I'll push back slightly and maybe tweak your answer or see what your reaction is. And the example I'll give is writing a poem. So obviously one of the early use cases of ChatGPT is you can have it write you a poem. And it is absolutely the case that in very, very quick, very quick to your point about speed, you can write poems very quickly with this GPT interface. But generally speaking they're terrible. I mean they're not awful, but they're not great. But they're really fast. And in some ways I think what that means is that there's a premium placed on the curated poem. The poet who truly writes something that moves you versus the drivel you're getting out of GPTs. And in the same way with analytics, I appreciate I may be stretching the analogy here, but like the, the quick answers that you get through the, the interface to your point are much faster but that frees the time for the analysts to handcraft something truly moving as it relates to the data is that I'm curious how you react so well.

Okay, I guess I'd have, I would have two thoughts on that. One is that the, that I think that one of the things these things will come to be able to do pretty well is all of the demos of them are, are like, give me revenue by country by month and spits out a thing. And then, you know, you'll see like, oh, revenue is up in the UK and it's down in India.

What's going on?

And you may ask like, explain this to me and it'll give you like a, you know, we broke it apart by products cue. Here it is. You're like, okay, that's sort of helpful. Fine, explain that to me. And it'll, you know, kind of keep doing the same thing. I think they will get pretty good at that. Sort of like how deep can you, how far on the string can you pull where you get the basic dashboard? You're like, oh, this looks like a thing. I, I, I have a hypothesis. And I think the thing, the reason revenue was down was because there was a big holiday in India this month. Can you tell me if that's true or not? You're like, oh, here it is. And one of the things they actually very good at better than actually analysts, I think is they're not as good at the SQL writing stuff. They're not great at. They are very good at being creative. No, to your point, their poetry is bad. But if you say like come up with 10 reasons why you think the revenue is down in India and it's up in the uk, they actually can come up with pretty good ideas for that and they'll come up with ones that are often things I think that analysts won't. So I think there will be a way to actually like interrogate them in that sort of way to ask these questions such that that type of analysis I think probably will become much faster. To your point, no, there is a. Should we build a factory in Japan? That's a much harder question that probably does require like you do want some person who's actually thinking about it. I do think there will. You will keep the sort of poet, as it were, to help you with those sorts of things. Though I don't know if they are good at answering these questions. The poet themselves may want to use the tools to help them get there. And I don't actually know exactly what happens there, but I think there'll be more pressure on like analysts than, than perhaps we like to imagine. Though I don't think it will be because they are like magically writing SQL queries. I think it will be more because they are better at like kind of reasoning through problems than we want to give them credit for.

Yeah, fair point. And yeah, it'll be. I think the idea of treating analysts as poets, it certainly would make them happy. So if nothing else, that's. That's something to take from that. Oh look Ben, it's been a pleasure to have you and appreciate the thoughts and insights sharing what you're doing at Mode and all the thoughts on generative models and what's going to happen in the future. So thanks so much for the time.

Yeah, for sure. Thanks for having me.

This one Datamasters is brought to you by Tamer, the leader in Data products. Visit tamer.com to learn how Tamer helps data teams quickly improve the quality and accuracy of their customer and company data. Be sure to click subscribe so you don't miss any future episodes. On behalf of the team here at Tamer, thanks for listening.