Rethinking the Data Stack in the Age of AI with Tristan Handy, President of Fivetran + dbt Labs

Richie Cotton: Hi Tristan, welcome to the show. 

Tristan Handy: Thanks for having me. 

Richie Cotton: Yeah great to have you here. And next to begin with, congratulations on the merger between dbt and Fivetran. 

Tristan Handy: Thank you. It's been it's been a feat over the past year. A lot of work. 

Richie Cotton: I'm sure it has. Do you wanna tell me how it all came about and what the rationale behind it was?

Tristan Handy: The actual figuring out that we wanted to do this and the figuring out how to do it took about four months about a year ago now. It all started out just because George and Taylor, the co-founders of Fivetran, and I had worked together for something like a decade. And in fact the company that I was at prior to starting what was originally called Fishtown Analytics was a direct competitor to Fivetran.

In fact, it-- So it was called Stitch. Stitch and Fivetran were really the two first modern data stack native data ingestion tools. They were originally like, load data from Salesforce into Redshift. So I'd known George and Taylor forever and had collaborated, often over the years and really there is such a huge overlap between the user bases of Fivetran and dbt, and so just ample room for collaboration over the years.

And with a bunch of changes in the industry that have happened over the last couple years George and I thought it was the right time to be instead of close partners, to actually be a part of the same company. 

Richie Cotton: Okay. Nice. Yeah I hope it works out. Do you wanna talk me through the relative sort of positions within the stack that dbt and Fivetran take up then?

So you mentioned Fivetran's just, best known for being on the ingestion side of things, and then dbt you've described as being analytics engineering, slightly different. So just for the audience, do you wanna explain what that is and how the two things fit together? 

Tristan Handy: Fivetran as a product historically has always been about building the most reliable pipes possible.

I'm probably gonna screw up the mission statement they've used forever, but it's something like data pipelines as reliable as electricity or something like that. The funny thing about that is that you actually don't want to go to your electric panel and flip switches very often.

You just want to forget about it and make sure that everything works. And that is largely the promise that, that Fivetran has delivered over the course of the last, whatever it's been, 12 years or something. dbt, on the other hand is a product that users interact with every single day, and, That is because the process whereby you turn your raw data into meaning is something that is never really done, and it requires the the the constant adaptation of your datasets to the changing nature of the business.

And these, these two products really sit next to each other in the data pipeline. So you first ingest all of your data into your data platform, and then you transform it, and then the next stage is you do something with it. Maybe you give it to an agent or maybe you put it into a dashboard or whatever.

But so there's this supernatural handoff. And really historically, vendors like Informatica or Qlik or Talend or the, this prior generation of tooling sold all of this stuff together. And so as a result buyers, especially buyers in the enterprise, have been kinda trained to think that ETL is sold together as a package.

And so actually it's one of the many things, but one of the things that made the merger make so much sense because people were just used to seeing all this stuff come as a part of a package. 

Richie Cotton: Okay. Easy for enterprises to buy. That sounds like a, a good thing for you. I'm curious as-- So I had a bit of a conspiracy theory 'cause a lot of the, the bigger sort of players around data warehousing, it's Snowflake and Databricks, and with Fivetran and dbt combined I was curious are you trying to build something like that as well?

Tristan Handy: Something like a data platform? 

Richie Cotton: Yeah. Like a, a rival to those bigger cloud data warehouses. 

Tristan Handy: If you take all of our revenue and add it up we are still a tiny fraction of... i'm very proud of the business that we built. We're a non-trivial business at this point, something like 2,400 employees.

But we are a, a tiny fraction of the, the footprint of a, a company like a Snowflake or a Databricks. So I started using Snowflake in, I th- it was either, I think it was 2018. It was the first real cloud native data warehouse that I used. I s- I used Redshift before, but I would call that kind of a different thing.

And the fact that Snowflake could do what it could do was magic. It was just imp- and every single time, the, their SQL coverage was actually not that good back then. And so every time that they would release a new window function, I would like read the release notes with bated breath.

I was like oh my God, they now support rolling averages." Yet now we are, whatever, eight years beyond that, and The idea that you would have a cloud-native SQL engine that reads from blob storage and has scale-out compute and has complete coverage of the SQL dialect. Like all, all of that is expected.

And so what companies like Databricks and Snowflake doing to increase the value of their platforms to push out into like next use cases is to really move aggressively into AI. And I'm probably not the best person to comment publicly on, on their roadmaps, but they make a big deal out of the AI functionality that they're shipping, and that's great.

What we think is that as the data stack matures, it-- there's this real opportunity to provide these tools in a more open framework. And really all of that is based on the work that has been done in open table formats primarily Iceberg and the catalogs the open catalogs that are associated with that.

And because customers now have the ability to store their data in open formats, they can construct a stack that really for the first time in the history of data, for like many decades now, is completely free of the type of vendor lock-in that folks who have had, careers in data that span back to the, the halcyon days of Oracle will be like very familiar with the challenges around, around vendor lock-in.

So we want to build a an interlocking data stack that prioritizes open source and open standards and gives users choice. 

Richie Cotton: Do you wanna expand on like what your ideal data stack consists of then? 'Cause it seems like there was the, the modern data stack was a, a big thing like a few years ago, and it's very complicated and things have been getting simpler.

So what's the, what's this... I guess you used the term mature data stack. I don't know how standard that is, but contemporary data stack maybe. Whatever the term is. What should it look like? 

Tristan Handy: I wasn't trying to coin another neologism. I don't think we need... The, the, the way that we talk about this internally is ODI, open data infrastructure, and it is really a, a way of thinking about building a data stack around interoperability.

And so at the foundation of this is Iceberg, and we make it very easy to land all of your data in Iceberg. And we h- hand it over to you in a Polaris catalog that you can then plug into whatever data platform you, you like. We then obviously with DBT, transform data on top of that.

And the, th- the thing that this then enables you to do Is to go all the way from source to use case, making choices along the way. So f- here's example. You could imagine a situation where 80% of your data pipelines could be built on top of DuckDB, and th- that maybe that would save you a ton of money.

And so you could actually do that. You could have DuckDB running a bunch of your data pipelines, and then your gold layer could be served in, inside of BigQuery, whatever. And historically, or let's say over the past five, six years the, the way that people have thought about their data stacks is monolithic.

They they land their data into a single vendor, and then because they have standardized on that vendor then they use that vendor for everything. And if it turns out that there's some use case that vendor's technology is not that good for, sparks a conversation internally about migration. The funny thing is that's not how software engineers think.

N- Software engineers never say "Oh, I can only possibly use one database." No, you, you like building application and oftentimes an application has multiple different data stores. It's got Redis as a caching tier. It's got an object store. It's got a relational da- like you... It's not crazy to have multiple different data stores for software engineers.

But because of the way that data platforms have commercially developed they're these like monolithic things and we just think that's not good. 

Richie Cotton: Okay. Yeah. I love that you're gonna get more flexibility than you might even save some money if you're getting to pick and choose business software, and particularly a lot of open software is definitely cheaper.

D- does that then cause more management headaches though more governance headaches if you've got lots of different data stores and lots of different pieces floating about? How do you manage all that? 

Tristan Handy: So it's... Yeah, it's a good question. The, one of the, you mentioned the modern data stack before.

One of the things that typified the modern data stack era was that it was very common in order to put together a data stack that did what you needed, you might have to procure eight, 10, 12 different products. And nobody really liked that. Startups were fine with that if they put everything on a credit card, but enterprise procurement cycles don't really want to go through that process with 10 different vendors.

And so you're totally right. One of the ways that we think about this is that we as a company and awkwardly we haven't actually chosen a final name for the company yet. So internally we call it NewCo, externally we're calling it d- Fivetran DBT. But that superposition will collapse at some point.

We want to provide integrated solutions, but those solutions to have specific points at which customers get choice. So for example w- we have a product called MDLS, Modern Data Lake Service, and that is the managed Polaris catalog. It's all the data ingestion into Polaris, all the Iceberg table maintenance, all this stuff.

And you could structure this as the foundation for a proprietary data platform. Or you could think about it in an open way, and you could say now that we have this data here for you, you can plug whatever you want into it." And also, since we're so good at replicating data, we can actually replicate this Polaris catalog into whatever other catalog you might be using.

And so that's how we prefer to construct the stack is to build best-in-class components that all work together, and you can use all of our stuff if you want to, but it's natively built to assume that at multiple different stages, customers get the opportunity to, go use other tools. 

Richie Cotton: Okay, I like that.

So you can start with a, a managed service which is relatively easy to set up, I presume, and then if you wanna tweak it your own way, you can do that. We're about 15 minutes into the conversation. We've barely mentioned AI at all, which I think might be a record for this show recently. But it's often said that data is like the foundation of many AI initiatives.

So talk me through how does the Fivetran/dbt combination help AI initiatives? 

Tristan Handy: If you went to a data conference over the last six or six months or so basically every vendor at every data conference wants to talk about how what they're doing is supplying high quality context to your agents. And all you have to do is glance out across all the booths and you're like, "Oh my God, everybody's trying to do the same thing."

I think it is both true and not true that data is the foundation for high quality AI. The... L- let me get to the not true part first. The use case that is dominating AI right now is generating more tokens than anything else, is agentic coding. And agentic coding doesn't have really anything at all to do with your data stack, your company's proprietary data.

It just d- like those two things are orthogonal. And so companies are getting tremendous amount of value out of AI without thinking about the things that like data practitioners think about all day, every day, like at all. It is very common that data lags behind software engineering as a profession.

One of the things that dbt was founded on 10 years ago is the idea that really we needed to be doing data stuff more like software engineers did their work. And we tried to congeal 20 years of lessons learned into a set of best practices and tooling to get data people closer to the cutting edge.

And so I think that's what's happening here too. I think there are emerging agentic use cases in data as well. It's just starting to happen. So the obvious first one that everybody it doesn't take a lot of creativity to think about is, often known as conversational analytics.

Every, every organization has a bunch of data, and historically there's a couple ways that you get access to that data. Maybe you've got a, a BI tool where you click and drag and make some charts. Maybe you have a data team member that you ask them to build some stuff for you, and then they ship you back a thing later.

Often they're irritated because that's not the kind of work that they like doing the best. Yeah, there's, this is like different ways that you get access to your data. But now if you set everything up right you can go into your cloud code or whatever it is that you use, and you can ask standard questions that people have been asking for, about their data forever, and you can get correct answers.

Now the line if you set everything up right is doing a lot of work there, and I can say more about that. But th- that is a pretty groundbreaking thing, that you can just go in and ask natural language questions and you will like generally get pretty high quality answers at this point.

Richie Cotton: Yeah, I love that. Yeah, most people can now do at least basic analytics just by asking your favorite AI what yeah what your question is. So there was that key line in there, if you set everything up right. Talk me through what does that involve? 

Tristan Handy: The foundation for that is the same high quality data management best practices that people have been doing for a long time.

Most especially your agentic analytics is going to be plugged directly into y- what, your gold layer. So the tables that have been the most highly processed into the most ready to consume f- to for analytics. Once you make sure that your gold layer is really clean, which not only does that mean make sure the data in it is of high quality, it also makes m- means that like you don't have a ton of duplication either of tables or of columns in tables.

I'm sure that all of us have existed in environments where there's like the customers table that one team uses, and then the customers table that another team uses, and there's like the one yes/no flag that indicates this thing, and the other yes/no flag that's almost the same thing, but it's just a little bit different.

But like eliminating that type of ambiguity and forcing the hard conversations about how do we make this thing like simple and consistent is just like really important. But after that there is a, a set of things that analytics engineers have been doing for a little while. And that is things like making sure that your objects have high-quality documentation, like human or machine-generated documentation that actually describes what these things are.

And then you go a layer beyond that And you get to the, the semantic layer. And this is-- the, the semantic layer is a thing that people in the industry have been talking about a lot for years now, and oftentimes have been a little frustrated, and we've been frustrated internally, that in the BI era the semantic layer never became as central or as critical as, as we wanted.

But that was often because the BI tools acted as this choke point where if they, if it wasn't their semantic layer, then it wasn't very well supported. And it was really hard to get around that. But in the agentic era, agents desperately need governed definitions of things so that they do not have to figure out from first principles what this user is requesting.

They can just see, "Oh, they want revenue. There's a revenue definition right here. Cool. I'm just going to use that." And not only does that increase the accuracy of responses, but it also decreases the latency. It also decreases the number of tokens that the agent has to actually use in order to get to a good response.

And so the semantic layer is increasingly critical in the era of agentic analytics. 

Richie Cotton: That sounds like a, a triple win there. Yeah, better reliability, less money spent, less time spent. Yeah this sounds very important then. So what do you need to do to get a semantic layer set up? 

Tristan Handy: There are multiple competing sem- semantic layer solutions.

You, they, some, some BI tools have them. Famously Looker was built around their semantic layer called LookML. W- we, about a year ago now started a consortium called the OSI, Open Semantic Interchange. I don't know why, but the Apa... And we opened this up and it became an incubating project at the Apache Foundation.

And recently, I think we violated some naming convention at the A- Apache Foundation. I think they didn't like an acronym, and so we, it, we renamed it to Ossie, O-S-S-I-E. Now has a cutesy little animal as a as a mascot for it. But i- the, the essential thing here is that, Apache OC provides a common way to define your semantic constructs.

And there is a whole vendor ecosystem m- many different BI tools that support it many different data platforms that support it. We support it. There's probably a, a dozen or more vendors that all support this m- particular mechanism for capturing your your semantics. And the if you use this format you can then feed that natively into your agents using the dbt MCP server.

I'm sure there's other ways to do this, but we internally use the dbt MCP server to do that. And then just automatically your responses from your harness are going to look up the appropriate metrics and include those in their responses. 

Richie Cotton: Okay. I like that. So once you've got this technology set up and hopefully is a, I guess an OC compliant semantic layer, and then at that point, yeah your agents can then go and find the right definitions.

They go and do the analytics and hopefully in theory your self-service analytics works across your business. Who's in charge of creating the semantic layer though? 'Cause I guess i- is it suppo- is this a data team task or do you need like business team people 'cause they know like what revenue should be defined as or things like that?

How does it work? It sounds like it might be a cross-team initiative. 

Tristan Handy: We are in the midst of one of the biggest shifts in the way that data teams operate that have happened over the last 10 years. So the data team, is, I think, really bifurcating into two large buckets of responsibility.

And so the first the first bucket is really maintaining the platform. So working on this centralized infrastructure, and that includes all of the ETL, includes governance and makes sure- making sure that the right roles have access to the right datasets, and da.

Like all, all of this kind of like platformy things. And then there is the I don't know, the democratization the sharing, the making sure that the data gets out into the organization. And historically, that would've been often done by like actually creating reports. Increasingly that is more done by enablement like getting people throughout the organization set up on the tooling and teaching them how to how to use it.

It's done by partnering with business stakeholders to actually take their definitions and encode them into semantic models. So I do think that like primarily it is still the data team's responsibility to create semantic models, but, I think there absolutely is a feedback loop because the-- what often the ideal flow is that users throughout the organization are asking their analytics agents questions all the time.

And those questions get naturally captured in the query logs of the data platform, and it becomes actually not that hard to ask your agent as a data team member, "Hey, go through the last seven days of questions that have been asked that didn't hit the semantic layer because the semantic layer didn't have a concept that was needed, and suggest the top 10 things that we need to do to extend our semantic models."

And so this kind of flow, I don't think it makes sense for, generally for business users throughout the organization to be just creating metrics willy-nilly because that will actually lead to a bunch of sprawl and confusion, and I think your, the quality of your answers are gonna go down. But using kind of the exhaust of their questions, data team members can actually propose new metrics and thoughtfully design them into the system.

Richie Cotton: Okay, yeah. I can see how you don't want, like, individual salespeople to be defining the metric for what their sales target is. So you you want something standardized in terms of what the the process are. But that's fascinating about the change in the structure of the data team.

So it's now like a, you said like a data platform team and a data enablement team, and then I guess a lot of the analytics gets pushed out to the, the rest of the business then. Okay. 

Tristan Handy: I think that's often true. That's not to say that you're gonna completely do away with roles that have particular quantitative expertise.

I think that to, experimentation is an area that, that is al- has always been will continue to be quantitatively thorny. And so I don't think that's going away. But there's a lot of the work that data practitioners have been doing that doesn't require a- any specialized knowledge of quantitative methods.

You're doing some group buys and printing a, a chart. 

Richie Cotton: Yeah, there's a big difference between creating a machine learning model from scratch and just figuring out what are your top three products sold at this particular- ... store. 

Tristan Handy: And I think that there's the 80/20 rule.

A tremendous number of questions throughout the business are like that, that kind of basic stuff. 

Richie Cotton: Absolutely. Suppose the data team's got this new role, this new structure are you hiring for different skills then, different profiles? 

Tristan Handy: What should data people be learning? Yeah.

It's a great question. I was actually just talking about this in- internally with somebody. I, I really believe that we need to move away from data job titles that describe our technical capabilities. It was something like four years ago, somebody published this Substack piece that had a, had an image in it that was like all the data job titles from left to right.

Left was the most technical and right was the least technical. And it was like data platform engineer and data engineer and analytics engineer and data scienc- what- whatever. I can't remember the ordering or whatever. But then you realize over time that these roles do not tie to like how does this person create business value?

They tie more to like what language do you like to code in? And what, what tooling do you use? And and I just, I like don't find that particularly useful. And in a world of in, in a world of coding agents anyway all of us if we don't have a particular technical skill set today, then the, the learning curve is steep and we can be doing that work very quickly.

And so what I observe on the, the best data teams today is that they're focusing on full stack data practitioners that can, they can do really most of the tasks most of the technical tasks that, that are required and then they get to own projects end to end as opposed to having an eight-person team that, can tackle something together.

I think in general with AI, what I've found is that the most high performing teams, whether you're talking about software engineering or data or whatever, they actually give discrete tasks to one human. They say, "Here's a thing. Go get this done." And to the extent that you're able to be one of those one humans, I think that, that is a tremendously empowering thing for your career.

Richie Cotton: I love it and I love the idea of becoming a, a full stack data person, but there's been a thing over the last few years about how junior employees, or it's much harder- Oh my gosh ... to get a job as when you're just out of university. So yeah, you can't go from zero to I'm a full stack data person.

How does the career progression, like how do you get to that point? 

Tristan Handy: So yeah, I, that, that is a great question. On some level my answer is I don't know, and I don't think that we as an industry know. I don't think software engineers have figured that out yet either. And I think it's fair to say that this is a point of stress for early career folks and also for companies, because I think companies want a talent pipeline.

There's just this question of the kind of forces in the industry pulling in one direction and, the, the thing that I would really suggest is that, Young-- but okay, so this is maybe a bit of a digression and I apologize. But I used to play tennis in high school, and that was a, a minute ago at this point.

And when I played tennis in high school, I used what's called a closed stance for my forehand. Whatever, it doesn't matter. But that's the way that people played tennis back then. And then the open stance became more common, and I didn't have any tennis instruction in the intervening period. And so I recently went and got a tennis lesson, and the instructor was like, "Oh my God, we've gotta reteach you everything from the ground up," because people stopped playing that way 20 years ago.

And I guess the, the point here is that it's easy to see when you are recently coming out of school the hard things that you're facing, which, maybe this is one of them. But it's sometimes it's hard to see all of the ways in which you're, you have an advantage. And there are people currently working in really good data jobs that have been through like three or maybe even four generations of like truly massive change.

And that's hard. You have to, rebuild your mental model over and over again. And, I'm in my-- I've been doing data now for 23 years, and the... As much as I'm fascinated by AI and using it every day, I don't think I'm ever going to be as AI native as somebody who is coming into the workforce and like this is just the air that, that we all breathe.

So I think that like the ability to learn quickly and to use these tools like a, a native speaker is a, just a ginormous advantage. 

Richie Cotton: Absolutely. I have an intern out of this year who is 19 or something and can vibe code drastically better than I can even though I've I've spent years and years programming on and off over the last few decades.

So yeah, young people definitely do have an advantage in that case. So actually, while we're being middle-aged and completely perfect. Yeah how do you go about reskilling yourself? How do you go about changing your brain in order to keep up with all this technology? 

Tristan Handy: Okay. That's an interesting question.

I've never been asked that before. But you know what? We were-- At the very beginning, we were talking about the, the merger, and just on a personal level I was CEO of what became an 800-person company. I had been the CEO for 10 years, and I think you will not be completely surprised to find that being the CEO of a, somewhat large company has some demands on your time.

And so one of the things that was motivating to me to to do this merger, aside from all the other very good reasons, is that personally, I wanted to get closer to the metal with all of the changes that were happening. I, I, I-- And so I actually crafted myself a role in the, the new merged company that has me spending a lot of time building and learning and, doing this kind of stuff as well.

But so I probably spend, I don't know, half of my working hours right now directly working with agents. And I don't know that means that I'm ever gonna be a, a native, but it turns out that a lot of the existing skill sets that you have are valuable. The, for, I don't really understand, and this is maybe a grumpy old man thing to say, but a lot of people really seem to be very obsessed with the idea of agents running in the cloud because no one wants to close their laptop because then it, it kills other agents.

And I'm like, "Has anyone heard of Tmux or SSH?" We can do all this stuff. You buy yourself a, a $300 computer, stick it on your like next to your washer and dryer at home and give it an ethernet cable and you can you can have your own agentic backend. There's skills that, that come from, the, the decades of experience too.

Richie Cotton: Yeah. Nice. You can reinvent solutions from yeah, before the cloud from going back a few decades and yeah you have knowledge that maybe the the 20-year-olds don't have. Okay, nice. Just since you said you were wanting to get closer to the metal- ... what are the exciting things that you're building there?

Like what are you most enthusiastic about at the moment? 

Tristan Handy: Okay. The thanks for asking. Everybody wants to be asked what they're vibe coding. The, i'm not a software engineer by trade. I think that most people that are vibe coding stuff, they are attracted to the idea that "Oh, I can now build software that I couldn't build before." And that's certainly cool, and I maybe have built a couple of little things like that too. But the thing that I find More interesting than anything right now is the ability to do research.

And I, I... Th- this context engineering position paper that I was sharing before, th- this is an act of agentic development. I started off with 10 research questions, and I outlined a research process. I outlined a a criteria that a long-running agent could use to say "Okay, I think I've learned all that there is to know about this particular topic."

And I said, "Okay, get curious as you read stuff. Add your own research questions that you think are interesting to the list." And then I told it to go to town. And now in, I have this corpus of URLs with summaries and the, the act of writing the white paper is... i've written documents like this before, but the act of writing this piece of research is just dramatically different.

It's like having a team of graduate assistants that you're working with all the time, and you get to be the primary investigator as opposed to you have to go and read a bajillion documents and synthesize them all in your head and all of this stuff. And the output is just much, much higher.

I'm trying to do the... My, my wife is a s- a pediatrician. She works with a, an organization called the Vaccine Education Center. She does a lot of the literature reviews, mostly from PubMed materials. And so I've been, like, working with her to figure out, how do you do literature reviews in medicine?

Because this is a thing that doctors are doing all the time. They have their interest areas and you have to keep up with what is the most current knowledge in this field? And it takes a lot of time, and it turns out that agents are just really good at doing this stuff.

Richie Cotton: Absolutely. Yeah being a doctor, there must be more research published than you could ever possibly read in a day, even if you spent all your time. I love the idea that you can use agents for research as well. My experience is by default you tend to get some really shoddy results and it takes a bit of care to get good research back.

So do you have any tips on doing good context engineering here? 

Tristan Handy: Yeah. It's funny I hear that from people. That has not been my experience and I don't know what that means I'm doing differently. But I guess in general I try to break the research process down in, into the way that I would have done it as a human.

And by, by breaking it down and not a- allowing the model to have a lot of creativity around the process itself you don't allow it to use its own knowledge very much. I think that oftentimes when hallucinations happen, it is because the model thinks that it needs to know the answer itself.

And if you make it clear "Hey, your job is not to know the answer," like that's why you have web search. Or maybe I've given you a bunch of other tools to go get other knowledge bases. But your job is to like reason about the plan and to coordinate all the steps and at every step you have to show me the proof of where you got that information from.

I... and then like you're constantly outputting a, a chain of proof via like a series of markdown files and traces and everything on your local machine. 

Richie Cotton: Okay. Yeah, great tips there. I love that idea of making sure that proof is provided at every step. It's like that Wikipedia idea of citation needed everywhere.

Yes. Yes. So make sure that the steps are traceable and then you're gonna get some better answers there. Okay, wonderful. Just to finish with I always want more people to learn from, so whose work are you most excited about at the moment?

Tristan Handy: This is maybe a little bit off the beaten path for data people but I find the most high signal-to-noise source on the internet for keeping up with all the movement in AI to be Simon Willison's blog. He is a longtime software engineer, and he writes very, like, short but high-value posts with all the main news coming out in the in the AI ecosystem.

When there's model releases or other news stories, he covers them in a very accessible way. 

Richie Cotton: Absolutely. Yeah he's a fantastic writer. And yeah he's very good for news coverage. Yeah, that's good recommendation. I like that.

Excellent. All right. Super. Thank you so much for your time, Tristan.

Tristan Handy: Thank you. It was a lot of fun.