Chad Sanderson: Fixing Broken Data Culture, One Contract at a Time

Data breaks. AI models go crazy. Downstream teams scramble to put out the fire.

In this episode, I talk with Chad Sanderson, CEO and co-founder of Gable - a startup rebuilding data quality and governance from the ground up. We dive into the “shift left” philosophy: why upstream engineers must own their data outputs, how data contracts create accountability in AI systems, and what it takes to drive real cultural change across an organization.

We also zoom out into Chad’s journey - from martial arts and journalism to leading data teams at Microsoft and Convoy. Along the way, we unpack why upstream ownership unlocks downstream speed, why the future of AI depends on mapping data flows end to end, and how a mission rooted in truth and transparency ties it all together!

A must-listen for anyone navigating the messy intersection of product velocity, data integrity, and organizational scale - the foundation needed to truly unlock AI’s potential.

https://www.gable.ai/

https://dataproducts.substack.com/

Transcript

Rui (00:26)
Today on Floating Questions, I'm talking with Chad Sanderson. Chad is the CEO and co-founder of Gable.

a startup tackling one of the biggest headaches in modern data infrastructure, keeping data trustworthy, consistent and usable across complex organizations. Before Gable, Chad led data platforms at companies like Convoy and Microsoft, where he navigated the challenges of making data reliable at scale. He is also the voice behind the popular data products sub stack.

where he shares thoughtful and sometimes provocative perspectives on how to rethink data contracts, data governance, and the future of data infrastructure. Beyond the data world, Chad has a fascinating background from training as a journalist to martial arts in practice in Asia. Chad, thanks for joining me today.

Chad (01:24)
Hey, great to be here and good to see you.

Rui (01:27)
Okay, let me start helping the audience understand your startup. the way that I would frame it and correct me if wrong, I think Gable is trying to fix the death by a thousand cuts problem for data and AI teams.

when others are just asking the question of how much each cut is worth. ⁓ That's how I would frame it. Would you frame it in a different way?

Chad (01:53)
Yeah, I think that's a really interesting framing. ⁓ mean, definitely death by a thousand cuts is ⁓ certainly accurate description, I think, of the problems that data teams are experiencing right now. I also think there's a, ⁓ you call it a more core ⁓ fundamental underlying problem, which is there's an entire sort of category of quality ⁓ that's simply missing.

And the way that we like to think about this missing category of quality is output quality. So most developers, when they're trying to ship their code, the quality they're thinking of is, will my code compile? Will the software work? But there's this other aspect of quality, which is, well, is the thing that I am producing going to be the same as it was before I made the change? And as an extension of that,

are the people who are consuming it going to be affected in some way by whatever the change is? that's sort of like a, I think if you were going to talk to any other industry where there is a handoff between two parties, like if we're talking about logistics, for example, and we're McDonald's, and you've got the beef patties that are sort of being created by, I don't know, it is that creates beef patties, and they're handing those off to

the restaurant, there needs to be some clear set of expectations that says, hey, yeah, when we make a change to our beef patty formula, it's one thing to ensure that our machines don't break and we still get beef patties and sort of a similar number of them. But it's another thing entirely to say, did we change the formula in a way that causes our customers to not want beef patties anymore?

Or did we add some potentially dangerous chemical to the beef patties that ends up killing someone? These are two very different types of questions. And I think that quality in software for the last 20 or 30 years hasn't really been focused on that second type of question. That's led to a lot of the problems that we observe in the data space today.

Rui (04:07)
Right, this is a great segue into talk about the general philosophy behind how you and your company is trying to solve for this problem, which is this shift left thinking, which is, if I'm an upstream engineer making code changes, and there are 10 downstream teams depending on the data source

then what you want to do essentially is to have a contract with that engineering team that is overseeing the source code. And so that whenever they make another change in the future, they need to communicate it with the downstream team ⁓ to say, hey, we're going to make this change. Are you OK with how the data is going to be affected? ⁓ So essentially pushing a lot of so-called janitor work on the data team.

to the upstream Is that a fair way to summarize the general philosophy? Obviously, we won't get into into a little bit more nuance, but this is the theme that I'm getting.

Chad (05:06)
Yeah.

I mean, there's definitely nuance, as you said, it's a complicated problem, but in general, that is the idea. And the core thesis is if you're the producer of really anything, but certainly data. And one problem is that a lot of developers don't think of themselves as producers of data. They think of themselves more as owners of applications and systems that have output, but not really

as a data producer wherein that data is utilized in many different places all around the company for variety of different reasons. ⁓ And the shift left philosophy is saying, well, number one, we all need to accept that as a ground truth. That there is this sort of categorical data producer class and there is a consumer class. We need to acknowledge that that exists and that one depends on the other. And if you're investing heavily into machine learning or data science or analytics in your company,

then you will always have low quality data so long as that acknowledgement doesn't happen. There's really nothing a consumer can do about low quality data arriving to them other than attempting to react to that low quality data as quickly as they possibly can after the fact. And that simply isn't sustainable if you have a tremendous amount of data, a lot of producers, or a lot of consumers. It just doesn't really work in a centralized way. And it wouldn't work in any other industry.

So the equivalent here is, if you've got your meat packing plant that's sending out your patties, you probably don't want all 5,000 McDonald's restaurants to individually be responsible for ensuring the patties that they receive are of high quality. That's not scalable, and it's going to be hugely ⁓ variable depending on those particular restaurants. The better thing to do is to make sure that the singular meat production plant has an understanding

of what those restaurants need to be able to serve their customers. And in fact, this is exactly how McDonald's operates. The quality is not enforced by the teams who are, by the restaurants who are serving the food, it's enforced by the producers of the food who are following a particular standard. And so what we believe is that the data world, the tech universe, needs to follow a similar paradigm. That's what scalable,

That's how you actually solve the quality and governance problem.

Rui (07:33)
Right. Maybe an obvious tension here is between the developer velocity versus data quality control, right? ⁓ So if you're asking the data producer, those software engineers to have additional checks, then you're potentially slowing down their development because then now they're going to have to spend time to talk to downstream team. ⁓ So how are you thinking about this tension? Are you saying that slow is fast?

Chad (08:03)
Yeah, I think there's a few interesting things that are kind of happening here. The first is, yes, we are saying that culturally, if you want data to be an important part of your organization, if you have business critical data use cases like ML, AI, analytics, and so on and so forth, if this is important to you, then you have to treat data like it is any other part of the product.

It needs to have SLAs, it needs to have clear ownership, there should be APIs, and sort of a data contract is really the mechanism through which you create that level of accountability. And any time you add accountability into a system, or you add more testing, or you add more governance, you are going to slow down. And this is what we saw with DevOps, it's what we saw with sort of quality control, shifting left back to software engineers, becoming responsible for unit testing and integration testing and things like that.

And while in the beginning, this was perceived as a cost burden on the developers. It's like, well, why do I have to write my own unit tests? Why do I have to write my own integration tests? Can't someone just do that for me? Well, the answer is yes, theoretically they could. A centralized team could look at your code, write the unit test or the integration test on your behalf. But this takes a tremendous amount of time. It becomes a cost center. And eventually, it makes you go slower.

Because now all code has to pass through this small group of people that act as a bottleneck to value and to deployment versus simply having every engineer being responsible for their own quality. Sort of the same paradigm we're seeing in data where, yes, right now, all sort of forms of quality on the data side are flowing through a data engineering group or a platform group or whatever. But this is a bottleneck to the... ⁓

to the value you get. It's a bottleneck to the number of machine learning models that you can ship, how often you're deploying AI, how many amazing decisions that you're making. You're creating these value bottlenecks. So I think that's something that's important for executives to understand. If we're going to take data seriously and make it as a part of our business strategy, then we need to focus on the velocity of ⁓ data products. How quickly are we shipping out new things that make the business money?

There's the flip side to that that I think you're also touching on, which is, OK, Chad, this is all well and good. However, going and trying to convince a developer to slow down for no benefit is actually very challenging, right? Saying that I need you to do the right thing and to add more tests, and you're going to be making your own deployments go faster because you're having less outages and less bugs and things like that. OK, well, that's one thing. But to say it's really not going to affect you at all,

but it is gonna add a lot of benefit to other people in the organization, that's like a very different thing. in many cases, it means the incentives are not aligned, right? I don't get a bonus for ensuring that someone else many teams away that I don't talk to, that I don't know, can ship incrementally faster. I would love for that to be true, but today that's not really acknowledged, right? ⁓ And I think this is where the real power of shift left comes in, the real acknowledgement.

is it actually applying data engineering and data management best practices to software developers is value in and of itself to those developers. There's actually really, really great things that an engineer will experience by applying data contracts for themselves, applying code level lineage for themselves, and what the downstream teams get is high quality data as a byproduct of that ownership. So that's sort of another side of this.

Rui (11:36)
Mm.

Chad (11:53)
Number one is, yes, we've got to acknowledge if you want to ship more ML, ship more AI, you have to treat data as a product. And then on the other side, there actually are valuable things that software engineers can benefit from by applying these data engineering best practices upstream.

Rui (12:08)
Can you actually go into a specific example for how engineers actually love the solution, even though they're not the direct consumer of those data?

Chad (12:19)
Yeah. So I think one thing is root cause analysis. So if you're a developer, again, I like to talk about this in terms of output. The main function of a piece of technology is actually just to move data around. We're bringing data in through some system. We're transforming it. We're enriching it. We're masking it. We're applying some interesting functions to it. And then we're doing something with that data.

displaying it in a UI. We might be piping it into an API, which ultimately gets consumed by someone else. We might be generating an event that gets consumed by a machine learning team. But as long as something is leaving our system and being consumed, it's doing it in the form of data. So you can imagine if I'm an engineer and I make a change not fully understanding how my change is going to cause a data consumer to be impacted.

If I cause a critical system to fail, if I cause my UI to go down, if I cause my machine learning model to start making incorrect predictions, ultimately that's going to come back to me. And someone will say, hey, upstream team, you are causing X amount of dollars in business damage. ⁓ This is an outage. We think that it probably came from your service. Now you need to go in and fix it. And this can be a very, very time consuming process.

Especially if you have a big, complicated code base. Maybe there's hundreds of thousands of lines, millions of lines in your code, and you need to somehow track down the exact change that caused this weird, outlier edge case to affect the data coming out the other end. This is a very, very difficult thing because it's not, oftentimes not overtly obvious what that change was. Maybe I decided to upgrade to a new version of an SDK,

And for some reason or another, this changed how we're counting impression events. And that then changed how our machine learning model, which is like a relevance model which consumes impressions, is performing. So if you don't actually have clear visibility of where is the data coming into your system, how does it move across your system, how is it transformed, where does it go out the other end, and how is it consumed, it makes those root-causing analysis efforts

incredibly difficult. They can take days or weeks or sometimes even months. But if you had that into invisibility and you could actually map it to the changes that have occurred in your system, then you take sort of the mean time to resolve these issues down by an order of magnitude. You might take it down by 75%, 80%, 90%, even more. QA teams is another example that really, really suffer from this problem. So generally in QA,

If you're testing a feature, you're testing an output, ⁓ the most time consuming difficult part is the data side. Because it's not always easy to infer that some system is producing the expected data until it's actually deployed into a production environment. I actually have to ship it and then see what it produces, or I have to go through a lot of testing in some QA environment and see what it produces and then map it back. And if it's wrong, I have to roll back the change.

So oftentimes it's actually, is this thing producing the right data? That's the largest gate to being deployed. Now, if you had some idea of, well, I can automatically understand exactly what my data is doing, what it's going to do. I can infer what data will be created without needing to actually ship it into production. And I also know what the very clear expectation of that data is supposed to be as defined by the consumers who need it. Again,

I just shortened that time to actually getting something into a production environment by an order of magnitude. So there's a lot more examples of that that we can talk to, all the way from performing migrations to doing an impact analysis before you actually ship something. ⁓ But those are sort of two very common ones.

Rui (16:24)
Very interesting. I think before I dive into a little bit more detail for ⁓ how data as a product and work contract work, I actually want to take a step back What are the assumptions behind this whole shift to left philosophy in the data management that you're advocating for? ⁓ Because I feel like there are a few assumptions like, engineers.

want to actually own the data quality, that they actually want to accept the responsibility for something that traditionally ignored. And the assumption that we need to move away from a centralized data team or data governance to a more decentralized one. And the way to do that

is through this whole shift to left tooling. Is there an alternative world? What would be an alternative solution to whatever hypothesis that you are basically building this company behind that sometimes you would think to yourself, maybe I should consider that route as well?

Chad (17:28)
Yeah, I mean, there's definitely a lot of assumptions. I mean, I think one assumption is that the track that we are on is just generally ⁓ untenable. As AI becomes larger and more common, as ML becomes more important, as ⁓ code bases and services get more sophisticated and more federated, ⁓ the sort of assumption that we're making is that this is simply not a manageable ecosystem.

And the sort of largest tech companies in the world, like Google and Meta and some of these other organizations, are actually spending billions of dollars both on software and people in order to keep this problem in check. And that if you're really any other company in the world that's not named Google or not named Meta,

You simply don't have the resources or the technology to do this yourself and so you will suffer from these problems You sort of take the brunt of the issues and you won't really be able to do with it and will impact your velocity I think the assumption is that teams will recognize that right like they Many organizations have not recognized that yet, or they haven't necessarily put a name to the problem But our belief is that they they will recognize it

One outcome, one potential outcome is that people don't recognize it. They simply accept that this is the operating model that we've dealt with for the last 20 years. And yes, there is a pretty large impact to velocity and our ship speed. But we're OK with that because there's more important things to focus on. So again, my belief is that as ML and AI becomes more important,

It will be difficult to justify what is more important than our velocity and getting more models and sort of iterations of AI out the door. But that's kind of the bet that I'm making. The other sort of big bet is that, yes, eventually the software developers will want to own this themselves. I think that it's going to be very difficult to mandate from the top down in the beginning that a developer needs to go in and own the data purely for the benefit of another person.

This just doesn't really align with the way that humans do things in companies. So that's going to be a really, really tough ask. I think the only way that it's going to work early on is if there is some incentive for the software engineer to want to do this themselves. And that's where I sort of mentioned this at the beginning, but I think it's critical that the software, that the vendor, actually provides an in-built incentive for the developer to be willing to take this stuff on.

Otherwise, I just don't think it'll work and it certainly won't scale. Now, our belief is that at a certain point in time, it's of point of critical mass, then you can sort of come in with the hammer and start to ⁓ prescribe how developers ought to behave. And we're seeing this in security. We see it in compliance. We see it in DevOps. We see it in developer experience. But it does take a few years of that more organic adoption.

before it happens. And then the final thing, the final major assumption that I would say is that people are going to care when they get the relevant information, right? So the assumption here is like, if a developer is making a change and they receive information before that change is deployed that, hey, you are going to cause an impact to a machine learning model, you are probably going to cause a feature to degrade, and that is going to cause the business to lose $100,000 per day until it's fixed.

that armed with that context, they will probably do the right thing. They'll say, hey, I probably need to talk to this person before I make the change at the very least, or maybe I don't even ship it at all. There is certainly a world where no one cares about that information. They simply say, well, look, this is not my problem, and I'm going to do it anyway. And I don't care if it loses the business money. We hope that's not the case, and we believe that people are better Samaritans than that.

But again, I think in the long term, this will move from people choosing to do the right thing with the right information to businesses simply dictating if you are going to cause an impact of a certain degree to a model or to some other data product that's important to the company, then you cannot ship your code change. But it does have to go through that sort of process first.

Rui (21:58)
Fascinating, I think there is a lot to unpack. I'm gonna cherry pick the one about organization change, about the top down potentially, know, leadership dictating that we need to make the data first class citizen within the company in order to make sure the success of AI or ML projects. my question is in the future, do you see how companies are organizing themselves today?

be shifted because the data needs to be the first class citizen or which part of the company likely is going to be shifted.

Chad (22:33)
Yeah, yeah, that's a great question, I think. And yes, I definitely think that there's going to be a shift. It's a little bit difficult to exactly what that shift is going to be and how organizationally it will manifest. So something I'm a big fan of is this concept of data mesh. And data mesh has been around for maybe the past five or six years. And it does represent more of the organizational change.

that likely needs to happen in order for data to become a first class citizen. And the relationship to something like a data mesh, which is more about the data product model, where the organization, instead of being oriented around features, you actually are oriented around domains of data. You have these big nouns like ⁓ shipments or packages or orders or customers or deliveries. And you're sort of oriented around making that.

particular experience and that data object very high quality, obviously from a data perspective, but also from a user experience perspective too. And then each team that owns that data domain is responsible for the outputs. So ensuring that there is a clear contract in place, ensuring that they're producing something that the rest of the organization actually cares about, right? That's kind of the ideal cultural utopia, I guess you could sort of describe it as.

And there are a few companies in the world that have either already moved to that model or trying to move to that model. And those are the businesses where data is really, really essential to business operations. I think everybody thinks that data is important, but there are sort of different levels of importance. And the companies where it's extremely important have made that first step.

I like to ⁓ think of data mesh as the equivalent of agile software engineering. Agile was created in early 2000s. It preempted Git and DevOps and all of these things that I think we associate with agile today. And it basically said what I said just then and what we're talking about. like, look, the culture in a company has to change.

We can't do six month, eight months, one year release cycles. There's so much that we don't learn. We have to be more iterative. And the Agile approach sort of represented an organizational model for how to do that. The problem was, of course, that changing your organization with a hammer is almost impossible. There is not a great motivation to do it. Most people don't move fast enough. And if you get that resistance at the bottom layers, it's just really hard to make it work.

So why is it then that most companies today are agile or they follow agile principles, right? Like they have standups and they have Scrum and they have, you know, they sort of ship on a regular basis. Like, why is it that they're doing that? And my perspective is, is the technology is what enabled it, right? Version control and tools like GitHub enabled it because they provided a valuable utility to the software developer that they didn't have before.

These tools basically said, hey guys, you experience a problem when you're writing code. And the problem is, you're not able to work on the same software in parallel. And that takes a tremendous amount of time. And you don't like that very much. So let's introduce branching and merging. And the other thing that you don't like is code review. Code review sucks. And the reason it sucks is because I need to go out, I need to find the five or six or eight relevant people, and I need to schedule time on them with the calendar.

and then I need to go down and diagram out what I'm thinking in my code, and there's a lot of feedback, and it's of decision by committee, and nobody really likes that. So let's change that. Let's just show on the screen exactly what the code is that we wrote. Let's show the diff, what's different between the thing that I wrote and the new thing, and then give you the opportunity to come in and add comments in this sort of iterative, ⁓ federated way.

Like, there's all sorts of things like that that I think added value to the software engineers who adopted it organically for their own selfish needs. And then what happened, right? You've got all these developers that are now starting to parallelize. They're code changes. They're starting to move 10 times faster. And the old organizational model of waterfall doesn't make sense anymore. It doesn't make sense to do a six-month planning cycle if I can ship a change tomorrow.

Like, why would I do that? Like, something's not adding up. So the organizational model of Agile filled this cultural gap because the tooling And I think that this is going to be the same thing that happens in the data space. If software engineers start to care about their data, if they start to treat it seriously because there's something in it for them, if high quality data comes out the other end,

then this model of working that we have now, where we don't really care about our output, we don't care about who our consumers are or what gets produced or how it's used across the business, that's going to go away and there's going to be this cultural organizational vacuum of, well, what do we replace it with? And I think that something like a data mesh is likely going to fill the void.

Rui (27:45)
Fascinating. There are so many points, again. And so I'm going to pull on a thread, which is related to something that I'm currently dealing with. ⁓ In the data production utopia world that you're describing, each domain data owners, would emit high quality data and making sure it's consistent across ⁓ all the different domains usage. ⁓

And recently, I'm actually trying to push this with a different organization within the company. And one thing that I've been thinking about is that for my specific use case, maybe there is a specific framing or definition of, let's say, an entity that I care about, Like how do you define what is a payment or how do you define what is a transaction or how do you define a customer? Let's say you're the owner.

of this domain, let's say payment space, and I am the consumer of your data. And from my perspective, I would like you to define payment this way, but perhaps to finance, you will like to define the payment in a different way. So what I'm trying to say is that as the producer of that data facing different consumers, they might want a slight

different definitions. ⁓ Is that the case that you're seeing Or more often than not, what you're observing is that actually all of these consumers want to have the same definition across the org so that they can talk about the same thing.

Chad (29:18)
⁓ I think that's absolutely one of the big challenges. This is something I've done most of my career. When I was at Convoy, I did something very similar where we worked out the whole map of

nouns and verbs and adjectives and adverbs in the company. And we figured out, well, you know, if we structure things in this way from the services perspective, then here's all the great stuff that we would be able to do. And when I talk to other folks at work and say data modeling or data architecture, they have very similar approaches and ideas. I think that the challenge with understanding what the right thing to do sometimes is that the software engineering organization and frankly, the rest of the company,

is not necessarily coming along with us.

And that's another one of those cultural issues that's pretty challenging to overcome, I think, with pure organizational power. Because you're not having a objective conversation about what is true, what is the case. You're talking more about what should be the case. And that just becomes a debate.

Who can make the best sort logical argument? And if you're not sort of inclined to a debate, if you just want a thing because you want it, it's kind of easy to stonewall that conversation and shut it down. And so the perspective that I try to, that I generally like to take is that at each level, there's sort of like different levels of ⁓ abstraction that make ⁓ challenging conversations much easier to have.

And it makes it way easier to figure out what to do next. So maybe the analogy here is I'm married to my wife and we're living in a neighborhood that's very, very dangerous and we're having an argument about where to go on vacation. And the reason we're having this argument

is because we can only spend about a week away from our home every year. And that's because I have to hire my sister to come over and watch our house for us because I don't trust it alone. I think somebody's going to break in my house. I can't hire my sister multiple times because she has some really important job. And so we're having this argument about where to go, and we're disagreeing. However, if I lived in a safe neighborhood, if I had a security system,

If I wasn't worried about my house being robbed, then it means I also wouldn't be worried about having to hire my sister to come in and house it for me. And then this conversation about where we go ⁓ on vacation gets a lot easier. So the underlying kind of

⁓ model, like the problems that we're dealing with, actually determine how difficult it is to resolve some form of disagreement. And I think if we don't have clear answers on what is the source of our data, what does it objectively mean? There's sort of the downstream transformations in the analytics, which is like, what should it mean? How do we kind of combine these things together into some interesting insight? We don't even have the first answer to that question, which is like, what actually is this stuff?

We don't have clear ownership over it. And because we don't have any of those things, then we've got a lot of folks who have made assumptions about what that data is that are wrong. And we haven't even begun to have the conversation on, well, who is just incorrect about their assumption of what the data is actually doing? And then once you get through that, then I think at each layer, there's a new level of conversation that basically unlocks for you because it's become 10 times easier.

I do think that metrics repositories and things like that are coming in the future. I think they will really simplify those conversations and it will allow folks to have different definitions of similar metrics. ⁓ But I think it's just really, really hard to do that if your foundations aren't in place.

Rui (33:14)
So would you say that the foundational data pieces for entity, let's say a concept of like, how do you even define this as a customer to us, right? Where this is a transaction, where does it begin, where does it end? These fundamental, almost like factual pieces of information needs to have the single source of truth. ⁓ Somebody needs to really take a look at the business model.

And then basically just say, this is how we define a transaction. Regardless whether you are a finance or this work or that work, you are going to follow this definition. let's say if you want to calculate metrics, which is further transformation on top of this factual piece of information, obviously do whatever you want. Am I capturing what?

Chad (34:04)
You are. Yeah, yeah, that's exactly it. We need to start with objectivity before we get into the conversation around subjectivity. What is the world? We have systems that are collecting data. What is actually happening with those systems? What are the decisions that we've already made and that our data producers are oftentimes aware of, but that isn't really fully understood or known by

Rui (34:04)
You're trying to, yeah, okay.

Chad (34:33)
the broader organization, right? once you have your sort of description of the world, like here is sort of objectivity, now we can start to have the subjective conversation, which is, well, what should we do with this information? Are we representing this data in the way that is

that is accurate. My belief is that if we kind of started from the foundations and started from the objective truth of like, this is what this data actually is,

and what it really means, and here's the four ways that it's being used, which of those is sort of most correct and which of those is least correct, then we can start having some real conversation like grounded in fact.

Rui (35:13)
⁓ But the challenging that I'm thinking about is that trying to define the so-called factual pieces of information has so many layers of nuance, right? Like you can break any concept or any person or anything in this world down to atoms, but you have sub-atom level particles, right? ⁓ What is the granularity?

of those concepts and how do you draw the boundary between those concepts become actually quite subjective as well once again. So that's one thing that I've been thinking about. Another part is as the organization, as your product, as your business changes, the foundational concept might also need to shift and change as well, like, and how do we deal with those changes? So those are the two a little bit more nuanced parts that I don't know quite how to think about it.

Chad (36:08)
Yeah, I mean, I think that these are both really hard questions. And one sort of factor in this is time. If it takes you a very long time, I think it's time and the cost of ⁓ managing that sort of descriptive initiative. If it's really, really hard to do the describing at any level, and it takes a tremendously long time, then the problems that you just listed will sort of come to the forefront. If it's really hard,

then it means I'm only going to be able to get to a certain level of granularity. I'm not going to have full visibility of what this is. And so therefore, I may not even trust the output. Any decision is flawed because I'm simply not making a decision with the most useful information. And then if it takes a really, really long time, then the business might change out from underneath me. And if that happens, then the exercise also has relatively low utility. And so this is why I think that ultimately,

It is the responsibility of a system. So what I compare it to is a library. there's sort two problems. The first problem is, ⁓ or the problem that we all care about is, do we have the representative books in the library that our customers want to read? Are we choosing the right things? Have we selected the right categories?

That's sort of like a what should I do question. But in order to answer that question, you first have to answer the question of, well, what do we have? If I don't know what we have, it's really hard to make a decision on, well, what should I do next? And if my approach is to go into this massive library, let's say it's 100,000 books or something like that, and I go one by one, and I count every book, and I read it, and I read the intro,

That's not great, because A, I'm not really getting a true understanding of what each individual book is. That's the first part of the problem I mentioned. And then the other problem is it's going to take me an unbelievably long amount of time. And by the time I sort of get to the end of those 100,000 books, there's probably been a lot more that have been added or changed around or things that people have requested and on and on.

If I pressed a button and I knew instantly all 100,000 books, here's what they are, I knew categorical information about all of them, I had context on every single book, I had information about the author, and that was sort of broken down for me in an interesting way that I could actually start to reasonably talk about. It's like, oh, okay, we've got 10,000 books that are fantasy, we've got 20,000 that are in...

this, can sort subdivide that and As soon as you get to like that level of speed and insight, I think it makes the problem much more tangible. But if you have no visibility or limited visibility, it just becomes an insurmountable task that really goes nowhere.

Rui (38:55)
So what I'm taking away from here is that even if the description of that factual piece of information isn't precise and potentially it will never get as precise as it probably could be, ⁓ maybe the most important thing is to just define it in the most reasonable way at that point in time and just move forward with it. And so that you can start cataloging and having a good understanding.

And then if in the future something changes and you want to say, let's say, for example, the category of fantasy and you want to separate out I don't know, some type of like Renaissance fantasy or something like futuristic fantasy. And that's the subcategory you want to keep breaking down. That's fine. But the most important thing is like, just have a reasonable description for even like what a fantasy is as a category would be

Chad (39:46)
Right.

Rui (39:49)
more important than getting nailing down every single last bit of what it is, right?

Chad (39:57)
I think as exactly you're implying, know, going through this sort of cataloging ⁓ effort is immense,

I think the approach that you just said is really what you have to do. Like, what is our information? What are the categories? What do we mean when we say this particular category of information? What sort of facts is it rooted in?

I think you just need to start there before figuring out what to do next. And the last thing I'll say on this bit is

Going back to the point I made a while ago on, I think data folks, myself included, sort of want the ideal state of the world. My view on this has evolved over years to basically become what you actually have to do is assume you're at the start of a long race, right? Because data is in a bad place in most companies right now. And we can't jump to the end.

And the end is sort of a perfectly modeled world where everything has ownership and everyone is doing the right thing all the time. And instead, we have to start from the beginning of the race and say, what's sort of the simplest first step that gets me on the path to the goal that I want? And what I found is that is engineering ownership. It's engineering ownership accountability. That's sort of the key that unlocks everything. If I can get a software engineer to say,

I own this data. I own this output. That allows all the other conversations to start to happen. It's like, OK, well, you own this output. So what should it be? But if they don't own the output, then you can't get to the what should it be question. You just kind of get stonewalled there. And so if you start from first principles then, then the real question is, well, how can I get the engineer to own something, to own anything?

Right? And what goes into that? And it turns out that is not a trivial problem. Right? That's actually a very non-trivial problem, just to get to step one.

Rui (41:57)
Yeah.

How do you continuously justify the value of your product? Would customers ask, why pay for this if nothing seems broken? So this is just a classic problem for invisible products. And should the pricing scale with the data service area, how do we think about that?

Chad (42:20)
Yeah, yeah, that's a great question and it's a hard one, right? If everything is going right, then nobody notices you and then what is your utility? And I think there's sort two answers to that. The first answer is either things have to be going wrong so frequently that the likelihood of the spigot of disaster ever turning off is basically zero.

So a good example of this is Datadog. There really is not ever going to be a world without errors. If we get to an error-prone world, maybe with AI or something like that, then sure, it's going to be hard to justify the ROI of these tools. But humans are people, and they make mistakes. And we see that all the time. And that's why Datadog is charging Coinbase $60 million a year or whatever it is, is because there's so much surface area and there's so many potential

errors that could be made and those errors are so painful. The other side of it is the problem maybe a little bit less frequent, but it's so big and it's so painful if it does happen that you have to be extra vigilant. And the sort of analogy here is insurance.

Right? Where, yeah, you don't sort of use insurance all the time. But you need to buy insurance, because if you really need it and you don't have it, it's a huge deal. It's super problematic and scary. ⁓ And I think Gable and just this problem in general can fall into both categories. ⁓

If you are a company that's making a tremendous amount of changes to your software, which most companies are, I think you introduce the risk of outages and problems, right? Like any time you change something that ultimately is affecting an output is another opportunity for a thing to go wrong. Now I think most organizations don't actually realize how many things are going wrong as a result of their output being incorrect.

What we've heard talking to companies is that it can be as high as 80 % of the failures fall into this category. But because there's nothing to measure these things, all you're doing is observing that a thing has failed and then tracing it back to its source. ⁓ Then you don't have that clear numerical breakdown that you might get for observability that's been around for a very long time.

my sort of longer term view of this stuff is that there is even greater utility in adding value than there is in saving time, saving costs.

And I think that a system like this, especially in the age of AI that we're moving into, could absolutely start to make money. If you have a very good understanding of your code and where your data is going and who's using it and how it's being used, what you're doing is you're enabling potential artificial intelligence and agentic systems to grok your code base. Right? And that's not really something that exists today. Like most AI engineers...

⁓ AI in the sense of like the agents are limited to a relatively small Contextual understanding like if you're in ⁓ a I still in fact I just got done talking to someone from anthropic recently where this is a big problem right like if you're if you're sort of Making the agent having the agent do some minor code change very scoped very limited Within a single service or a small code base. It does great, but if you're asking it to build something big

that maybe has a lot of potential implications with other systems. Like, hey, I want you to build a brand new payment service because our old one is 20 years old and I want you to use TypeScript and I want you to use all the modern stuff. The AI doesn't understand all the implications of that and all the different places where the data is going and how other systems hook into it and what it has to produce in order to fulfill the needs of the existing service.

And a system that can actually understand the data flow becomes the backbone of software like that. So I think that's the world that we're moving to, where in order for these LLMs to really do powerful things, they actually need the context of the entire system. And the only way to get the context of the entire system is to build the map that describes it. And that's a pretty separate problem.

Rui (46:52)
this. I and I agree with you. And I think the way that I see it is that the data contract and all the context that comes with it will serve as the foundation for further AI evolution. As I'm talking about this, what I'm thinking is actually another startup called Delfina. ⁓ They're trying to create, at least the last time that I checked, ⁓ they're trying to agentic data scientist.

Chad (47:12)
Mm.

Rui (47:20)
⁓ data scientists spend a lot of time doing future engineering, trying to engineer all of those signals. If you have the right data contract, even just by simple combination or ⁓ variation, you can just quickly spin up

hundreds of different features in one go and then you can trust your data quality right away, right? And your data scientist agent, they don't have to go and understand all the, you know, gotchas and then clean all of the little pieces. Instead, they can just focus on, what are the potentially interesting combinations that I can try

there are so many other ways to, for this to become a value generator, right? Like when you onboard a new hire, what are the different payment concepts that you need to learn? It's embedded in the data contract. Potentially your onboarding plan is about, okay, here is the canonical 50 concepts in the company. Go learn all of them in your first one month of onboarding.

the use case where the way that you can think about it is just limitless. Because you are servicing the most foundational business concepts to all the people around and building a shared understanding and reduce the communication cost to me, especially for a huge corporation. I think that is a huge, huge win.

Another thing that I want to chat a little bit about is

At this stage, you feel like building tooling is harder or getting people to actually use them is a little bit harder? I think intuitively the answer might be, it's people, know, people change and culture change, mindset shift ⁓ is difficult. But even just building the tooling itself, I think there are probably a lot of nuance that you're encountering ⁓ that might actually also end up becoming challenging

So I want to understand that a little bit more.

Chad (49:25)
Yeah, I think it's another great question. So in fact, I was just talking about this with my team the other day, a zero to one problem.

And generally, people use these terms when they talk about product development. So they'll say, hey, I'm a 1 to 100 sort of guy. You bring in a product that already exists. You have customers. And the question is, how do we switch over to growth and focus on scaling that to many teams and getting our onboarding right and reaching new markets and so on and so forth, whereas 0 to 1 is more about creating something from nothing.

I think this applies to more than just product development. It also applies to the actual problems, the types of problems that you're trying to solve themselves. So a one to 100 problem I sort of define as being the business has already recognized the issue internally and has already taken steps to resolve it and more or less knows the solution.

However, that solution might be not very efficient or low quality or requires a lot of maintenance. Like, hey, we like A-B testing and we all acknowledge that A-B testing is really important. And so we decided to go and build our own A-B testing tool. But that requires like six or seven people to run and we've got some engineers who work on it and some UX designers who work on it and that's really costly.

And now there's a lot of needs that our data scientists have and our analysts have. And frankly, we simply don't have the resourcing to meet all of those needs, right? Because it's just a very quickly, rapidly evolving space. And so I might go out and then find a product that does all the things that I need my product to do. But instead of being a one, it's a 100, right? So that's kind of one side of it.

And the other side of it is like a zero to one sort of problem where the problem is so difficult to solve. It's so hard that work on the problem to even conceptualize the solution hasn't been done yet. And so people can't even yet imagine what the cultural change is going to be or what the process change is going to be. We're sort of stuck at like, it's still hard for me even to conceptualize.

that you can solve this thing. And so what I find in those cases is that most companies do not expect that we are going to change the culture as our first stop. They're not expecting that. That's ultimately what we do. That's the goal of a tool like Able is to change data culture. But they're not expecting that. What they say is, I just want you to technically prove you can do this.

And if you can do that, I will buy your product. And then I will take it on myself and you guys to then let's go in and see if we can change the culture using this tool. so what that basically has meant for us is actually the biggest barrier, maybe surprisingly, is the technology. Can you build technology that is sophisticated enough that solves this problem in a way that creates a believer of

the people who have the issue. And if you can do that, then the cultural conversations actually become not that hard. ⁓ It's just that that technical bar is extraordinarily high because they have to see the tool and imagine how running this thing could ultimately lead to the culture problem being solved. ⁓ So yeah, I think, at least for us anyway, it has been more of the technology bar.

Rui (52:45)
Hmm.

Chad (53:12)
But it's of like technology in service of solving the eventual cultural issues.

Rui (53:18)
I see. And where do you think that on the scale of 0 to 1 problem, where are you at if you have to do a self-assessment for how far you're away from the 1?

Chad (53:28)
Oh yeah, I I think that we're not far away from the one. At least in the ability to show that there is a one and that sort of delivering upon the one is possible. So a company like Glassdoor, for example, we've been rolled out to thousands of engineers. Almost every engineer at Glassdoor is sort of using Gable at this point.

That wasn't something that was an executive order. I mean, it became an executive order, but it started with the engineering team saying, this is going to be super high utility to us. We have other use cases we're working on right now with really big banks. And those are also the engineers from those big banks coming in and saying, we could use this ourselves in order to do something useful. And what's amazing,

is that the data teams are always our biggest fans. We love data teams and they love us because we're solving a problem for them. But they don't oftentimes even realize what Gable can actually do for the engineering teams. They believe that they need to come in and be the champion for Gable and advocate and drive it and implement it and everything else. And what we like to say is, no, no, no, you actually don't have to do that. Yes, we need you as a champion. Yes, we need you sort of

Rui (54:24)
You

Chad (54:47)
explaining why this is important. But once we get this into the hands of the developer, you're not going to have to worry about it. It's just going to get adopted. And I think that's just so different from every other data tool that most data teams have worked with, that it doesn't seem real. It doesn't seem like a real thing that can happen, because no other data tool is like that. And so they just oftentimes don't believe us.

And that can be a big challenge. We're like, dude, if you put us in front of these developers, I'm telling you, they're going to get really excited about it. And it's oftentimes like, yeah, I just don't really believe you. Like, I'll do it. But I think I'm going to have to drive this stuff myself. So it's hilarious that one of the bigger gates to us isn't actually the engineers. It's actually the data people not believing that the engineers are going to adopt the tool.

Rui (55:39)
Fascinating. And also related to the zero to one problem, there are some open source potential solutions out there. I can also imagine data companies, I don't know, like Databricks, right? Like they could build a tooling or feature like data contract and baked into their platform or their offering. Why do you think that you would have the edge?

Chad (56:05)
Yeah, well, I I think the biggest edge is that we don't actually consider ourselves a data tool, and we don't really consider ourselves a part of the modern data stack, which is essentially vendors and data companies that are building on top of products like Snowflake and Databricks and other analytical databases. And the reason we don't consider ourselves sort of a part of this collection is because we don't require

any connection to the downstream system to add utility. And in fact, right now in all of our implementations, don't even, our product doesn't even know that these downstream tools exist at all. We exist solely in the upstream, in the space of upstream engineers. And why it's important to apply these contracts there.

is because yes, you can certainly apply a contract on a downstream system. You can say, if I see data coming through that doesn't match my expectation, I want to move it somewhere and I want to do something with it. And that's great. And it certainly does have, that does certainly drive quality. And it means that you're not immediately going to be broken. But if the analogy is ⁓ I'm sitting on an assembly line and there's a machine and the machine is producing a product and I always expect that product to have a certain quality,

All you're doing in that case is sort of moving the check to see if the product is defective or not earlier on the assembly line versus after it reaches the customer. It's a lot better to do the check there, absolutely. But you're still putting the onus onto the data team to identify the defect, try to figure out what it is, and then open up the product with a screwdriver and fix what's going on before putting it back on the assembly line.

And that is the fundamentally unscalable issue. And whether your data breaks or snowflake applying data contracts on your downstream systems, that would still be the end result. The only true solution to the problem is ownership. It has to be ownership from the source. And a software engineer simply is not going to own a data contract on a downstream system. They will never own that. They don't think in terms of tables and columns and fields and

data quality tests and things like that, they think in terms of code. That's their workflow. And they will want to own something in their application code. And so the contract, if you want it to be adopted by the developer, which is the primary problem in my opinion, it has to exist on the code. And if it has to exist on the code, then you also run into the issue of like, it has to be easy to own. And in easy to own means,

Can you automatically say a contract should go onto the output of this particular system? So how do you do that in a holistic way, in an automated way, in a low effort way that an engineer will actually adopt? Well, you would basically have to build the Gable product, like one for one. You would just have to build our software. And we don't believe that the Databricks is in the snowflakes of the world are going to do that because it's a very different type of company.

Rui (59:20)
What about open source teams where like internal teams

Chad (59:26)
Yeah, open source has been around for a very, very long time and it has not solved ⁓ core technology issues that are essential to this problem. Low level technology issues that have existed in 30 years for security. Open source is still not.

not solved it. For example, doing semantic analysis, having a semantic analysis layer where you're essentially inferring ⁓ contextual meaning from building a contextual map of your code, ⁓ everyone has known that this is an essential thing to do in code analysis engines. And there has never been a single open source implementation of that.

And the reason why is that it requires, A, it's a lot of work. And so the question is, why would someone do all of that work for anything other than a commercial output? That's sort of number one. Anyone that's sort of done the amount of work is doing it to make some money. Because it takes years to get to a single implementation. It's not like I can iterate my way there. I have to spend maybe two years sort of working on this. And then the other problem with it is that these things are always extraordinarily opinionated.

So any sort of contextual layer that you build is going to be very strongly opinionated to your specific scenario and your specific solution. And so it hasn't emerged. It just requires too much coordination, too many people sitting in a room trying to figure out the right thing to do, and these products drag on and on and on. And they never actually make it into an open source setting.

And it's why you don't really find these end-to-end code parsers. You can find components of it every now and then, but it's very, very hard to find the end-to-end piece. The other thing I would say is that it's a multi-step. The technology is very multi-step. So it's not just that you need to have a compiler front end, or you need to have a static analysis engine. You also need to have a machine learning component.

And you also need to have a component around workflow and data contracts. ⁓ And so building all of these different components, building everything together in a way that works for an enterprise, it's a very, large endeavor. It's less like building software, and it's more like building an airplane, where it's just a huge technological investment.

And you just don't see too many open source airplanes. It's a very hard thing to open source, although that might be for a slightly different reason. And so this is sort of where our sort of view on this is that if someone's going to come into this space and try to solve this problem, Gable has basically a three year head start. ⁓ It's going to take about three years of research.

to even understand how to solve it. And it's going to require a very specific set of skill sets and backgrounds.

Rui (1:02:38)
Interesting. the last question that I will ask around this whole gable piece actually is Have you considered partnering up with GitHub?

and the offering as a product feature there to directly insert your solution. And that will immediately get potentially looked at and adopted across different companies.

Chad (1:03:01)
Yeah, I mean, think a GitHub partnership is definitely something that is ⁓ interesting and possible. We are not focused on partnerships right now. There's still so much core technology to build. There's still so much, I think, value ⁓ left to prove, both to prove to ourselves as a company and to prove to the broader market. The way that I'm sort of thinking about this is we want to...

make sure that we've got really incredible foundational technology. We want that to work at really any scale for any language. We want to have demonstrable proof that we're significantly and radically changing culture at some of the biggest businesses and enterprises in the world. And we want to demonstrate a layered offering where we're not going to market with a single solution and just

charging customers for usage, which I think is a model that's probably going away. And instead, being able to say, we have a variety of SKUs. Like, there are product lines here. And each product line can be layered on top of the Gable and adds an enormous amount of additional value, and in fact, multiplicative value. That's the place that we want to be. And when I think we can demonstrate that, then there's a huge number of partnership opportunities that start to open up as we want to expand.

our reach. But we're just not quite there yet.

Rui (1:04:26)
Interesting. I see. ⁓ Maybe let's talk a little bit about your ⁓ life outside of Gable.

Chad (1:04:26)
That's right.

Rui (1:04:34)
and especially your previous journey as a journalist, and also your time spending training martial arts in Asia how does the journalism training helped you ⁓ in starting this company? How have the dots connected for you?

Chad (1:04:52)
Yeah, well, I mean, I think the interesting thing in journalism, like journalism is not as different from data as you might believe. Like there's a lot of the sort of core components. ⁓ Like if you're a journalist, you need to do a lot of investigation, a lot of investigatory work. ⁓ You start with a hypothesis. You need to collect evidence. You need to collect data.

You can get data from a variety of different sources. Some of those sources are ⁓ qualitative. Some of those sources are quantitative. ⁓ You are going to need to very strongly test your assumptions. And then when you start ⁓ composing your ideas, you treat it a bit like a research paper, where you're citing your evidence. You are describing what data informs this particular opinion.

You're trying to distinguish from the factual and the non-factual. And then you're doing an analysis at the end of the day. So I gravitated towards data because I saw a lot of that work. That was always the part that I enjoyed the most, frankly, from journalism is doing that investigatory work. And I saw that when I was in data and I was an analyst as well. So was like, this is the same stuff. It's just that instead of interrogating people,

Now I'm interrogating systems and I'm interrogating spreadsheets and stuff like that. And there also still is lot of interrogation of people as well. ⁓ That part didn't actually go away. And I think that's probably the other large component is journalism is at its heart, it's all about the human beings. It's like you need to figure, if you want to talk to a person, it's oftentimes not enough to just send them a cold email and say, talk to me about a thing.

Rui (1:06:27)
You

Chad (1:06:48)
You have to give them something useful, something that's valuable to them. You have to share information, or you have to make them feel good, or you have to go on a walk with them because no one has asked them to do that, or drive two hours to their house to sit down and you bring them food. There's all sorts of things like this that's all about just creating value through a human connection in order to get a story. And then I guess the last piece that I really

sort of I saw ⁓ represented in data is that it's not about a trying to, ⁓ it's not about, at least if you're a good journalist, right? It's not about trying to push through a very specific opinion. It's about trying to uncover the facts that give you ⁓ a narrative, but the narrative should be as rooted in objectivity as you can, right? You're sort of trying to tell the story

as it exists and help other people understand what happened. And different people may have conflicting opinions, and it's your job to synthesize all that together. And that was basically my work as an analyst, more or less those three things, interrogating data, extracting information, ⁓ the human connection, ⁓ having conversations with people to understand what data meant and why they collected it and where they got it from.

And then the actual narrative and storytelling component of it and trying to ensure it was objective and fact-based and useful ⁓ as it could possibly be. And so I saw a lot of similarities there. And the only thing that was missing for me is I didn't have the technical skill sets to have those conversations intelligently. ⁓ And so that's sort of what I focused on developing after I stopped being a journalist and I read a bunch of books and I took a bunch of online classes and.

I at least just got to the point where I could write enough code to know what I was doing and not look like a fool and have a conversation about this stuff without being totally out of my depth and it just sort of went from there.

Rui (1:09:00)
Interesting. And what about the martial art piece? What kind of martial arts did you practice? And did you actually go to Asia and then train there?

Chad (1:09:14)
So I've been in martial arts since I was a kid, since I was a little kid. I think I started when I was something like ⁓ seven years old, eight years old. Originally it was Taekwondo because I was getting bullied in school and my dad didn't want me to rely on having the teachers come and defend me and I needed to be able to defend myself.

So I started in Taekwondo and then my father is like ⁓ hyper competitive. And so he's a track coach and he's sort of, ⁓ you know, he was reasonably famous as a coach in his day. He coached some national champions. And so he wanted me to compete and I started competing in martial arts. And I got reasonably good at that in Taekwondo and in karate.

And then I just started expanding out sort of horizontally and I did a little kickboxing, I did a little Muay Thai and that's when I ended up going to Thailand. So I was a writer, I had this journalist background and I had this martial arts background. I loved talking to people and I thought that the martial arts as an industry was just fascinating and I thought it was full of weird, wacky characters with interesting stories. And I wanted to figure out how I could get over there to write about that space. And so I applied to a job.

at a gym, a Muay Thai gym in Phuket, Thailand. I got the job and I was super excited and then about two weeks before I was gonna fly over there, I already bought my ticket. I basically had around $200 to my name and I spent 500 bucks on the ticket. They told me it was canceled and so I went onto Twitter and I asked every single journalist that I knew who lived in Thailand if they had any opportunity for me and I would work for free.

as long as I had a place to stay. And I found someone who said, yeah, like come on out. You can stay on the same flight. We're also in Phuket. And yeah, it put me up in a place to stay and I worked for free. And I wrote for about a year in Thailand before I moved on to do the next thing.

I think that I basically learned people in this field are crazy They are certainly out of their minds ⁓ and I say that as being someone in that field, you know But like I you do have to be a certain type of person to be a to be a fighter ⁓ to enjoy getting beaten up and and beating up ⁓ other people and to and it doesn't pay very well, right like it's not

Rui (1:11:22)
You

Chad (1:11:42)
It is not a sport that will ever make you wealthy unless you're at the, you know, you're in the top 1%, maybe even the top, you know, 10th of a percent. ⁓ So you're not gonna get rich off of it. So most people are really just doing it ⁓ because they love it, because it's who they are. And that just brings out a lot of wacky, zany, kooky characters.

It's ultimately why I decided to move on from it is because the people, the personalities were unpredictable. Whereas in tech, are not like that. You know, people care about your health insurance and they... ⁓

You know, they don't just randomly scream at you most of the time. And they're not on drugs when they come into the office most of the time. ⁓ Maybe sometimes they are, but yeah. that was a very interesting time in my life. I had a lot of fun, ⁓ usually. But it was also like super, super unpredictable. there's not really a great, ⁓ there's not sort of clear upward trajectory.

And that just sort of danger to me.

Rui (1:13:01)
Yeah, that makes sense. what's imprinted in you throughout those years of training? Like what is one thing that you felt like, ⁓ my God, this thing really shaped who I am today.

Chad (1:13:13)
Yeah, that's a great question. I think frankly the biggest thing was it probably revolved around the work ethic and the grit and the sort of grind of things. When I was over there, my goal was, if I go home, if I go back to the US.

I want it to be because I accomplished all the things that I wanted to do. I don't want it to be because I failed. That would be tough. ⁓ I just personally didn't want that. It was a goal of mine. And there were times where it was extremely difficult. And I really, really, really wanted to go home. ⁓ But I didn't. And by the time I kind of ended my time over there, I sort of looked back on

the five or six things that I wanted to do in the beginning and I had accomplished every single one of them. It took me three years, three, four years, ⁓ but I had sort of gotten through my list. And in doing that, I kind of developed a pretty tremendous amount of self-confidence. Like, look, if I can do this, go to a different country, not speak the language, go into a field with no pay,

start from absolutely zero, where all the people are psychopaths, and I can still do every single thing that I've laid out for myself, ⁓ I'm pretty sure that I can do that anywhere. Like in any field, I think I can do it. And so the next question I asked is like, well, okay, well, if that's true, if that's the sort of level of belief I have in myself, then what's the field with the highest opportunity? And that was tech. And I was like, okay, I'm gonna go into tech, I'm gonna learn it.

Rui (1:14:27)
You

Chad (1:14:53)
I did get into the tech field with the intent of building a company, ⁓ mainly for the reason that I mentioned a second ago, which was, essentially asked, what do I think is the greatest, ⁓ the biggest outcome that I could accomplish in my time on earth? And I had a few things in mind, ⁓ but in order to do those things, I felt that I needed

a pretty tremendous amount of capital. And I felt the shortest route to getting a tremendous amount of capital was to have a company

I basically put together about a 20 year plan for sort of the first phase of what I wanted to do.

And I've tried to follow that timeline pretty closely.

I I like the data domain. I think that I know it very well, and because of that, I think it makes it just more likely for me to succeed in an area where data is involved. And so one of the questions that I've kind of been asking myself is, what are ⁓ ways that you could utilize data?

for example, I think that there are ⁓ really meaningful ⁓ transparency issues that you could help with that would make people I believe want to participate more in their government.

Rui (1:16:16)
So this is obviously a broad stroke of description. If I have to use three words to describe, roughly describe the mission with the journey that you're on, is it fair to say that it's truth, transparency, and communication?

Chad (1:16:35)
Yeah,

mean, I think that's exactly it. that, you know, I sort of had, I came up with this sort of stupid analogy when I was 15. And it's something that I've more or less lived by, which is like, it's sort of a, it's similar to the Plato analogy of the cave, right? Where you're in the cave and you see the shadows and they're like really scary and they're sort of demons or whatever.

And then you leave the cave, and as you're leaving, you notice that the shadows are actually just kind of these non-living machinations, like puppets that are actually casting shadows on the wall. And they're not really scary. They're not the demons that are going to eat you. And Plato's point of view is that it ⁓ is moral and it is righteous for the person who has the information ⁓ to go back and help everyone else and sort of ⁓ achieve ⁓

⁓ knowledge equity, right? It's like we all kind of know the same things and then we can use that information in ways that are best for us.

I think you're right. It's like if I can contribute to that mission, then I think I'm doing a good thing. And I'm helping people and helping myself.

Rui (1:17:56)
Yeah, 100%. Thank you so much for everything that you have shared today. it was a great conversation. I really enjoyed it.

Chad (1:18:04)
Thank you, I really enjoyed it too. It was great being here.