Benn Stancil, founder of Mode, on how data science can help us make better decisions

Hi there and welcome to Scale by Intercom. I'm Lean Geraghty. Scale is our dedicated content resource on the Inside Intercom blog, where you can find a wealth of materials, including podcasts, of course, that explore how businesses are driving growth through customer relationships. This week, our guest is Ben Stancil, Chief Analytics Officer and founder of Mode, which is an analytics platform designed to help data analysts and and data scientists analyze, visualize, and share data. Prior to founding Mode, Ben served in senior analytics positions at Microsoft and Yammer, and worked as a researcher for the International Economics Program at the Carnegie Endowment for International Peace. On this episode, Ben talks about how data can be used to drive growth for startups by facilitating better decision making, as well as discussing what the modern data stack looks like right now. And he asks, are some airplanes flying faster than others? That will make sense later. Okay, let's head over to the studio to chat with Ben Stancil. Ben, thank you so much for joining us today.

Great to be here.

So, first of all, could you tell us a little bit about your background, you know, what you do and how you got to this point?

Sure, yeah. So I basically started my career in a totally different world. I started it in the policy world as an economics researcher at a think tank and then spent a couple years there. Really liked the work and liked the idea of basically trying to solve problems with data. My job was essentially to look at what was happening in the world economy, which this was like 2010 at the time, and so everything was kind of falling apart. Look at the problems and then look at data about it and try to come up with recommendations about what policymaker should do. It was really interesting kind of conceptually, but if you are making recommendations about what the Fed should do, as some, like, junior person at a think tank, nobody's really paying attention to you.

Yeah.

And so I like the idea of doing that kind of work, but wanted to do it in a way where it was more directly sort of related to the problems people were trying to solve. We could actually see if your ideas or recommendations worked out, people were listening and things like that. And so that's how I ended up actually moving from. From that job into an analytics job at a tech company in San Francisco. And so that was my first job in tech. Worked there for a couple years as an analyst or data scientist or whatever you want to call it. But the type of person whose job it is to work with marketers or product managers or operations folks to help them make decisions about which products to ship or which audiences to target or if the business is performing well in certain areas or not well in others. And so it was a lot of that kind of work. Again, it was similar to what I was doing in dc, but just applied to a very different domain. And then from there met some folks, started realizing sort of the needs of folks like me and what kind of tools we wanted, what kind of tools weren't there yet, and ended up creating Mode kind of based on that vision.

And so, like, was it challenging to get to this point with Mode kind of in the, in the startup journey?

Yeah, I mean, for sure, like every, every startup is, is going to be a challenge, and Mode is no different than that. You know, Mode has had plenty of its ups and downs and things like that. I think, I think on, on one hand, it's been very challenging. Every day you have sort of different problems you've got to work on. It's stuff that you've never really anticipated before. As I'm sure you're well aware. The, the journey going from a company of, of three people working out of someone's living room into something that's hundreds of people is one where you constantly are encountering new things, where the problems you have on month one are different than problems you have on month two. And so every day you're kind of having to learn some, some new thing that you've never thought of having to solve before. It's not, I'm going to get really good at this particular thing. It's like just as you get good at it, you sort of fall into the next one. So in that sense, it's, it's. Yeah, it's been very challenging. I think on the other sense, though, you know, we've had a great team. There's great people who supported the company, whether or not they're the employees, whether or not they're people who are early customers, whether or not they're just sort of friends and family and the types of folks who sort of put up with you as you're going along with it. And so it's been hard work, but it has been sort of a very good experience in that way of having the support of so many folks to be able to do it. I think folks in Silicon Valley are particularly privileged in that regard to have an entire ecosystem kind of dedicated to helping them and their companies succeed. Whereas if you were to do this in other places, I think it can be much harder than it is in Silicon Valley, where so much is built around trying to help people build companies and be successful. In doing so.

Yeah, absolutely. So I suppose, like data science is what it's all about for businesses that are looking to improve their decision making by using the information that they're already collecting in their apps and other systems. And this is where your company Mode comes in. Can you tell us a bit about the platform that you've built and how it helps data scientists?

For sure. So companies use data in a lot of different ways. The kind of easy way you think about it is thinking about what you would see in sort of the caricatures on movies and stuff like that is like rooms full of dashboards and charts where people are making decisions based on stuff. And like that obviously doesn't really happen. People do have dashboards and we're all kind of checking how, how companies are performing and that kind of stuff. But a lot of the actual day to day work of using data effectively comes from someone who is a data expert sitting with someone who is a business expert trying to solve a problem together, where the data person is working with that business person to answer the questions they have to help them make some decisions. So, you know, imagine you are, you are a product manager wanting to decide which product to build. You may want to understand, okay, well, how do people use the current features that you're thinking about changing? Do different types of people use it in different ways? Are there things that are seeming like they're trying to do but struggling like they can they can they accomplish the goals that they have? All of those things require these like very particular questions. And it's not a process that you would answer by looking at a dashboard. That product manager is not going to look at a screen and be like, aha, this is exactly what we need. It's this kind of long, iterative process of understanding sort of more and more about what their customers want to and then coming up with a decision and saying, hey, I think we should build this. Let's do some analysis to figure out if we think that's the right feature to build. And then you may find out, well, it kind of is, but something doesn't quite work. And so mode is really about enabling people to do that. It's about enabling that analyst to do that sort of work so that they can very quickly and easily help answer questions for other folks. And then how do they distribute that and make sure it's collaborative with those people as well. Because an analyst can't just go into a hole and answer these questions. They have to work alongside the product manager to do it as well. And so that's what we really want to enable. And then there's a lot of other things that happen around that. Like once you have that. Those kind of answers, can you turn them into something that are reusable? Can you make them so they're easy to return to and auditable and all that kind of stuff? But at the core of it, it's about helping people who need to understand something about their business answer questions by enabling them to work more fluidly with the analysts that are often the ones driving those answers.

So just I suppose to set the data scene from your point of view, like what will be a data story like, or example that had kind of like a happy outcome and one that didn't so much just to kind of. For people like me who's kind of like dipping their toe into the pool of data just for an example.

Yeah, I mean, so like a couple happy outcomes. I think there was a company, so this was a company that they were basically serving videos around to a bunch of customers. So their product is kind of a video platform. And they were trying to figure out how to make it better for people around the world. It was a global product. And one of the things that they realized was there were some customers that some countries rather, that tended to perform very well and some countries that didn't. And they weren't exactly sure why. They were like, oh, great, we're doing great in this country and doing great in this country, but not doing so great in these others. And one of the things after doing a bunch of analysis and kind of digging into it, they realized was the problem was videos basically were too slow in certain countries because of where their data centers were located or where their sort of, I guess probably AWS environments were located. But they basically realized that the problem wasn't, you know, they thought maybe it's something cultural, maybe it's something about like internationalization. We've done the translations for these countries. Maybe we've done something wrong there. Maybe it was something about the product just didn't resonate with particular audiences or was adopted by different types of people with different use cases in different countries. So they had a bunch of different things they could have tried to solve. Where it's like, maybe we have to invest a whole bunch of internationalization, maybe we have to invest in different features if we want to sell to these types of audiences because they think about the problems differently. Again, it was a video platform, so maybe they have to invest different content. But it ended up actually being something much simpler. It ended up basically just Being the app was too slow in these countries that people got frustrated because their videos would buffer too much and it just wasn't a good experience.

Right.

And so like they could solve that by saying, hey, let's put our product in more data centers in AWS or again, whatever, whatever sort of hosting product they were using, which isn't a, like, that's not a trivial solution, but it's not a hard solution comparing to having to figure out how to create entirely new content for different international audiences. So it was something that like opened up these new markets for this product without them having to go through a lot of the other kind of experimentation that they were originally planning when they realized that they were successful in some countries and, and not in numbers.

Absolutely. Yeah. That's a great example.

Yeah. In terms of the, the, the like negative data stories, there's a couple examples you could point to on that. There are certainly cases where people will, will try to make data driven decisions and end up making something that doesn't work out. You know, I think part of that is, is the nature of, of what data is, is it's kind of telling you something more or less probabilistically. Like if I tell you that should I bet on me rolling a die and me getting between one or five or a six? I, I could tell you, yeah, absolutely, the right thing you should do is you should bet on a 1 through 5. Like your odds are much higher for that. And that's the right sort of data driven analysis. But sometimes you may lose and if you're building a product or making a decision for a business that you can only make once, you can't go back and say actually let's roll it again and keep rolling until you get a one through five. Like you may just say, we bet on a one through five, we rolled a six and we're just gonna, you know, that's how it goes. So there's a lot of examples of that sort of thing where data's not perfect. You know, it's not going to tell you the future. It can give you some, some senses of what might happen. But there's a lot of stories about people making decisions probably doing the analysis really well, making what is a sound decision prior to it being made and then the result just doesn't pan out. I think that's the, you know, one of the things we talk to a lot of folks about is, is being okay with that. That's part of the game with, with trying to be more sort of data oriented as a product And a business is, you're not always going to get it exactly right. And you just can't kind of lose faith in what data is by expecting it to always tell you exactly what the future will be.

Yeah. And I suppose off the back of that, like, how important is it to consider the journey that that data follows to like to reach the dashboard at the end?

Yeah, I mean, so that there's definitely a kind of garbage in, garbage out type of process to all this. And I think that's pretty well understood. You know, I think that most people would understand, hey, data quality matters. You know, say we're trying to make decisions about our sales pipeline and how well, you know, different customers are moving through a sales pipeline and which stages of the sales funnel perform well and which ones don't. And, you know, you may come to the conclusion that, oh, in the, in the sort of the security review for our product, when we talk to folks on it and security about whether or not our product meets their standards, deals always get hung up on that. So we need to focus a lot more on that. If that data is based on. On sort of our conclusion is based on data that's manually entered by a sales team, it may not be that that's actually true. It may just be that, like, that's the part of the process for the sales team is, is sloppier about entering that data in Salesforce. And so therefore, you know, that conclusion actually isn't a reflection of reality. And I, I think people have a reasonable understanding of like, you know, you got to sort of do all the work upfront to make sure your data is actually accurate before you can draw any real conclusions about it. The part of that I think that's a little more interesting is there's another way in which I think there's kind of a similar dynamic around this kind of garbage in, garbage out, where you can do a bunch of different analysis and say you look at, look at some problem from 10 different perspectives. The way you look at that will matter, that there will be some perspective, that it appears a particular way, and that analysis by itself may be sound, but unless you tell people, hey, we tried 10 things and nine of them suggested one thing, but this 10th one suggested something else, then the 10th thing that suggested the thing that's sort of the outlier could appear by itself to be. To be very positive. You hear a lot about this in sort of like the academic p hacking type of studies where people are basically writing academic papers and it's a question of like, are they kind of looking for results and the answer is like, of course they are. Like, academics are paid to do that. They want to find something interesting.

Yeah.

And so it's not necessarily that they're like fudging the numbers or they're using bad data. It's just that when you go looking for something interesting, you're much more inclined to find it, even if that interesting thing isn't, isn't necessarily real. And so I think analysts can suffer from the same tendency where our job is to find something interesting. Like, we want to be the one that, that stands up at the big meeting and says, like, check out this chart that reveals this really dramatic thing. And so if you're always looking for those things, and again, nine times out of ten, you don't find it, the tenth time that you do, it's important to say, hey, we tried a bunch of other things first. And like, that helps sort of understand whether or not this thing you're thinking you're finding is real or not.

Yeah, 100%. So for startups, I suppose out there, you, how can data be used to drive growth?

A bunch of ways. So, you know, a lot of people, you can, I mean, most people use it, I think, like growth hacking and stuff was, was, you know, I guess popular a decade ago, which sort of people pejoratively referred to as essentially just like a new way to call marketing. But you can use it very much that kind of way. So you can use it to better understand your customers, to know who to talk to. A lot of what growth is is just like finding the right people and share, giving them the right message at the right time, at least from kind of the top of the marketing funnel side. And so data can be really important in that, you know, how can you understand from who's coming in your funnel? What do they say? How far do they get? Like, who are those people and how do you reach more of them that look like that? I think the kind of more important levers though, are often around understanding, like, what it is that your customers are trying to do. That people will often build products and expect it to be used in a particular way, expect people to like it for one reason or another. And people don't always like it for those reasons. Like, there's a lot of features that we've built at Mode, or we've heard from our customers that have built where they're like, oh yeah, this is going to be a great thing for X. And it turns out that that's not really why people like it, but they might like it for Y. And if you, unless you're looking at the data to understand kind of the behaviors of what people are doing and trying to understand what motivates them to do those things, you'll often think like, oh great, we launched a feature that was really good for this and that's why people are using it. So we're going to really lean into that. But it may be that you're actually kind of playing against the way people are trying to use the product and you should instead be saying like, hey, they're using it for why. Let's really build ways to enable them to do Y thing on it. So like as an example of this, it was a company that was aware of, that was like a, it was, it was kind of a chat product essentially for work folks. It was collaborative, you know, kind of a slack type of product that was like sort of mobile focused. And they originally thought it'll be a great way for frontline workers to communicate. It'll be a great way for people who don't have email addresses, addresses to communicate. So if you're, say you're a cashier at 7:11, you may not have a 7:11 email address. But we need a way to be able to have, you know, sort of corporate talk to those folks. This was an app for that. They got some adoption, but they thought that was why it was, was these people who didn't have email addresses. But after looking at a bunch of the data, they realized it was actually people who, who just had to be in and out of the office a bunch. The most useful thing wasn't that they didn't have an email address. It was they were away from their computer a lot. You know, they're essentially using it like a, like a WhatsApp type of replacement for corporate chat. And so, you know, had they thought it was the one thing where it was about, it was about people without an email address, they might have built a bunch of features where you sign up with your phone number where you do a bunch of things that make it possible to make this a thing where you assume you don't have a desktop computer. But what people actually wanted was this like experience where they could use a computer sometimes and then walk away from it and then have a really great kind of mobile experience when they're on the road or they're making a delivery or whatever it is as they were doing. And so, you know that, that creates a very different path for that product and company. But they would never actually understand that Unless they were looking at the data to say like, who's the people who are actually using it? What are they actually trying to do with it? It's about kind of finding that that actual product market fit rather than the one that you assume you have.

Want to be at the forefront of customer service? Join us on May 21st for our Built4U virtual event. You'll join leaders from Lovable Consensys and more and discover how AI is transforming how support is measured. You'll also be the first to see Intercom's latest AI innovation. Register by visiting Intercom's LinkedIn page. So what does like the modern data stack look like right now?

Yes, the modern data stack is the kind of like catch all term now for the new set of data tools that are being developed really on the backs of cloud data products. Moving to the cloud. The kind of core of this is the data warehouse. So back before basically 2010, any company that wanted a data warehouse, which is where you store all of your data, would typically have to go buy something where they would buy a physical machine or buy physical software like on a, on a CD that they would then run on a machine that they own. So it would be, you know, we have a server room in the back that is our database and we're running some Oracle database on it and all of that. Basically with Redshift, which was one of the first cloud data data warehouses, people started moving all that to the cloud where instead of me having to actually buy a machine or buy software that I own, I can just go to AWS like say, you know, spin up a Redshift database for me and I can do that from my browser in 15 minutes and I don't have to actually have any hardware to do it. And so a bunch of tools have been built on that idea of saying, hey, what if we did all of our data work in the cloud the way that, that so much other many other products are moving now and didn't have to have all this software that we ran ourselves. So the modern data stack is really kind of around that idea of what does it look like now for data to be moving to the cloud. And so there's a bunch of ways you can define it, but generally it has been building these very sort of horizontal products that there is a product snail that will just ingest data from third party apps. So say that you have data in Salesforce or in Zendesk or in Marketo or in Stripe products that will just ingest that data into your warehouse. You've got products that will like transform it and model it in your warehouse. So you say you got a bunch of messy data that you want to turn into clean data, products that will manage that. The warehouse itself will do storage. There's analytics tools like MO that sit on top of it for dashboards, for analysis, for being able to share and distribute that work. And then there's a bunch of other tools that kind of get built to support those. So now that you have five or six tools that are running your data tooling, you want to be able to monitor all of them and be able to see like, is everything working right? Like, are the pipelines from point A to point B all up and running and performing as I expect? If I want to make the change to one, how do I make a change to this one and then sort of orchestrate that change to the system? So it's becoming just as much more complex ecosystem. But it's all kind of built on this core flow of some way to ingest data in a warehouse, some way to transform it in the warehouse, some way to kind of build a data asset on top of the data in the warehouse, and then some way to ship it off to whoever it is that actually needs to see it.

Is it a challenge that, you know, like, I suppose the fact that it can be so hard to get everyone to agree on, on the numbers when you have different dashboards and tools telling you different things, like, is that a challenge?

Yeah. So this is, this is one of the kind of like paradoxes. A little bit of, of the current state of the modern data stack is we've spent now, you know, close to 10 years building these products. And they are revolutionary products in a lot of senses. They do things dramatically better and dramatically faster than they did 10 years ago by comparison. So about 10 years ago, the top of the line databases you could buy, you'd have to spend say a million dollars a year to run it. You'd have to pay for the machines that run it. You'd usually have to have one or two people whose full time job was to manage it. And today you can get warehouses that are faster than that one that will cost you $20,000 a year that you don't have to have anybody manage that are fully managed for you that, you know, you can just say again, I can go to aws, push a button and have it, and pay, you know, tens of thousands of dollars for something that used to cost me all in probably a couple million dollars a year. And it's a better product. And you could. You can make that same claim. Like that kind of across the entire stack, like, analytics tools have improved in that kind of way. The data ingestion tools and pipeline tools and improved in that kind of way. So we've had these dramatic improvements in, like, the quality of the technology. But the core problems that we're trying to solve are often, like, sort of stubbornly persistent. That one of those core problems we had 10 years ago was two people walking into a room and being like, my dashboard says this and somebody else saying, my dashboard says this. And they spend the entire meeting rather than trying to figure out what to do. Like, arguing about whose number is right. And we still do that. Like, there still is a lot of that. I was talking, or was heard a talk from the CEO of Databricks, which is one of these really modern warehouses that's now a very big company that is sort of driving a lot of this change. And he was saying that one of the most common complaints he hears from customers is people spend all their time bickering over numbers and just like, which one is right. And so I think that we're getting closer to that. There's part of solving that problem will be continuing to build tools that can kind of talk to each other and work better together, and systems that allow us to sort of define things once, so that if we look at a dashboard, we know it's pulling from the same. The same place. But part of it also is, I think, just going to be organizations figuring out how to work with data. Like, data is still a relatively new thing. You know, most companies have sort of started using it in a real way in the last 10, 15 years. We're still kind of figuring out how to make that work. Like, there's still a lot of conversations in the community about the different roles that we need and what they're for and who's responsible for what. And so, you know, like, engineering wasn't a practice that developed overnight. It was not a practice that developed overnight. Marketing and sales have been around for hundreds of years. Like, we're still in the early stages of figuring what this looks like for the kind of data profession. And I think that there'll be a combination of the tools that we build and just everybody starting to realize this is the way this works and this is the way this doesn't. Before we can really get past these what seem like foundational problems, but are often, often still very hard to solve.

Yeah, absolutely. And I think everyone from, you know, all kind of industries will have their Own stories, certainly with podcast metrics, I think, are probably a good example of the complications with data where, you know, like, a download usually doesn't equal the total number of listeners because an individual listener might have downloaded the same episode on multiple devices, or they might have downloaded it with the intention of listening to it, but never got round to it. And I know there's trying to introduce kind of like a standardized way of measuring these things, which is probably going to happen across the board, I guess, for a lot of industries.

Yeah. So if you think about, like, marketing metrics and, say, the basic web marketing metrics and how people run ads and stuff, we've started to standardize on some of that. Where, you know, if you go your Facebook ad dashboard or your Google Ad dashboard, those things are going to look pretty similar. They're going to tell you more or less the same story. Because there's been some standardization on how we actually talk about and figure out which ads are performing well versus not. And you see this with some other things. You see this like SaaS companies, for instance. SaaS companies now have kind of their standard kind of book of metrics that they all draw from. So there are a few places where we're starting to see this kind of coalesce. But, yeah, there, I think, will be a lot more of that over the coming years where it's like, okay, how do we think about podcasts? How do we think about particular types of products? How do we think about measuring the performance of a support team? How do we think about all of these different things that are the data that we now have, like, so much richer information about? But every company is still trying to figure out kind of individually, or every person, in some cases individually, of how they make sense of it. And so I think there will be some standardization around. Okay, this is probably the best practice for thinking about these sorts of problems. Companies will still obviously have some bespoke reporting that they need to do. Like, this podcast may be different than the way that another podcast wants to measure things because you may have different audiences you care about or. Or sort of different goals. So everybody will have their own sort of different tweaks on it. But I think there will be a much better sense of, okay, this is the way that we all kind of agree works, and we're more adapting from that best practice instead of everybody trying to do this from. From scratch, which is now where. Where we are. And a lot of these. A lot of companies, when they start their data practices, are often trying to build things from. From the ground up. And I think we, we have little ways to go before we get to the point where you can, you have kind of the scaffolding we can all build on top of. You know, web frameworks in some ways are example of that, where if you go to one of you want to build a web product or, or build software, there's pretty well defined sort of outlines that you can draw from, where you then sort of add your own logic to make your application exactly what you want it. You know, analytics is, doesn't quite have that. Everybody sort of starts from, from zero rather than having that, that kind of core framework that they can build on top of.

What would you say to startups daunted by, by data and you know, just kind of like staring at it all and kind of feeling a bit kind of anxious about it.

So I think, I think this can happen at startups. I think this can also happen at companies that are data mature and with individual analysts. And like, it's easy to stare at a blank page, basically, or stare at a overloaded Excel spreadsheet or a whole bunch of tables and think like, what in the world do I do? And that's easy to do if you're an experienced analyst just like starting to understand a problem. It's easy to do if you're a company that doesn't yet know what to do with data. It's easier to do if you're a junior analyst who just joined somewhere and isn't sure what to do. And I think the solution for that is all kind of the same, which is it's okay to start with stuff that's really simple. Like one of the things, I think that it's remarkable how much basic information people will find valuable. So I used to know a guy who would have a. Basically once a week his data team would have a meeting where they would essentially share the things that they learned over the week. And some of these things were stupidly simple. The company was a product that was built for businesses, so it was used Monday through Fridays. And they made a chart that was, this is how many people use it by day of week. And look, most people don't use it on weekends and a lot of people use it on weekdays, which is a thing that is, you know, you're not exactly uncovering some incredible insight there. You're not. Everybody kind of already knew that was how it worked. But seeing those numbers and exactly how much it dropped off on weekends and like there were some weekends where it didn't drop off very much. And some weekends where it dropped off a ton.

Yeah.

Generated a bunch of questions and, like, curiosity around what's driving that behavior. Why. Why is that weekend one where people seem to use it a lot, like, what happened there? And so that was the seed for a lot more of, like, all right, let's continue to learn. Let's continue to ask questions. Let's continue to dig. And so I think that that's the way that I encourage people to start, is just start with the things that are basic, that even if they're assumptions you're making, just be like, yeah, I want to see exactly what that is. I know people are going to not use it on the weekends, but by how much. Like, and as soon as you start to look at numbers and start to see that, you will see things that make you think and scratch your head and make you realize, like, there's so much more here that I don't understand that I am curious about. So a lot of it is just, like, allowing yourself to. To be taken by that curiosity and not being saying, like, I need to go uncover some amazing thing. I need to find that, like, needle in the haystack that will change the trajectory of the company on day one. Like, you're not going to find that right away. The way you're going to find it is by just kind of poking around, seeing things that are interesting, and letting yourself explore those as interesting things when you find it.

That's great advice. And just before we wrap up, it strikes me like, you're clearly so passionate about data. I just wonder where that came from.

Part of it is you work in it for a long time, you just kind of get to know it. I think part of it, though, is it's the way that I think, you know, I think it's. It's fun to figure stuff out like this. I think that this is maybe giving away the sort of nerdy type of person I am on this stuff. I was talking to someone about. About flying from New York to San Francisco a couple days ago. It's a flight that I've made a good bit. They have made it a good bit, too. They were saying that when they were flying back, I think it was actually San Francisco, New York, but they were saying they were flying on a Delta flight, and it felt like it was way faster than when they were flying on, like, United flight. And it was like, why is Delta faster on this? And so it made me think, like, do different airlines actually fly fat? Like, are there some airlines that are just, like, able to Fly faster. They have different routes. Like, doesn't seem like that would be true, but does that actually hold up? The Department of Transportation releases statistics on or like, they basically release raw data on every flight in the US like, where it started, where it ended, where it took, what time it took off, when it landed, all that stuff. And so I just started playing around with it, trying to figure this out, and, like, looked at different routes and was like, okay, are there. Are there changes in sort of the speed of different airlines? Do those times. Are planes flying faster at different times of day, different times a year? It was, you know, like, as you get into it, it just became interesting to see, like, I don't know any of this stuff. I don't know how fast planes fly or why they fly in different speeds, you know, on the same routes or whatever.

Yeah.

But it was interesting, and it ended up being that there actually were some airlines that were consistently a couple minutes faster. I don't know why that would be. It was never by much, but it was basically like 90 seconds of difference fairly consistently between a couple airlines. So I don't know, maybe they just, like, have different guidelines or something.

Right.

But I don't know. Like, that sort of thing, I think, is. Is what makes me interested in it, is I am. I'm just naturally prone to want to kind of play around with that and understand it. And I don't. I don't know, really have an explanation as to why that is, other than I find it fun. And. And so, you know, I think that really drew me to. To the job in the first place. And then once you kind of get into it, you start to see all these other things that you could be doing and other things that are. That are. That are fascinating and fun.

That's great. So what's next? Like, have you any particular plans or projects for 2022, where we've just started.

Continuing to do the mode things? You know, I think there's a lot of stuff on that front that we're excited about, a lot of new. New things we're building and kind of the direction of the space is one that we're very excited about. So a lot on that. I think, you know, for me more personally, last year I started basically writing a lot more on a substack because it's 2021 and now 2022, and that's what we do. And that's been fun. It's been good to get some of the thoughts out about. About these ideas and just have conversations with the people in the community and kind of see where things go. Again, part of it's just like interest in the space. And so certainly we're planning on doing more of that and be much more involved in that. I don't, I don't know exactly where that goes. And I think part of this is, is again, letting myself kind of be curious about it, do the things that I enjoy and, and if I find stuff that's fun and that people, other people seem to enjoy, then giving myself kind of the permission to continue to do it.

Well, I was going to ask where our listeners can go to keep up with you and your work. Definitely the substack, I think it's Ben with2ns.substack.com is that right?

That's correct. So mainly the two places would be there and Twitter, which I am not like the most active Twitter person in the world. So the substack is a better place for some of the more interesting things. But my Twitter handle is Ben Stancil. Ben with two M's and then Dancel. And there's links to other, you know, if you like LinkedIn and whatever. You know, if you want to connect professionally, there's obviously things like that. But most of the things are substack. Really.

Yeah, yeah. No, I've been reading lots of your, your posts and they're, they're, they're great. So I would definitely recommend everyone go and subscribe to Ben Substack. Well, thank you so much for chatting with with us, Ben.

For sure. Thanks again for having me. This is fun.

I hope you enjoyed my conversation with Ben Stancil. If you did, I would love you to give the show a review. It helps like minded people discover the show. I'll be back next week with another great episode. See you then.