Drill to Detail - Drill to Detail Ep.60 'A Deeper Look Into Looker' With Special Guest Lloyd Tabb

Episode Date: March 5, 2019

The Drill to Detail Podcast returns for a new series with our host, Mark Rittman, joined by Lloyd Tabb, Founder CTO and Chairman of Looker to talk about the foundational story of Looker and LookML, query latency and semantic models, analytic engines and code IDEs, analytics developer workflows and the rise of cloud elastically-scalable databases, packaged applications and embedded analytics and why learning (and loving) are the long-term keys to analytics and business success.Looker JOIN: The Tour 2019“7 Reasons Looker Built a New Language for Data”“How do you decide what to model in dbt vs LookML?” - Tristan Handy“Looker co-founder finds freedom and inspiration on his bike rides” - BizJournals.comLooker Packaged Applications“A simple explanation of Symmetric Aggregates or: Why On Earth Does My SQL Look Like That?” - Daniel MintzDrill to Detail Ep.48 'Mondrian OLAP, Apache Calcite and Database Dis-Aggregation' With Special Guest Julian Hyde

Welcome back to a new series of Drill to Detail, the podcast series about the people and products driving innovation in the data and analytics industry. I'm your host Mark Rittman and today I'm joined by a very special guest, someone who I've been looking to have come on the show for some time now, none other than Lloyd Tabb, founder, CEO, and chairman of Looker. So welcome to Drill to Detail, Lloyd, and thanks for joining us to talk about your history and how Looker the product and Looker the company came together. Thanks, Mark. I'm really excited to be here. And so, Lloyd, for anybody who doesn't know you,

maybe just explain the role you have at Looker and just introduce yourself really. You know, I was the co-founder of Looker with Ben Porterfield. I've been a serial founding CTO for a number of years. And basically, Ben and I started Looker and I've been working on it since then. So you describe yourself as a serial entrepreneur. And before that, you worked at companies such as Netscape and Borland in development roles. So tell us a bit about the work you did there and how it led to the product and business that you built over time with Looker. Yeah, sure.

You know, I've always been interested in programming languages. My whole career has been around programming languages. In 87, I wrote a native code DBase compiler, and I worked in the languages group at Borland and databases group at Borland, building, let's see, building IDAPI, which was their common database interface, and scripting languages, and I was architect on DBase for Windows.

And so I had been building languages for a number of years. And then I saw the internet happened and built one of the first application servers for the web, which was gluing a web server, a database, and a programming language together. And that got acquired by Netscape when Netscape was about 80 people. And so I've been doing web and database and languages for my whole career. After Netscape was about 80 people. And so I've been doing web and database and languages for my whole career. After Netscape, I was CTO of a bunch of different companies. And essentially, every time I was at the company, what was important was getting everybody to understand

what was going on in data. So I ended up building a lot of data tools there too. So that's kind of how I got to Looker in the first place. So language is something you've always been interested in. Yeah, you know, Noam Chomsky talks about language as thought. The idea is that you can't really have a thought if you don't have words for it. You can have feelings, but they become thoughts when you actually can put words to them. And different languages are good at expressing different types of thoughts. So, you know, French is the language of love

and German is often thought of as the language of precision. You know, there's this saying that Eskimos have, you know, 50 words for snow, which is actually accurate. And so programming languages are very similar. Different languages are good at different things. So Go is a great distributed processing language and javascript is a good scripting language and um um and sql is is the data languages that we're dealing with like sql are are back in the 80s and 70s when they were developed they really haven't moved forward and and so so looker was was my take on

on on bringing bringing that forward so um when you got to the point where uh you formed looker and had the original ideas behind that what was the what was the kind of business problem you're looking to solve there um that kind of i suppose was the inspiration for the product you know um on uh i've been an entrepreneur for a really long time and and um uh even in college and high school and but and normally what you want to do is make sure that you're understand what's happening in the business is super important. So if you're a restaurant, you pay attention to the quality of the food and the smells and like, and if you're retail, you kind of watch the floor traffic and what are people

picking up and touching. But in the internet based businesses, you can't see anything. You can't smell anything. You can't touch anything. You have no sense about what's going on except for data, right? So like the only way that you can really understand what's occurring is if you look at the data to see what's happening. And unfortunately, in most companies, a lot of times there's a data group who's responsible for seeing, for doing all the sensing for everybody else. And so I was doing a bunch of internet companies

as a CTO and my job would be, okay, how do I get it so that the broad audience of the company can see what's actually happening so that they can understand what's going on? So in 2003, I was the founder-ish of a company called LiveOps, which was the first crowdsource company. We had 30,000 home-based,

ultimately 30,000 home-based telephone operators. And all of our business happened on phone calls. And there are lots of attributes about the phone call, like what the agent that took the call, what it was for. We were answering phones to take orders, basically. And we wanted to know, was the agent a good salesperson? Were they upselling well? So all of this information was happening around calls, and the company couldn't see it. People were typing SQL queries to try to understand what was happening in calls, and they were saving SQL queries. And I was like, okay, there's a better way to do this.

They need to be able to see what's going on. So I built a special purpose tool around call data that let people kind of figure out what was happening, whether agents look at calls bucketed and then drill in and listen into the phone calls. manage 30,000 operators at scale without actually being able to see or know them or know anything about them, except that being able to see the data and listening to calls. And then I did another company called Luminate, where ad tech was the same problem, what was happening with the ads that we were running, and another staffing company where we're trying to figure out what was happening with staffing. And every time I would build these tools, and I realized, well, there's a there's a, there's a thing here, a general purpose thing here to let people understand what's going on in data. And so that was the premise for founding Looker. So what I find to find interesting

about Looker, and the success you've had is certainly back in 2003, there was no shortage of analytic databases, and BI tools out there that would have had a business model layer. And you could argue, I guess that this is a kind of sole problem, really, in some respects. So why do you not see the likes of Oracle Business Objects, Cognos, and so on, even Click and Tableau, being used by startups and SaaS businesses today? What was it that was out of step with those products or missing from them that means that your product came along

and met a new need? You know, sensory input and latency are two really importantly related concepts. So latency is how long it takes for you to get the signal. So like the latency, if the Mars rover is sending something back, it takes, what, 17 minutes for the signal to get here. So it becomes very difficult to drive the rover on Mars because every time you turn the wheel,

you have to wait 17 minutes for the wheel to get here. So it becomes very difficult to drive the rover on Mars because every time you turn the wheel, you have to wait 17 minutes for the wheel to actually turn, right? So you can't really drive with a car with 17 minute latency. You need basically sub-second latency or to be able to operate a vehicle, right? Businesses are pretty similar. Most reporting tools are built about what happened. They're focused on the past, what happened yesterday. So the latency can be a day. And that's okay in a brick and mortar business. But that's not okay when you're trying to figure out what's going on right now and do something about it right now. What didn't ship today?

The latency on that report needs to be minutes or seconds, not hours or days. Because you need to be able to react to it to serve your customers. So the old tools are really about what happened. And what I needed to build was about what's happening now, so that you can actually, so that you can, so that the latency is as close to zero as possible. So when you talk about latency, are you talking about how fresh the data is? Or are you talking about the time it takes between having an idea and a problem to be solved, and actually getting things on screen? No, it's how fresh the data is or are you talking about the time it takes between having an idea and a problem to be solved and actually getting things on screen no it's how fresh the data is like you need to be able to so looker originally operated on transactional databases we

you know our original customer base were like hotel tonight thread up um um you know and what they were doing was they had everybody in the company had email open and looker open so they could figure out what was going on in their business. Instead of having the engineering team build custom tools so that they could see what the remnant hotel rooms were at this particular moment, they could use Looker to do it. And so it was much cheaper to build those interfaces. And to this day, a lot of people actually run their businesses on Looker because you can connect to both the transactional database, which gives you up to the second, zero latency in the data, as well as your analytical stuff, which gives you what happened yesterday and that kind of thing. So access to both kinds of data is super important.

And so how much of a role did the disruption in the market that these elastic databases, such as Google BigQuery and so on on redshift um arriving in the market you know contribute to the opportunity that look i've got to get its growth yeah you know i mean transactional databases like postgresors or or or my sequel will cap out at about 10 million rows in a query before it gets to be too painful so you're constantly trying to trim down and it really depends of course on the number of joins. But a scan of 10 million rows in a query is about all you'd really want to do in a transactional database. But if you're doing less than 10 million transactions in a day or in the interest period, it actually works just fine. To really understand trends or what's going on, you need to be able to look at a billion rows. And so, you know, the Redshifts and the BigQuerys

and the, you know, the snowflakes of the world are great at really dealing with large data sets, allowing SQL access to large data sets. And what they're really great at is relating lots of different data sources together in a way that gives you like 360 visibility on what's going on or what happened. So you can relate that to your transactional data

as well as build the digests about what happened to. So it's pretty amazing what you can build with all this stuff. So what did the first iteration of Looker look like? The minimum viable product that got traction with customers and proved that you solved a real business need. Was it the core SQL generation engine? Was LookML there, for example? What did the first iteration of the product look like?

It looked like the Explorer interface in Looker. So it was, it was the Explorer Looker, the Explorer interface with a couple of visualizations. And so what we did was LookML was the first thing that was built and the Explorer was the second thing that was built. And that was the MVP. Actually that, that and then and then persistent drive tables came right so so basically the mvp i think would be the the drive table system the persistent drive table so the ability to transform the data the ability to you know query through and explore and um yeah and and and and and then and some basic visualization was the MVP so let's talk about the data modeling language LookML to my mind probably the most I suppose distinctive or

kind of differentiating feature of Looker compared to other BI tools I've worked with you know it's quite a different you've taken quite a different approach to how to build out the metadata in your your system and the kind of the business model and so on there um and what kind of um what what was the story behind this and why did you go down the route of creating a new language and a layer of abstraction over sql and the underlying relational databases that you source data from yeah so sql sql is not reusable um sql is a lot like a lease i don't know if you know if you ever had a lick it's a lease and if you want to if if you want to lease another apartment where you copy the lease and you make

some changes to it and so it has this generational problem which is that you start with the first lease and by the 10th lease it doesn't look anything like the first lease and if you want to change some clause in the lease you have to go to all the all the leases and change the causes right the clauses there's no reusability in it it It's a copy, it's a copy metaphor. And, um, um, and it, so it, it, it lacks reusability and decomposition that we take for granted and all these other programming languages. So look, ML was designed to basically decompose SQL in a way that would be reusable. And so the, and so that anybody could query it could query it because all of the pieces of the query were decomposed in a way that it was reassemblable

by a regular business user, right? And so the composite forms of it are scalar computations, which are dimensions. These are things like first name plus last name. You don't want to look, you know, in the database it's stored as a first name and last name. But when you look at it, you want to see there just, you want to see Lloyd tab. So you want to see a concat with a space in it, right? So that allows you, that's a scalar or a dimensional

calculation. There's another kind of calculation, which is a measure, Looker calls a measure. And a measure is an aggregate calculation. It's when you take a couple of several rows in the database and combine them using a function like sum. And really the simple case would be, say, revenue. And revenue might be the sum of all of the order item prices and less the shipping costs. That might be your total revenue in a retail. And LookML allows you to define that in one place in the model. With just those two things, you can actually build up lots of... With just those two things and the ability to filter the data, you can look for total orders by person in the last month,

and you would grab the dimension of your person's name, the total revenue, and you'd filter on the order created date of the last month. And that would produce, Looker could then write a query from that. And it would be totally reusable. And if you change the revenue calculation, it would change it everywhere. So there's a governance layer that lets that work. Now, there are other parts of things that are in the model also. So the relationships between tables is also part of

the model. So like an orders table might have a user ID in it, and then the relation of the orders to the user table is also built into the model so that you don't have to constantly redeclare that relationship. And transformations are also in it. So suppose you wanted to do a customer lifetime value calculation, you could write that in LookML also as the user ID and the total order amount, reusing the same calculation of revenue to produce a new table that doesn't really exist in the database but is ephemeral and can be used everywhere else,

and that's the transformation we call a derived table. So at some point point did you consider adding some form of internal kind of analytic engine or um like multi-dimensional olap server into look at the product um if not you know how do you decide where to stop really you know where to i suppose just use the leverage the functionality of the database or or you know or build things into the actual kind of server as an analytic or compute engine? Okay, so the problem with analytic engines is that they're extraction-based, right?

And so if you extract the data, what happens? It's old, okay, right? And therefore, it's a lot less useful, right? So Looker has always operated on the premise that it needs to operate in very low latency situations against data. We can still do these other things, and we do a lot. We can build OLAP cubes in LookML using derived tables, but we also need to be able to relate data. So there's two things.

One is it can't be old, and the other thing is we need to relate everything. So if you pull it out of the database, and you need something else in the database, you have to pull that out too. But if you operate within the database, then all of the data is completely available. So it becomes a movement problem. If you don't move the data, it's all available to you. And so that's the hard problem we've been working it's it's an attitude but we've we worked it um it creates tremendous value but what about areas like um so aggregate management you know for example working with um you know big query or snowflake um it would be great if there

was a i suppose a transparent query rewrite engine um or some kind of a way that we could automatically map the detail level um queries an aggregate table, for example? Is that an area you think there'd be some value there for customers? Oh, sure. I don't know if you know, but I think Julian Hyde was on your show. He's one of the world's best people in that area, so I'll leave it up to the reader. Yeah, he came on the show at the start of last year,

one of the most popular episodes, actually. And I think certainly, I mean, presumably you think there's some kind of value in this and it's worth investing and bringing someone of Julian's caliber, really. Oh, sure. Oh, for sure. Listen, I mean, interactive query speed is super important, right? And so there's a trade-off between freshness and speed right if you if you pre-compute a bunch of stuff it comes back really fast if you want it to be up to the second then it can't be based on an aggregate so we need we we want to operate in

both worlds and we do it very well and we we we're we i i basically don't want to talk about future plans but i can tell you that we are very interested. So the way that Looker has, I suppose, reintroduced the idea of a semantic model to today's developers, you know, data engineers, data scientists, data analysts, was that a bit of a mission of yours? Was it something that you were quite keen to do, a central part of Looker's mission? Oh, absolutely. I mean, Looker, the whole concept of Looker is around the semantic model, right? I mean, that was the first thing we wrote was the programming language. There's a very big difference between historic semantic models and LookML. Historic semantic models mostly were around pre-computing aggregates.

They were built around the fact that databases were expensive and slow. And so the semantic model was an optimization layer for databases. they were built around the fact that databases were expensive and slow. And so the semantic model was an optimization layer for databases. It really didn't concern itself. It concerned itself with aggregates, but only in his effect as how the data was dimensionalized. And LookML is really a different animal. And what it focuses on is around the query as opposed to around reporting,

right? So the traditional semantic models were about around dimensional joining. And LookML is around queryability or the ability to ask questions and drill into the detail of what's behind it. So, you know, every Looker query, when you get a result set, every aggregate, if you click on it, will show you the objects that it's composed of. And that's all possible because of the relationships and the way the data is defined in the language. And so it's a reduction of complexity as opposed to a tool, a language, to be able to create reports. So most BI tools I've seen organize their semantic models, their metadata models,

around the concept of star schemas and dimensions and hierarchies and very kind of formal, dimensional kind of structures. And yet with Looker, you went down this idea, this route of using what you call an explore, which needs a lot more kind of freeform tell us about some of the thinking behind the explore and um and some of the terminology that you use yeah you know we

had a hard time naming what that was uh you know if in retrospect i would have liked to have named it a relation because what it is is is is a set of related objects, and it's the starting point from the relation. So orders is the starting relation, but you would join in orders and products and order items and even lead sources and things like that. But the concept of aggregation is pretty core to Looker. So you always pick with a dimension that you're going to aggregate the data on, and then what you want to compute, and what you compute is entirely dynamic.

And what's beautiful about Looker is that it doesn't, you can always compute accurate measures regardless of where you are in the relation. And that's actually been a really hard problem in SQL that Looker makes totally transparent to you. And a lot of times people will look at Looker and say, okay, show me the average user's age and the total revenue by state. And they'll expect it to be a weighted average user's age and the total revenue by state and they'll expect it to be a weighted

average user's age because a user might have ordered once or twice but in Looker it will calculate that correctly regardless of the join pattern. So another thing another aspect of Looker that's supposed to differentiate to that seems to really resonated with developers and engineers is the way that it adopts modern software development practices for when you come to develop the semantic model things like the fact you use git for the repository and just generally you know you tend to script things it tends to be in alignment with how engineers work with software today was that again was that deliberate or was that just a kind of bit of luck really uh no it, it was, you know, I learned this one the hard way. It's a pretty funny story. So I was,

so I was at Borland, and we were building visual programming tools, like, you know, Visual DBase for Windows, which was a visual programming environment. And there was Delphi and Visual, you know, Visual C++ and Borland and, and Microsoft had Visual Basic and Visual C++. And, and so the conventional wisdom in 95 was that if you're going to build a tool, it has to be a visual tool backed by some programming languages, right? Okay, so I started the company that was building this application server, and I, of course, needed to build a visual editor for it because all programming tools have visual editors, right?

This is 95, right? And so when we got acquired by Netscape, I couldn't find anybody to build a visual editor for me. So I ended up being architect on Navigator Gold, which was trying to build a visual interface to build web pages, right? To build so that I could build a visual interface so that I could build web applications, right?

Well, of course I was wrong. Nobody who builds web pages wants a visual builder, right? They don't want PageMaker or they don't want the visual tools. They want to code it. And so I thought that we needed a visual builder, but people really wanted the code. You know, in data, data still thinks people want visual builders, but what they really want is to be able to express higher levels, you know, more complicated abstractions, which you need code to do. So everybody thought we were crazy when we were starting Looker that we were going to do it as a language-based thing. But my experience said serious software people want serious software tools. And so we built the full IDE that was code-based.

We built the full IDE that was code-based. We built, you know, the workflows that, you know, there's a sandbox development environment that you get within Looker so that you can, but it's all code-based and it always has been. So you said earlier on that the purpose of LookML or one of the drivers behind it was reusability. And there are complementary products out there and open source projects that kind of work with Looker or complement Looker that take this kind of concept concept a bit further so for example you know dbt from the guys at fishtown analytics um that takes the idea of reusability that you're talking about but then extends it through things like templating and macros and so on to bring kind of i suppose quite a good degree

of modularity there and dependency graphs and so on into into kind of the data modeling around analytics um so you know what's your view on where looker ends um and pdts and so on and you know where does it end and where should uh maybe an external tool or external framework be used to do the kind of data modeling and so on that associated with a an analytics project um so eventually eventually we think we'd like you to stay entirely in LookML. There are edges that you can fall off of. But the transformation engine, the building transformations in LookML is amazing.

It's the, you know, when you think about the world before Looker, you had a data team which was responsible for grooming data and putting it in the database, right? So they would build a data team which was responsible for grooming data and putting it in the database. Right. Um, so they would, they would, they would build a data pipeline. It would land in the database in a way. Um, and, and, uh, and then you'd have an analyst that was pulling from the database into an extract and using it. And, um, the, the, the, the looker world is, Hey, just land the data in the database in any form that you can get it in and then then build a transform in LookML to get it into the form that you need to be able to make it accessible and understandable.

And so Looker's transformation engine, the derived table engine, allows you to do this in a very agile way. And you can also, you know, there's a subtle thing here, which is that, you know, you have a temporary table that you're using in a pipeline world. It's very difficult to test a new version of that. But Looker is fully automatic.

If you're in development mode and you make a change to a derived table, you get your own copy of it while, you know, without risking anything that's in production. And when you actually push your changes to production, that becomes the de facto standard. And everybody's reading from that. And so it's this flow that allows you to do experimentation, which is super important in software development, and then testing, and then deployment. It reuses what you built in development mode. Now, sometimes there are limits into how big of a transform you can do. So if it takes half a day to do the transform,

you probably want to pull it out of Looker and do it in something else. So that's the edges. It's basically how long it takes to do the transform. But you have it modeled correctly by the time you're ready to do the transform. So who do you find are the users of LookML within customer sites and organizations and so on? I mean, is it typically just developers or are you finding that analysts are adopting LookML as a way of doing things like kind of retention calculations and some of the more complex things, some of the more complex forms of calculations you get with event-based analytics? You know, it is both for sure. You know, I mean, if you look at,

we have a very large payments company where everybody codes in LookML. Like they have a tremendous number of people coding in LookML. And they have, you know, a workflow of working on branches and then making pull requests and, you know, shared models. And so it really depends on the organization. It's like, how do people use Python? Well, they use it very different ways in different companies,

right? It's a tool. And there are definitely different cultures of working. So there are organizations where there's only one or two people who are doing LookML development, and they answer questions and send, you know, links back to dashboards and looks, which are query results, so that people can get their questions answered. Or there are organizations in which everybody's actually coding in LookML. And so it really varies based on culture, data culture, within the organization and what they're trying to achieve. So I'm conscious that you, moving on a bit here,

I'm conscious that you can't really speak about specifics with the product and where it's going in the future, but what's your vision, really? What's the vision for where the product goes? Things like package applications, I think, is an area you said you're looking at. You've also got the kind of concept of look at the platform as well. What's your thoughts about where you want the platform

and where you want looker to go in the uh the future so you know the the core of data is is it accurate right and so um uh it's let's see so raw data is pretty is not very interesting raw data is is everybody has to make their has to build it up to something to use. It's basically raw sensory input. But once you've built a model around it, you know what's good. And then that can be shared in a lot of things.

So for example, about a quarter of our business comes from people building things out of Looker, using Looker as a platform today. They've been doing it since the beginning. So we have people whose companies run with Looker as the core thing that they provide and the logins to the data that they provide to other people is Looker. And so that's always been a big part of our business. So packaging applications that can be installed into your Looker is a big part of what we're

doing and what we announced at Join. But also the ability to deliver data in, you know, it's the ability to digest data from external sources and deliver it into things where you are. So, like, we have a Slack bot, for example, where you can actually use a command line interface looker to pull data into a Slack channel. There's all kinds of things that we're doing that allow data to be used in the place you are rather than coming to Looker for it.

So on that point, one of the things I said to you in the past, actually, that I really like about Looker is the fact that it's not, you know, you aren't part of a kind of larger mega vendor, you know, with lots of ERP and CRM systems that, yeah, that's to the point then when all your product development ends up being just integrations with those with those uh those products but i suppose the other part to it is that analytics is at its most effective when it's part of a workflow and and when it does integrate in with with applications and processes and so on so again what's your thoughts on um what's your thoughts on looker's role as a kind of part of an analytic workflow and as part of a wider set of kind of business processes, really? You know, Looker has always allowed you to embed the results in other applications. In fact, one of the largest's, so it's, you know, it's the, the ability to take a piece of data and put it into some other application has always been part of what Looker does. In fact, you know, if, you know, for a long time, BigQuery was demoing their public datasets, and they were embedding Looker to demo the data sets against BigQuery. And so Looker, the ability for you to take something that you see, every piece of data, whether it's a dashboard or a look,

or the results of an explorer, is URL addressable. And you can take that URL and embed it into all kinds of things. And so the beautiful thing about Looker is that it's born of the web, and basically all the results, everything that you're looking at is web addressable. So moving on from Looker, the product to Looker, the company and the company and the culture and so on you've built there, what are the kind of core values that you try and live to and try and, I suppose, try and communicate to everybody in the company and to customers and so on? You know, one of the core Looker value, the most important one is probably love, look, or love.

And what that means is that essentially we will only succeed if our customers succeed wildly, right? And we have a complex product and we need to teach this complex product to our customers. And so we need to have nice people who are smart, who people feel safe around, right? And feel comfortable asking questions to. And in the company, we also have another value called the kitchen table, which is that basically there's no dumb question and you can ask as many times as you want. And whenever somebody asks you a question, you stop and answer it. And so it requires to be hungry, nice, smart people who are helpful because that's what it takes to teach a world a new way of looking at

data. I have a really smart friend who once told me that in order to learn a new language, spoken language, you have to be willing to appear stupid. And the same thing is with a programming language. You have to be willing to accept that you don't know it. Like, and we, so the way we do support, which is, you know, we have analysts that are available on chat to answer any question. And they sit around a table and they will answer any question as no matter how complicated. And you'll get a good answer. We don't say we don't know.

And it's pretty amazing. So that's the helpfulness and the whole company is centered around that. I mean, we knew that we had to do this to succeed. We built the culture around what it would take to make the company succeed. We couldn't, built the culture around what it would take to make the company succeed we couldn't you know there are other companies that didn't necessarily you know the sales organization it's it's a it's a helpful driven culture and um i see you you're also quite

a keen cyclist as well um so i think i saw an article once where um you know you take your bike to to work you lead um you lead uh cycling kind of cycling groups going out from uh from the offices there yeah i suppose how much is um health and um work-life balance important to you and to uh to looker yeah you know um i always say that a good life is a series of good days um you know and hopefully if you're working at looker this will be your best days like there's no reason that you're when at Looker, this will be your best days. Like there's no reason that when you work here, it shouldn't be your best days. And so, you know, we take work-life balance really seriously and we want you to be well-rounded and enjoy yourself. And that, you know, my goal is that Looker is the best place you ever work.

And so it means that you get to do things that are part of life. So I love to bike i it's my my my happy spot so i share that with others so lloyd just to finish things off just tell us about the joint events that are happening in the next few months around the world you know um so uh you know when people come to interview at looker i always say there's tremendous amount for you to learn there's we what we do is really interesting and powerful, but it takes education. And so Join is about coming, learning about how other people do it. We're inventing a new way to look at data.

And it's a great place to come get educated, to learn, to see what the best practices from what other people are doing. You know, we're all exploring the future together. It's been great having you on the show. Thank you so much for your insights and your kind of the back story really around Looker, you know, how it came about and where it's going. Thank you. You know, just a comment on that last thing is, you know, Margaret Rosas, who runs our Department of Customer Love, our support team, told me very early that we'll be successful when we have a thousand true fans. And enterprise software with fans is like kind of an oxymoron to a degree, right?

And, you know, and we do, we have fans. I love the fact that we have fans that that that people love that that looker makes people more powerful and they love both the company and the product that that's that that that makes me super happy so anyway Thank you.