---
title: "Why RevOps Shouldn't Have to Beg Engineering for Data"
episode: 58
podcast: "The LeanScale Podcast"
publisher: "LeanScale"
guest: "Ghalib Suleiman"
guest_title: "Co-Founder & CEO, Polytomic"
date_published: 2026-05-15
date_modified: 2026-07-22
duration: 00:30:24
word_count: 5446
topics: ["revenue-operations", "consumption-revenue", "gtm-strategy"]
canonical_url: https://leanscale-knowledge-hub.netlify.app/podcast/ghalib-suleiman-empathy-data-revenue/
source: "LeanScale Podcast Knowledge Hub — https://leanscale-knowledge-hub.netlify.app"
license: "Free to quote and cite with attribution to The LeanScale Podcast."
---

# Why RevOps Shouldn't Have to Beg Engineering for Data — Full Transcript

> Episode 58 of The LeanScale Podcast, with Ghalib Suleiman.
> Published May 15, 2026 · 00:30:24 · 5,446 words.
> Machine-transcribed and **not diarized** — speaker attribution is inferred, so verify
> attribution against the audio before quoting a specific person.
> Structured breakdown: https://leanscale-knowledge-hub.netlify.app/podcast/ghalib-suleiman-empathy-data-revenue/

## 00:00 — Meet Ghalib Suleiman & Polytomic

**[0:00]** Today we have Golub Suleimont, and we are so excited to dive into the Polyatomic platform. It's the ETL and reverse ETL platform that is built specifically for RevOps professionals and data professionals. And he has built a platform that makes it so easy to get the data into the places that you need the data to go to. So Golub, I'm so excited to dive into it today. And I think anytime we have the founder, the best part, I'd love to kick off with the founder story. You have such an interesting background where I feel like you have some deep empathy for the problem. And we'd love to hear how you got kicked off. Sure. Yeah. Pleasure to be here, Anthony.

## 00:43 — Founder story: a decade running data teams

**[0:43]** So I'm Golub, co-founder and CEO of Polyatomic. Beginning with the founder history, my history is 10 plus years working in data. I used to be the guy running data teams who would collaborate with RevOps teams to get them the data they needed. Now back in the day, I'd get a lot of requests to think of your typical SaaS company. You've got data in silos, you've got RevOps in charge of the CRM. Those guys need data. Like for example, our users are locked up in systems controlled by the engineering team. We as a sales team want to maximize upsells and minimize churn. We'd like to monitor usage. For the heavy users, we'd like to engage with them.

**[1:22]** For the light users, we'd like to engage with them as well for different reasons to prevent them from churning. So I was at the crossroads really at the company, but in particular with RevOps and the GTM side of the house on data they needed. It could be billing data. Often it was indeed product data of some kind, user data, which users are using what, who last logged in. A few fields in Salesforce or wherever your CRM is containing this data can go a long, long way. You can then generate reports. Every customer success manager can generate reports in the CRM. Could be Atio, could be HubSpot, could be Salesforce, whatever it is.

**[1:58]** Then they have a view, your full customer 360 as they say, regarding all the product data about that customer, as well as whatever's in the CRM. Now I was the guy sort of played the role of a traffic cop often. This is rather unfortunate and unfortunate admittance I make now, but often I would tell my RevOps counterpart, sorry, we're too busy for you. You're working on sexy data projects, whatever they may be. And your asks are sort of on the mundane and painful side. Thus just wait and they'd go, what do you mean just wait? This is bottom line stuff for the business and I'd go, well, we just don't have time. We're doing other things.

## 02:40 — Why data lives in silos: everything follows the org chart

**[2:40]** You see, we report to the engineering org where we're special. Well, many, many years of this. I ended up at some point realizing, hang on, this is actually a real problem. They remain siloed because the org chart results in teams that are separated with boundaries. Everything follows the org charts. You're never going to have a combined RevOps and engineering team in one. As long as they're distinct teams, you will have silos. And then you have the sales team who often make the decision on what CRM to buy, right? That's sort of another silo. They're hassling RevOps, marketing hassling RevOps, RevOps is hassling us.

## 03:15 — Founding Polytomic to 'pay penance'

**[3:15]** We're now three degrees removed from the company's bottom line as far as impact goes. And so the realization was people are buying different solutions and begging internal teams just to move data around within the company. Well, at some point we thought, let's just start a company, make a platform. It's just the one platform to move data between these systems. An idea often joke, the surreptitious goal for starting a company is me paying penance for all the times I somewhat abandoned by RevOps counterparts who in hindsight was very correct. I'm not very correct about the fact that this was bottom line business, high impact stuff.

**[3:53]** But me, of course, the academic rather underweighted it. In a world where they could have served themselves, I would never have been an obstacle. And so this has really been the goal here. Well as a fellow founder, I don't think there's a better way to give yourself some lashings and pay penance than to start a company and then go solve the problem. Because I know there's plenty of challenges I'm sure you've gone through birthing a company into existence. So I think that's great. And then I love the perspective of that and I actually really like that you were almost on the villain side of the story that like, you know, sui asides a little bit because

**[4:30]** we hear people feel in the pain, but you recognize that you are causing pain in someone else's life. And that's what motivated you to fix it. I love it. Yeah. Well, yeah, exactly. Well, I'm really excited. I know you prepared a demo today to show how easy it is to get data moving because this is not typically an easy thing. Usually you need developer level talent, at least engineering level talent to make this happen. And I think the way you've designed Polyatomic has really just empowered RevOps people to take control, take part in their own hands and make it happen. So excited for you to show how you do us to do it. Sure. Let's get going.

## 05:11 — Demo: connecting sources and building a data model

**[5:11]** Let me show my screen here. Okay. So here is Polyatomic's demo instance. Now we have a blank slate here. However, if I do click on connections, we're connected to all kinds of systems. For this demo, my initial use case will focus on moving product data from our sample product backend into Salesforce. Which is usually one of the most difficult use cases to make happen. For sure. For sure. Especially if you're building it in-house, Salesforce has API limits. It has field quirks, all sorts of things. We just take care of it with clicks. We are connected to a couple of product backend databases here. We'll be grabbing user data from.

**[5:50]** And then if I scroll down amongst our many sample connections here, we also have a connection to Salesforce. Now let's get going with this. The first thing to set up, and it does sound fancy, but it really is not, is one or two data models. Now a data model is simply a list of fields from your sources that you authorize for syncing. For example, let's add model, we'll go to this product backend database. Let's call this model user details. Now I can click here and we see what sort of tables or collections of data are available in our product backend. In our case, I'm very interested in users, we'll click that.

**[6:28]** And then what we return is all the fields behind this collection, just like every Salesforce object has fields, all the collections on your product backend have fields as well. In this case, we've got a few named fields for users, email, first name, and so on. For every field we'll show you the robots person, the example value behind that field. So you can see the shape of your data without even asking your engineering team. We'll just surface an example value for each. Your leftmost column is your actionable one. This is a true false column that decides what fields are surfaced in a data model. In other words, your green lighting fields.

## 07:07 — Green-lighting fields and creating a Salesforce sync

**[7:07]** I am green lighting these fields and allowing them, I'm declaring them to be allowed to be synced to other systems, right? So it's an authorization process. In this case, I'll actually select all here in the user's collection from our product, hit save. And we have a data model here, meaning a mini catalog of fields we can now sync anywhere, CRMs, finance systems, support systems, likes and desks, spreadsheets. It's a catalog available to be grabbed from. We'll now go to model syncs and actually finish the initial run of this demo. And we'll create a sync into, pick our destination to be Salesforce.

**[7:43]** All target objects are available as options, including custom ones. We'll show them all automatically. But since we're moving user data, let's go into contacts. Really then it's on you to pick a sync mode. Now you've got a few options here, updates or create meaning. We will update any matching records within Salesforce. We'll also create records that don't match from a product. Update only mode is where we'll just update matching records, but not create any new ones. Create mode, well, it's creating only, no updating any matching records. And one has to be careful, but we do allow you to delete stuff if you need some mass cleanup.

## 08:26 — Identity mapping and field mappings

**[8:26]** Most commonly people will pick option number one. They want records both created and constantly updated. The first thing to pick with any sync to CRM is what we call identity mapping. So on the left hand side, it's this data model that we've just surfaced before in its fields. On the right hand side, it's a Salesforce contact fields. Now this identity mapping is really any kind of unique field on both sides, some kind of unique ID. You can use whatever you want. And for users, you will have a custom user ID that's unique. For the sake of this demo, I'll use email, but just realize you can do whatever you want.

**[9:04]** Once I select identity mapping between the two, in this case, email from product will map to email on the Salesforce contact. Now it's just a case of field mappings. I can grab first name from our users table in the product map to first name in Salesforce. If you look up here, our Salesforce requires last name on contacts. And so this is actually a Salesforce validation rule, but we are propagating to you the user. And you can see, oh, hang on, my Salesforce requires last name to not be empty on contacts. Fine. Let's map last name as well into last name on contacts. And I could go on, but I do think the audience gets the point.

## 09:40 — Filters, overrides, and Salesforce validation rules

**[9:40]** It's really a field mapping exercise from whatever your data sets are. And so we can dismiss this and move on. You can even set some point and click filters here. B2B companies often do this where, for example, they only want to sync users where say email, let's say, does not end with gmail.com, right? Now in this case, often, especially if you have some sort of PLG or self-serve motion, as they call it, right, you may have all sorts of random signups and you may care about only moving ones that are under the guise of corporate domains into your CRMs, right? You may want to exclude gmail.com.

**[10:24]** We do offer a full list of filtering abilities for text, other ones for numbers and other ones for dates as well. We'll show you the right sets automatically based on your field. Otherwise, overrides is a minor feature, but there are a lot of crowds. Sometimes it's quite thankful for it when they do use it. This is where you could do some quick substitutions. If you remember how our Salesforce requires last name, well, suppose people have signed up to your product and have not provided the last name, but your Salesforce requires it, what do you do? Are you out of luck? Not quite. You can use overrides to set text substitution rules.

## 10:59 — Scheduling and change-only syncing

**[10:59]** And so, for example, I can say, well, if last name is empty, I'll replace that emptiness with the literal text M/A. This means it's now not empty. I can get past Salesforce's blockage, and then maybe I have some other process in Salesforce to update these guys later on or deal with them later on. So overrides, again, can be quite handy. Just text substitution rules on the way to your destination. Otherwise, you really just hit continue, and this is the last step. You set a schedule. Now, manual just means someone needs to click a button every time you want to update sent.

**[11:35]** Continuous, the guarantee here is we'll run every five minutes and no later than that. Otherwise, you have more structured options, hourly, daily, weekly, and so on. I'll set this to run hourly, say, at 30 minutes on the hour. You hit continue. That's really it, verify your summary of your sync and their settings, and you can leave a note. Let's call this user signups sync to Salesforce. Just a descriptive note for you and your team about what the sync is doing. And note, one piece of magic about Polyatomic is we automatically detect what's changed in the source and only move that.

**[12:14]** For those who are squeamish as you should be about API consumption when it comes to your CRM's daily API limit, whether Salesforce or otherwise, note, Polyatomic is rather clever. Not only do we use the right APIs to minimize that, but we only ever move changes, new records or updated records. And so we're not doing the dumb thing of just syncing everything every time and consuming resources from your CRM's allocation. Otherwise, going back to this, you hit save. Well, here we have a sync created going into Salesforce. One can run a test sync, which would sync five random records for testing's sakes. Or instead, I'll just enable this guy.

## 12:54 — History, logs, and error handling

**[12:54]** And instead of waiting for the first scheduled run, I'll just click sync now, just to force it to get going. Click sync now. We've got a sync currently starting up and running. As this goes, a couple more tabs to cover. We've got a history tab. So you get full audit abilities on everything that's currently running. And then anything that's completed gets recorded down here in the completed table, where you'll get logs for what was inserted, updated, any errors and so on. And then under error handling, we can toss in any number of email addresses or Slack channels in the subscriber list, and we'll automatically notify everything on this list if anything

## 13:33 — Data models as a catalog + custom SQL

**[13:33]** fails. But really, at this point, for this particular example, this was a setup from scratch. You walk away at this point, and anything that changes on the left-hand side will move to the right-hand side. Now, going back to these data models, this really becomes your central catalog for you to specify what's available to sync from. For those who are more sophisticated, maybe you know custom SQL, you can actually generate these data models through custom SQL. We can go to this SQL source here. And often, for example, in this day and age of API token consumption, a lot of billing models are maintained by engineering teams.

**[14:13]** Here you can hook into the database. Let's call this billing info, for example. And you can switch from table select mode to SQL query mode. Now, some of our customers have the complete works of Shakespeare and SQL form. We won't bother you with that, but I'll have a very dumb query here just to illustrate the fact that you can write SQL. You can actually write anything you want, complex joints, aggregations, as you see fit. You hit continue, and it's the exact same flow. You can back fields, examine them, choose which ones you want to authorize for syncing. In this case, I'll select all again, hit save, and now you've got another catalog you can

**[14:50]** move data from. This is a heterogeneous control plane, if you will, or can connect your heterogeneous systems. You know, I can go to whatever. I can make a data model of NetSuite, or I believe I've got a Google Sheet here, for example. Of course, people will use Google Sheets often. Let's go to the one tab on the sheet. And here I've got city, country, and state, for example, as example fields. I can hit save. And now I've stitched together, well, we've got a catalog containing data from three different places here that we can sync anywhere. So one could go on, but this is the core concept.

## 15:28 — Embedded query runner and SOQL

**[15:28]** Anyone can now jump in here, grab whatever fields they want, and sync them to every system. And this really concludes it. For the Salesforce card in particular, I will mention one more thing. This can be quite neat. We have an embedded query runner tab. Now, this lets you run arbitrary SQL queries against any SQL databases we're connected to. Run a query, preview some data, maybe make a model by clicking here. For the Salesforce crowd, you can connect directly to Salesforce and run SOQL queries directly against Salesforce. This can be quite powerful, both as data exploration and as an alternative to rollup helper and so on.

**[16:10]** You can make a complex SOQL model, create this model, and then sync it back to any Salesforce fields. This has been quite powerful indeed, but it's really the same method. You hit create model. We then create a model here, pick the fields you want to authorize for moving, hit save, and you're off to the races. This really covers it. This is the full setup from scratch. You can see the sync here just completed. If we go to history here, you'll notice we have a log that we can click on. I can click on what was updated, which was all 100 or updates. Even within the logs, I can click on any of these IDs and jump straight into the record in Salesforce.

## 16:50 — Five minutes to product data in Salesforce

**[16:50]** Or, again, if you're using Atio, HubSpot, and so on, you get links directly in there. Really, as a Revolx person, you have complete control of the situation as well as its results. This basically concludes the demo here. I really love how simple, yet powerful and enabling it is and empowering forward the RevOps professional, often tasked with getting, I think, two of the main ones, getting product data and billing data into the CRM, whether it is Salesforce, HubSpot, wherever it is. I think the way you've designed it just really gives them the tools to be able to do that. Now, it's clocking how long it took you. It was five minutes.

## 17:33 — Heavy-hitting use case: product data and churn

**[17:33]** Five minutes to build the model, sync it, and so in five minutes, you have product data into Salesforce, which is normally, I'd say, a few week-long engineering projects and red tape to go through to make happen. I think that's just absolutely credible. From your perspective, because you're dealing with these use cases all the time, what tend to be some of the heavy-hitting use cases that everybody's having a tough time with, where polyatomic just handles the bread and butter. Yeah. As far as the sales CRM goes, the two big ones are product data and let's call it billing data or the buckets of finance data.

**[18:17]** For product data, realize all data about who has signed up to your product, who's using it, and in what capacity is sitting in a database locked up by your engineering team. Could be your data team, could be your engineering team, but it's certainly not the GTM side of the house that controls that data. No. Now, I certainly care about this regarding our sales team. We and everyone else cares about minimizing churn and maximizing upsells. These are your two, and of course, acquiring new customers, right, but that's a very definition of sales. But then beyond that, we all also care about minimizing churn and maximizing upsell.

## 18:57 — Last login as the churn predictor

**[18:57]** The biggest indicator of churn, there are many data points about do they use your product, do they not. If you simply begin with the last login date into your platform, that ends up being extremely telling as to who is lucklier to churn than not. I remember running this analysis back when I was running data teams, and we tried all these sophisticated signals, right, products that they've done this and the product, they've done that and the product, realized, hang on, if we just look at last login dates, that correlates so very well with the likelihoods or the lack of it of churn.

**[19:29]** So even just beginning there, right, if you simply want that data point, that setting in a database locked up by the engineering or data teams, you can get sophisticated based on your product. You know, could be, if you're, for example, some sort of AI platform, you are probably looking at who has instigated agent actions, for example. Maybe you're running some agents, or you're offering some sales agents that your customers can use. If people haven't put the agents to work, then they're not using the product, then they're at churn risk, right? So the premise is you have this data in there. You've got your users in there.

**[20:06]** You now can organize who you reach out to and why. You marry that with product usage data. You can now segment your users as reports in your CRM, assign them to each of your customer success managers, and each person can pull up a list of their accounts, see, are they heavy product users or not? So not only do they have the users present, they can also see who's used the product and who hasn't. They can then segment people into churn risks or upsell opportunities. Someone who's heavily using your product is clearly already bought in. You don't need to talk to them to find this out, which means you can immediately target

## 20:41 — Billing and consumption reconciliation

**[20:41]** them with a script to upsell them on more stuff, knowing that they're heavily engaged. Someone who's barely using the product will not listen to an upsell pitch. They're barely using the product. For them, maybe an education pitch is warranted. Maybe there's some org dysfunction that's preventing them from using the product, but you can enter that conversation beginning with a different set of assumptions without having to be surprised. And so by far that tends to be most impactful. Billing is a big one. And again, in this day and age of AI with token consumption measurements and so on, a

**[21:18]** lot of billing infrastructure is somewhat split between your usual sort of finance systems and engineering, also owning some of the data and mechanics behind who has consumed what. You own the price books, you know how much to bill them. You just don't know what they've consumed. And you can call that product data. And certainly it's part of the product org, I suppose, but really your goal is to reconcile your finances and you need this. Who's using what so that we know who to bill and how much, have they exceeded overages or not? This is just pretty common in this day and age of consumption.

**[21:55]** And again, that's just sitting in some other system that can be synced in. And so you can imagine going from NetSuite or QuickBooks or whatever, and then you bring in this other proprietary billing information held by your engineering team in your CRM. And again, you've got your single window where you can see everything. Yeah, and those things, to highlight the point you were bringing earlier, all of this is to maximize revenue. So all of that data is helping your CS team execute plays that are going to help with retention or expansion, identify upsell opportunities for sales teams.

## 22:29 — It all comes back to revenue

**[22:29]** And then also make sure you're collecting the revenue appropriately because a lot of the analytics models are so complex. We've worked with companies where they're not billing properly or it's costing thousands and thousands of dollars of manual effort, manual work to reconcile everything. So you're definitely leaving revenue on the table or spending too much to go collect. Exactly. Our customers often ask us, they go, "Well, what data should I move and why?" And so on. And we'll always say, "Well, forget the data itself." Do you want to make revenue? And the revenue could be from street collections, could be from monitoring your overages.

**[23:09]** And again, that falls under collections. Or it could be avoiding churn, right? You are making revenue by avoiding a churn incident. You're keeping someone subscribed and paying money. And then upsells too. It's really exactly what you said, Anthony. It's all under the guise of making revenue. Everyone needs to put food on the table. We'd like to put as much food on the table as possible. And these are dimensions through which you can view the problem. And it just becomes, well, where's the data sitting? And Polytomical took care of that. Right. Right. Given your experience, I'm curious, I feel like this is a big problem.

## 23:41 — Org design: why RevOps and data live apart

**[23:41]** And I do think the way you structure companies tends to be one of the most important components of higher companies going to operate because at the end of the day, people will listen to their boss. So if my boss tells me to do something, I know that's usually my definition of success. And what you're saying earlier is RevOps teams usually living under the go-to-market organization. Data teams usually living under engineering. If you're an early stage company, you will have like RevOps working directly with the product or engineering team. And then if you're more mature, you may have a dedicated data team.

**[24:14]** But what advice, if any, do you have for breaking down the silos? What can RevOps do to help engage their engineering or data team? And if we have somebody on the engineering or data team listening, what can they do to help engage RevOps or maybe empathize with what they're trying to do? Yep. Certainly. Beginning with the RevOps side, well, beginning with either side, I think it's worth remembering that no matter what label we assign, companies, teams, business units, it's all human beings at the end of the day. The reality is, no matter what org charge you have, if the humans in question are not

## 24:52 — Breaking silos with empathy — both directions

**[24:52]** getting along, all bets are off, they could even be on the same team. Which is why it gets met. Because it's all human, so. Of course. Of course. There's no such thing as a company deciding anything. It's just management is deciding something and who are those managers, they're human beings. There are some particular moves, though, that do engender and foster these relationships. And so, for example, RevOps person going to the data team or engineering team with a request, that breeds partnerships and agreeableness. And I think empathy is a big one. I think simply starting with what are your current priorities, right? I'm here to be educated.

**[25:32]** There's a social aspect of sort of lowering yourself somewhat temporarily. I'm the ignorant person. You're teaching me something. And the topic happens to be, I'm ignorant about your priorities, but it really doesn't matter, right? Hey, what are your priorities? What are you working on? I'm curious. It's just a slight understanding of what their world is like. And that then, I think, opens up a discussion where you can go, well, we have this really important thing. And it feels to me like this is more important than X or Y that you've listed for these reasons. But you at least have an entry point rather than coming and going, listen to me, this

**[26:08]** is important. Get it done. Because the reality is there are as flippant as I was earlier regarding, oh, I was the traffic cop saying, no, thanks. There were some legitimate reasons sometimes where the VP of marketing wanted some complex attribution analysis that involved cobbling data from many places and understanding it and so on. And as a team, we were just very busy. At some level, the service teams, engineering and data, and they should see themselves as that for internal requests. Sometimes things do need to be kicked up to the org charts. You know what? VPN sales and VP of marketing need to tussle a bit and come back with priorities as to who

**[26:42]** should be listened to. But usually the engineering data people are just not aware of these mechanics at all. And it's really on the wrong person to come in, get educated, and then use that as an opportunity to provide some education of their own. Well, let me tell you about my world, let me tell you about my world and your priorities. I think the same thing can apply to the other side. Rather than some people do get a bit drunk with power, that sounds a bit crude, but it's maybe somewhat true, I think, where you just sort of your ego grows larger and larger every time someone comes to you with a request that's important.

**[27:16]** Rather than focusing on that, you start realizing, "Oh, I'm the important one." And you start sort of trusting your instincts, which frankly may be very incorrect. You do not work on these other teams. What may seem not important to you or trivial to you may be extremely impactful to the other side. And sometimes things are a bit perverse where something that can take you five minutes starts feeling trivial. You're a technical person. This only takes five minutes. How impactful could this possibly be? You're only saying this because you're in a position of ignorance. You have no idea how starved to the other side is for help, where these five minutes

**[27:50]** can really change a team's week if you just simply spend the time. So I do think it's on the technical people to also have this empathy and just find out, "Hey, what's on your plate? Tell me more. Why is this important? Who's going to be affected?" and so on. Because it works out quite well with the other side can't quite describe why this is important, in which case maybe it's not. Some requests are vanity requests, "Hey, I need help with this dashboard. Great. Who is going to be looking at it and making what decisions?" "Oh, I don't know." So-and-so just asked them, walked away, "Well, let's talk to so-and-so.

## 28:28 — Empathy as the theme; discovering new lanes

**[28:28]** Is this really important to them or was this an academic curiosity?" So it is on the technical side too, I think, to understand the other sides. And I suppose if there's a theme, not to sound too wooly about it, but empathy is a big one. Just simply understanding a little bit about the other side both helps you make better decisions and has the great advantage of engendering some level of understanding and partnership. I think that's really well said. And I think approaching things with humility, empathy, realizing, "Hey, we're all on the same team." At the end of the day, our company's trying to grow.

**[29:00]** We're trying to get more revenue and take care of our customers. So I think, you know, let's all do the most impactful things that can make it happen. Mm-hmm. Yeah, exactly. And you'd just be surprised. I think people in general, maybe if there's a general piece of advice for everyone, is you would be surprised which opportunities you spot if you open up your minds like this. You may think you know what lane you should be walking down, but I've been personally pleasantly surprised once I've discovered other lanes by complete accidents, just by talking to people. 100%. Gallop, I think this was really, really phenomenal.

## 29:36 — Closing

**[29:36]** And I think you actually created a platform that enables people to serve themselves and also build empathy to break down those silos. You mentioned, "Hey, this five minutes can help anyone." And I saw you were able to get product data into Salesforce in five minutes. So powerful. I'm really excited for our customers to see this. I'm excited for our general audience to see it as well. I just appreciate what you're doing. You're using your experience where maybe you are the cause of pain and correcting it, paying penance as you put it. I love that. And just thank you for what you're building. Thank you for what you've done.

**[30:12]** And really, really excited to see what you do next at Polyatomic. Absolutely. Thanks so kindly for hosting me as well. Thank you, Gud.