Turning Rage Design Into Culture with David Boskovic, Founder & CEO of Flatfile

(Intro Narrator at 00:00:01) Today, we're talking to David, founder and CEO of Flatfile, about the concept of rage design and harnessing discontent to build great products and workplace culture. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:19) I like to always start with the origin story. How did you get into technology as a whole?

(David at 00:00:27) Yeah. I'm just an obsessive person. And so when I find something I can do and enjoy doing, I tend to lean into it. And I started super young. My dad had a business. He needed a website for it, and I really wanted to build it. So my dad's business, and this is sort of an aside, but he's a violin maker by trade, so nothing in tech. And he ended up building a really large distribution business around violins and stringed instruments in Canada. So as a kid, grew up in a family business, and I wanted to do my part. I wanted to do something that I thought was interesting, so I learned how to build a website.

(David at 00:01:07) Fast forward three years. It took me three years because I rebuilt it three times. Learned how to code. I read, at the time, it was PHP. I read the entire PHP manual. And by the time I was done with that, I knew how to build software. And then, much to his chagrin, I started building software for everybody else and fell in love with it.

(Joel Beasley at 00:01:29) Nice. What was your first big project that took off?

(David at 00:01:32) First big project, for a few years, I built a lot of side projects for different folks. And then I was 19, and I was having dinner with a friend, and they worked at a large bank, and they were telling me about this project that had gone on for two years, and they'd just been told it was going to take another year. It was $4 million in the mud. And I was joking around, and I was like, oh, pay me $500,000. I'll do it in three months.

(David at 00:01:59) And I got a call the next day, and they were like, I told my boss about this, and he wants to throw $500,000 out there at the chance that we don't have to wait another year for this to be done. So I flew 10 of my friends into Alabama, believe it or not. And we lived in a house in Alabama for three months, and we built this internal banking software for a major bank. And after that, we got all the work we wanted. So that was the first big project that sort of kick-started the business part of this.

(Joel Beasley at 00:02:26) Yeah. Yeah. Alabama's the next Silicon Valley.

(David at 00:02:30) Apparently. I just had a friend who lived there, and he had a house. And I was like, all right, we're going to go live there for a while.

(Joel Beasley at 00:02:37) So you Canada, Birmingham, where are you at now?

(David at 00:02:40) I now live actually outside of Washington DC via Denver. Spent 10 years in Denver, but recently moved out to the Baltimore area. My wife has horses, so we have 10 acres. And I am almost finished putting finishing touches on my office, which is the upstairs of this horse barn. Now that might sound insane, but if you know thoroughbred folks, their barns are better than houses. They're beautiful. They're beautiful.

(Joel Beasley at 00:03:09) They call them barn dominiums. They're barn houses.

(David at 00:03:13) For the people that full-time take care of these horses. Yeah. So I'm turning that into this beautiful home office. So that's been a fun project.

(Joel Beasley at 00:03:21) That is awesome.

(David at 00:03:22) Yeah. Yeah.

(Joel Beasley at 00:03:22) So you're building this big office. Do you have an office for your team in the town or no?

(David at 00:03:30) No. So we're fully distributed. We were from day one. This is pre-pandemic. And, obviously, when the pandemic started, that felt serendipitous. But, you know, both myself and my co-founder, we've worked remote quite a bit in our careers. And so we lived in different cities. So the first decision was, like, hey, do we move together to build this company, or do we go remote? And if we go remote, should we be remote?

(David at 00:03:55) And the way we sort of tested this was it was sort of like what's good for the gander is good for the goose. It's like if we can collaborate well as founders remotely, then we're sort of the weather vane for whether or not our culture is functioning for the team. So, yeah, we're remote since day one. We have almost a hundred employees, all remote around US, Canada, and South America. And this is an interesting point on this. We actually, one of the biggest challenges with remote is finding the right place to work when you're remote. So yeah, I'm working at my home office, but we actually pay $10,000 to every employee. Well, we pay $10,000 to help people renovate a home office. So we actually have a designer on retainer. They'll pick a room in your house. We'll figure out how to make it the coolest home office ever.

(Joel Beasley at 00:04:37) Can I... that's the remote perk? Where's the application button?

(David at 00:04:41) It's on the website. There you go.

(Joel Beasley at 00:04:43) Do you know if it's forward slash careers, or when you go to the Flatfile web, it's just flatfile.com?

(David at 00:04:48) It's probably slash careers or jobs or something like that.

(Joel Beasley at 00:04:50) But it's clear in the...

(David at 00:04:52) It's clear.

(Joel Beasley at 00:04:52) You guys are hiring, basically.

(David at 00:04:54) We are. Yes. We're scaling up our engineering team, and it's... we think remote is a great way to build and collaborate and sort of get that space to step away and focus. One of the hard things with remote, though, is coming back and figuring out how to ideate together. So I feel like ideation remote is always a challenge. I think that's something we're still solving for. We do interesting things, like we'll fly people together to work together for a few days in an area in front of a whiteboard. One of the things we do try to avoid is actually having scheduled meetings. It's kind of counterintuitive, but the less people spend time in meetings, the more time they spend sort of ad hoc collaborating and engaging in ways that sort of drive things forward.

(Joel Beasley at 00:05:40) Yeah. It's amazing when I talk with, you know, whether it's customers or just other people. I would say our company culture is a lot like what you just described. And then I'll talk with somebody else who's chaining meetings back to back five days a week, eight hours a day. And I'm like, that's crazy. When's your time? When's your space to be curious and explore and figure out the next thing?

(David at 00:06:02) Especially for builders. I think, you know, for people working with customers or supporting or sales, there's a lot of meetings in their world. But for builders, a lot of this is taking time to think and be creative. Yeah. Yeah.

(Joel Beasley at 00:06:14) Yeah. I was specifically talking about internal meetings. Right?

(David at 00:06:18) Yeah. Oh, yes. Yeah.

(Joel Beasley at 00:06:19) Yeah. Yeah. Because some companies get crazy with them. Yep. Far, far too many.

(David at 00:06:24) I think there's now been actually a lot of ink spilled on this, but I think when a lot of companies went remote, you just fill everybody's calendars with meetings to make sure you have these check-ins. You're like, well, I can't... I'm not sitting next to you anymore. So here's a meeting for this and a meeting for that. And very quickly, people realized, hey, you can easily take up 40% of your operating time in meetings if you're not careful. So there's now been, I think, a lot of better hygiene coming out around sort of remote culture. And for a while there, it was chaotically bad.

(Joel Beasley at 00:06:53) Yeah. The reaction to not knowing how to measure it is to try to jump in there and control it. Right? So we worked really hard. I had always done remote teams until this company, and we started it in Florida. Pandemic happened, then we grew quickly because I was telling you earlier, we changed the business model. So we grew quickly, and we hired wherever, and it just scattered us across the US. And then we made a very conscious decision to get rid of the office and be fully remote because you can't do the second-class citizen thing. It just doesn't work out.

(Joel Beasley at 00:07:24) And it becomes like a they, them, you know, deal where you have two different camps, the people who are in office, people who aren't in office. So we went fully remote, and we've been doing fully remote with this company for about three years now. And we focus a lot on just figuring out the KPIs. What are the two or three things a position, a role can focus on that ultimately generates revenue or supports that somehow?

(David at 00:07:47) I think there's a profile of person that works really well remote as well. And this is, if you know what success looks like and you have the intrinsic motivation to pursue it, that's great. Because you're not going to have anybody sort of banging on your shoulder to keep you on track. And trying to do it, I think, remote is ultimately very hard. So that's one thing we filter for at Flatfile.

(Joel Beasley at 00:08:08) For at Flatfile.

(David at 00:08:09) It's just people with intrinsic motivation, people who are able to self-manage their time. So then it makes it easy. Right? Here's the problem. Here's what we need to solve, and you're going to be held accountable to solving it. So figure it out. Right? Pull people in, et cetera. And I think that's an interesting part that people don't really talk about remote. It's not just about, hey, you know, business-wise, are we set up? It's, is the team the right team to operate in this way?

(Joel Beasley at 00:08:32) Yeah. Josh is sitting over there like, does he sound like me or what? Everything I'm hearing out of your mouth, I'm like, this is exactly...

(David at 00:08:40) Oh, no. We agree too much. We're not going to have anything interesting to fight about on this podcast.

(Joel Beasley at 00:08:44) Well, I think your topic, one of your main topics is rage design. Right? Is that correct?

(David at 00:08:49) Did you have, like, a rage design topic? That came about in the weirdest way. After my Series A, I was doing a reporter interview, and they were asking me why I started Flatfile. And I think, yeah, we'd get there in the journey. But I was like, look, how many times do you have to build a CSV importer before you get fed up with it? And then for me, apparently, it was 13. But, you know, company after company, right, you have to go solve... you solve the same problem of customers being able to import data into that product. And I've been doing SaaS, and almost every SaaS product is an empty box, right, waiting for customers to bring something to it. A CRM or a HR product or whatever it is you're building, right, you're trying to optimize an aspect of the business. But the first thing is people have to bring their data. And every company always gets to this place where you're like, oh, we got to stop building the things that we wanted to build and build this customer-facing ETL experience.

(David at 00:09:39) And I was like, man, I was just so angry that I couldn't just go find something and use it. I had to stop our roadmap and spend three months building this that I spent the next two weekends rage designing this solution. And then the next day, the headline was like, Founder rage designs, raises $50 million to rage design a product or whatever like that. But it turned into culture at Flatfile. And I think that's... I was talking to somebody about this recently, but I think this active discontent is something that we don't really value enough in business. It's like the unhappy people are oftentimes, like, given the ability to be active about it, can be the best innovators. And so I've found that discontent is a feature, not a bug in a lot of areas as long as you lean into it. And so looking at the things that people are unhappy about can tell you a lot more about what they're going to do and spend their time on than things that they're happy about.

(Joel Beasley at 00:10:32) Well, we spend money to solve problems.

(David at 00:10:34) Yeah. Exactly. Right? So I apparently care a lot about CSV files. Yeah.

(David at 00:10:40) Or really the... I was trying to actually understand sort of why there's a series of things I've cared about through my career. And it comes to high-delta problems in innovation. Right? You're innovating and solving this business problem, and you've got this, you know, billion dollars of investment here, but somehow there's a massive delta between that and the person emailing over a spreadsheet full of data. Right? We haven't innovated in this area, but there's so much innovation here.

(David at 00:11:07) And so as the delta grows, the costs and friction start really materializing and slowing businesses down. And there's so many areas in the world where there's these massive deltas in innovation, and all of them keep me up at night. This is the one that I think is fundamental to unlocking most of the future innovation. That sounds like a founder thing to say. I know, oh, my company's unlocking the future of innovation.

(David at 00:11:32) But, dude, I was talking with this founder recently, and their company is an AI product that analyzes cancer research data. So it'll take seven years of cancer research and MRIs and metadata, and they'll plug it into their software, and it can basically early detect cancer five years before doctors can. It's pretty innovative AI. But it takes them a year to clean up the spreadsheets in order to run the analysis on the metadata. And if that doesn't... it's like we're spending a year trying to clean up data just so that we can access this innovation.

(David at 00:12:09) Sure. I don't care if you're spending a year adopting a new HR platform, but innovation is across all frontiers, whether that be technology and HR or innovation and sciences and any sort of fundamental problem like this where data... for us, data exchange, right, is something that is worth caring about because it holds the world back.

(Joel Beasley at 00:12:30) Would your product be something that could help them?

(David at 00:12:33) Yeah. So Flatfile is focused on that sort of problem of exchanging data. And if you think of ETL historically as a world where you have sort of data in one shape over here, you need rules, and you can move the data from that shape into another system. Flatfile lives in a world of what we call high-variance ETL, where every source is likely to be different, right? Every customer, every vendor is bringing something different.

(David at 00:12:56) So what you have to do is take every ETL problem and move the problem-solving part of it to the front of the funnel, right, the point of variance, because that's the only way it can scale. We've basically simplified ETL in a way where end users providing data, anybody who's providing data that's messy can clean it up as part of providing that data. So now your thousand customers or your 500 hospitals, they can basically hand you clean data.

(Joel Beasley at 00:13:21) That's pretty neat. Because when you were talking about it at first, me as my developer background, I was like, okay, so it's a mapping tool that... you know? And then so but, apparently, it's a lot more than that.

(David at 00:13:31) Well, when you think about the fundamental problem, right, it's schema resolution, right, between point A and point B. You're giving me data. I know it has the data I need in it, but it's just in a completely different shape. Now that shape might be as simple as you named your field F name and I need full name, but it might also be the fact that your data is in 5,000 PDF files, and I need it in a database. Right?

(David at 00:13:50) And so there's a whole world of sort of layers of extraction and schema resolution that have to happen. At the end of the day, it comes down to, hey, you handed me something that's called, you know, F name. Is it full name or is it first name? And Flatfile sees billions of those decisions every year, so we're able to predict with an extreme level of accuracy exactly what you mean. It's like we know it's a first name because it looks like a first name.

(David at 00:14:12) So you start being able to automate that and then reserving just the decisions for the user that are essential for them to answer. That starts making it, you know, taking away oftentimes thousands of hours of work in a data exchange.

(Joel Beasley at 00:14:25) So you can sit in between any data source? Like, can you sit like, if I have APIs? Like, for example, I did real estate software for a while, and they had this thing called RETS, which is Real Estate Transaction Standard. The funny thing about it is every single board, and there's 900 of them in the US, interpreted this standard differently, which completely defeated the purpose of the standard. So sometimes it could be called BDRM for bedrooms. Sometimes it'd be BD. Sometimes it'd be beds, you know? And so you've got this across 900 different sources. You're trying to aggregate all of them. And that was an interface through an API. Right? Would you guys sit in there at all or no?

(David at 00:14:59) Yeah. You can certainly plug in anything on the left side and anything on the right side. Our specialty is focusing on resolving the differences between those two things. Usually, if there's an API or existing connector for it, right, that's not where we're specializing. We focus primarily on transactional data, where your format of this is going to be extremely different. Some of that is API-based, but you see this the most in spreadsheets or CSV files. Right? Like, hey, here's my dump of data. It's like, oh, we have no idea what we're about to find in here. But what we've done is create experiences where, you know, in that example of BDR versus bedroom, right, you can easily make that decision in the UI, and you don't have to be technical for it. And so as a result, we get to learn from subject matter experts. Like, you're the real estate person importing this data. You just told us now that this means this, and we're going to see a hundred more of you do this. And after that, we're going to be able to know everything about real estate data that we possibly could want to in order to actually automate the transformation of the business side of this.

(Joel Beasley at 00:16:00) Okay. So you're organizing your learnings based off of some data they give you, and you're asking them about the data they're importing.

(David at 00:16:07) Yeah. And, you know, the net product of that is something that would take you hours or weeks of manual cleanup in a spreadsheet can now be done in seconds. Right? Drop a file, done. Connect an API, done. And this is actually coming full circle to the rage design problem. Developers oftentimes are given a business problem. Let's say in this case, right, we're trying to import a lot of customer data. Right? But before it gets to the developer, right, the business usually tries everything else. Right? They're, you know, support's doing it by hand. Right? And by the time it gets to a developer, it's now reached business-critical priority because, you know, building a solution takes time and it's expensive. So usually by the time one of these things gets to a developer, it's we've already tried everything else. And so developers are oftentimes put in a position where they have to solve something relatively quickly because it's important to the business, and you can do it a lot of different ways. And for us, and I think, you know, for companies like Stripe, you are the way the developer can win. Right? So, hey, here's a tool that helps you get to your objective as quickly as possible. And that's actually been interesting for us from a business learning perspective where, you know, early on, we were the import button. So if you're a SaaS application and you want to add your import contacts button in there, we've got you. That's a relatively narrow application of this problem. As we've grown now, we've become a platform where, as a developer, you can take all the building blocks and build incredibly comprehensive workflows. So, you know, if you need a sign-off process from a technical stakeholder, or if you need a compliance review in there, you can do that all with Flatfile. So we've opened this up to let you implement us in any workflow.

(Joel Beasley at 00:17:42) Yes. Rather than me making my own service to operate the rules and just using an import solution and then putting rules in, I can put the rules in the—you put in the cloud. What do you do?

(David at 00:17:51) Yeah. So, I mean, if you—I like the Stripe comparison. We describe Flatfile as, like, Stripe for data import. It's got all the APIs. You describe your destination structure, right? Your API. And then we'll take care of getting data into it, whether that's a CSV file or an Excel file or a pile of PDFs. We'll present the UI modules, take care of everything. So any sort of unstructured data into, ultimately, that target format. And the big problem there is UI. Right? It's like APIs can do a certain amount, but at some point, you need the customer or the person uploading the data to make some decisions about it. Right? Confirm, sign off, like, yes, this is the right financial metric to be using here. Because getting it wrong can sometimes have massive consequences for the businesses. So we've created UI experiences that allow these people to answer all those questions, and you can put that in your product or implement it in your flows.

(Joel Beasley at 00:18:36) That's pretty cool. Dude, I love it. I could not be having more fun building a company here. It's just so broadly applicable.

(Joel Beasley at 00:18:55) Do you guys think you're outgrowing your name, Flatfile?

(David at 00:18:57) No. Actually, I think the future of data exchange is CSV, and that's probably the craziest thing to hear. But I think CSV is interesting. Right? It is actually a really bad format, and it's because it actually has no standard. CSV just emerged, and eventually, I know the guy who wrote out the RFC. He just documented what was currently generally accepted as CSV. But CSV destroys data when you serialize it. Right? Like, everything's a string, and so, you know, trying to get data back out of it requires some judgment. So I think there's iterations on CSV to be done on the format. And we're about to launch CSV 2.0, which is a stricter format of CSV. That means you can serialize data without any loss. And with that, that actually creates the most portable format for data exchange. It's interesting. It's the most ubiquitous exchange format in data. Right? Like, if I ask you for a random Parquet format, you're not going to know what I need. The average person is not going to know what I'm asking for. But if I ask for a CSV file, someone's going to be like, oh, yeah. I can get you that from Excel. So I think everything eventually getting into a common exchange format is pretty important. So what we do on our end is we'll take your Excel file, convert it to CSV or our version of CSV. We'll take your PDFs, convert it into structured format. That's the first layer. And then from there, we pick up and normalize schemas. So CSV is the future. You heard it here first.

(Joel Beasley at 00:20:22) That's funny. You mentioned flat file, flat data structure. For some reason, I don't really understand that a whole lot. Can you tell me, like, an example of a flat data structure, like, what it is and then a data structure that is not flat?

(David at 00:20:34) Yeah. I mean, I didn't come up with the word flat file. That's existed for a long time, generally, to describe CSV or fixed-width format structures. And it's just, you know, can you put your data set into a file? And if so, that was described broadly as flat file. The other way of thinking about it is there's one row per record and then all of your attributes as columns-ish. Fixed width breaks away from that, and they try to put more dimension into a single row. But, you know, broadly, you can think of it as serialized file formats.

(Joel Beasley at 00:21:08) Okay. Yeah. And that's how you came up with the name?

(David at 00:21:10) Yeah. It was—yeah. The domain was available, and I was like, cool.

(Joel Beasley at 00:21:14) It was flatfile.com?

(David at 00:21:15) Well, not .com. That's another story. Yeah. That's an expensive purchase later on. Right?

(Joel Beasley at 00:21:18) That's an expensive purchase later on. Right?

(David at 00:21:20) .io was available. .com, I got from a welding factory outside of New Jersey, and they made these old flat file cabinets. And they're filing cabinets that take blueprint plans. And he did not—yeah. He was like, you want my—sorry. You want my domain, not my entire company? Yeah. Like, yes. Just the domain.

(Joel Beasley at 00:21:46) And then he—what did he change to, like, flatfilesomethingelse.com?

(David at 00:21:49) I don't know. I don't think he even realized he had a website. So it was—yeah, domain purchases always have the wildest stories behind them.

(Joel Beasley at 00:21:58) Yeah. Yeah. I have some, and I can't share them on air, but I can share them off air.

(David at 00:22:06) But, yeah, you know, it's interesting. I had said earlier, I'm a bit of an obsessive person, and so this is a problem I started obsessing about. And then it's easy to look at this and go, oh, interesting. This is a relatively boring business problem. But I was describing it recently to someone, you know, like Moore's law, right? Moore's law is an incredibly boring problem, right? Can we reduce the space between transistors on a chip by another nanometer or whatever it is, right? And can we do that consistently year over year over year? And the people solving that problem have led to almost every aspect of innovation that we have. Right? The people working on this core fundamental thing. I just fall in love with fundamental problems. Right? Things that are underlying every aspect of innovation. And this is one of those things, right? Like you can't exchange data. At this point in business, you can't do business. And that's another kind of crazy thing. I was talking to this grocery store owner in Northern Maine, and they're a farm-to-table grocery store. They get all their stuff from local farmers. They have a data ops person that works with the farmers to get all their data on the produce that's available. The person has a full-time job. Like, there is no area of doing business that you can do without exchanging data anymore. And, you know, twenty years ago, that could be a handshake and, you know, I know Joe, but now you just gotta solve this problem for us to keep innovating.

(Joel Beasley at 00:23:37) What's next for Flatfile?

(David at 00:23:39) Yeah. I mean, going deeper and deeper on this problem. Like, you know, fast forward a few years, our objective here is to make almost any aspect of data exchange instantaneous. I described it early on as the Tesla opportunity of ETL because you get to watch people actually solve these problems, unlike every other aspect of ETL where you have, you know, data engineers who know how to clean things up, but they don't know anything about the data itself. And so by putting all the problem solving in front of the customers or the vendors, you actually get business information from the decisions they're making. So you're going to turn that into something that basically makes data exchange completely automated and move on to the next problem in that area. You know, the ability to go deep on this is extremely high. Right? Like, it's like, hey, we've got Excel spreadsheets, but we've got this in banking, the banking industry, we've got it in the insurance industry, and then also, you know, a list a thousand miles long of every industry that has something like this. So, yeah, we're here to build one of the largest companies in the world just solving this fundamental problem better and better every day. And that's—the people we hire are people who also obsess about this and just want to really get good at this user experience around data exchange.

(Joel Beasley at 00:24:56) Oh, it's a very first principles approach.

(David at 00:25:00) You got my soapbox or, you know, my—are you a fan or not fan of first principles?

(Joel Beasley at 00:25:08) Of Musk.

(David at 00:25:09) Of Musk. Oh, this is a tough time to ask that question.

(Joel Beasley at 00:25:12) No. I'm a fan.

(David at 00:25:13) But I'm a fan of blasphemy. And I—

(Joel Beasley at 00:25:19) That's a less controversial—no. Explain this to me.

(David at 00:25:24) Well, okay. I grew up hyper-religious, and this is an interesting point to this. But I remember my family being shunned from the church for some religious decision, and it was—it's intriguing in that, like, I think there's ways that you get to a commonly held set of beliefs on, in this case, let's call it the church of business operating principles, right? And then breaking out of that is blasphemy, right? And I think that, you know, blasphemy is sometimes good, sometimes bad, but what it says is you're definitely breaking the narrative a lot. I think that's how you learn, right? We do this in engineering constantly. We do this—as kids? My kids do it. Yeah, yeah, exactly. Like breaking things is how you learn. And what's interesting is in these fundamentals about how the world operates and how business should operate and how you make money and how you scale things, there's commonly accepted principles of what is good and what you should do and what makes things work. And I think we don't break those things often enough to learn if they're still true, right? The world has changed a lot. And so, you know, I—you can go read a hundred books on business leadership, and you'll get a relatively homogeneous set of advice. And I think that's concerning, right? Like, I think as a world, we should break things more often. And, you know, the problem with that is sometimes there's negative effects of breaking those things, but I like blasphemy.

(Joel Beasley at 00:26:46) Yeah. Well, you gotta try new things and you gotta explore. I'm a very curious person, and I would actually say it's almost equally a weakness and a strength is my inability to see some of those walls. Right? Because, you know, socially, it sounds cool. Like, oh, I'm an innovator. Well, it's like, I just can't see some of these common things, or at least for some reason, I don't have this emotional connection to respect them. And it's not that I want to go against it necessarily or for it, but it's just, I don't know. I just kinda do what I want to do. I do what makes sense.

(David at 00:27:20) And that's hard. And sometimes it doesn't—you know, the narrative violations are oftentimes where innovation really starts happening. Right? Like, there's commonly held beliefs of this is how things work and should work, and then somebody changes the rules. Right? Like, hey, this is how taxis work. Well, somebody changed the rules. Right? Big narrative violation, and we have a completely new world we live in. I think there's a lot to innovate in in relation to business management and building companies. And I think as startup founders, we get to do that a lot, right? There's very few rules that are applied when you're fifteen people or thirty people. And especially with the way venture capital works, there's oftentimes a lot of freedom given to how you want to build this. What's interesting is in large companies, that almost always goes away. Right? Like, you probably bring in a management consulting company to any fifteen thousand-employee company, and they know how to run it. Soul crushers. But they're, you know, commonly accepted principles. This is actually—we can get into this here. I'm trying to hire a VP of Engineering right now. And one of the things that I refuse to accept is the VP of Engineering who doesn't build things.

(David at 00:28:32) There's this—and I've worked for a bunch of them, and this is no knock on it—but building is the most important part of engineering. Managing the engineering team, I get it's important, but I think being able to build and create and be a craftsperson alongside the engineers garners a level of respect for the direction, the decisions, and the trade-offs that are being made that you don't get from someone who's living behind a spreadsheet, mostly doing recruiting, etcetera. And so I'm trying to hire for this sort of VP/CTO hybrid, where you're the best engineer on the team, but you're able to scale this up to the next 500 engineers. And it's like the recruiting firm on this, and it's like a relatively narrow set of criteria.

(David at 00:29:20) Because oftentimes people actually optimize relatively early on for a management path or a building path. At Flatfile, I have this rule on the engineering team that everybody on that team builds. Right? So we don't have purely administrative roles. We don't have product managers.

(David at 00:29:34) Right? You have tech leads who can sort of make product trade-off decisions. Even the sort of operational, I have a build ops person who is responsible for keeping the system flowing, but he also delivers features. I think that's important, where everybody's able to sort of get their hands on the problem in the business and build. And for an executive, especially, if there's a problem here, my expectation is that you can never sort of identify it as a people problem.

(David at 00:30:01) Like, I don't have the right person here. I'm going to go hire another person. It's like, well, if you don't have the right person here, solve it yourself, and then go hire the right person. We're too early as a business to make this a hiring thing or a process change thing. Everything has to be solved by building.

(David at 00:30:18) So everybody builds as a culture, probably because I'm a technical CEO, but it's done wonders. And I think we've made some missteps along the way, and we started building a little too much process early on. I know actually, I think in your book, you talk about scaling too fast a bit. But we definitely did that early on.

(David at 00:30:35) You raised a lot of capital. You're like, alright, we need to scale this up. We get a bunch of managers in place. And before you know it, everything grinds to a halt.

(David at 00:30:42) And so we did a bit of reset where we got back to this core culture of building. And in two months, we built more than we built in a year just by shifting this mindset back to this active building mindset.

(Joel Beasley at 00:30:54) What size is the engineering team currently, if you're sharing that publicly?

(David at 00:30:57) We're about 20 people right now.

(Joel Beasley at 00:30:59) Okay.

(David at 00:30:59) So, yeah, 20, 25 people and scaling it up pretty significantly.

(Joel Beasley at 00:31:04) Yeah. So you're really early in engineering team size. When you said 100, I thought at first, well, he has 100 engineers, but—

(David at 00:31:10) It's not the whole company. He's 100. Relatively early there. But I was at this summit for growth-stage founders a couple weeks ago in Lisbon, and we were talking about this. And if you ask someone who's built a company up to 500 employees and they're a technical founder and you ask them how they've maintained the pace of execution, you get this thousand-yard stare.

(David at 00:31:31) And they're like, oh, man. I just, like, it just—you can't. It just eventually slows down. You can't solve it, etcetera. Maybe coming back to this question about Elon Musk, maybe that's not entirely true. Maybe you can be a big company and you could execute quickly and you can sort of make fast decisions at sort of close to the metal.

(David at 00:31:52) And so, but what's interesting is I think a lot of founders actually give up on that. You know that you can move quickly. You know you make these decisions, but you actually lose the ability to expect that from your team. And that's one thing that I refuse to allow myself to do. If I would expect this from myself, then you better be better at it than me. I'm not going to give you the disrespect of thinking that I could do it and you can't.

(David at 00:32:16) And so, this is actually true of the executives and all the way down. You're hired because you're really good at this thing. Right? If you're going to be the engineering leader at Flatfile, you should be the best engineer. You should be able to solve these technical problems. You should absolutely be able to sit down in any of these architecture conversations and contribute and help make the decision and know when the decision's bad and be able to be part of that conversation.

(David at 00:32:41) I think that's a very controversial position, but I think it works.

(Joel Beasley at 00:32:47) It's hard to find that person.

(David at 00:32:49) It is. I've been interviewing for this role for a few months now. Gotten close, but I think—okay, I actually think this person exists more than you think. Because if you talk to engineering leaders and you're like, what don't you like about your current role?

(David at 00:33:06) When I back to this point of active dissatisfaction or discontent. When I hear, man, I feel like we've just gotten super process-oriented and everything's sort of like checking a box and there's nothing to innovate on anymore, and I want to go solve problems again, that's a feature. Right? And I think those people have oftentimes sort of optimized for the career opportunities that are available for them. But if you're a builder at heart, and then you've sort of lost the ability to create and build because that's just not how business works, I think those people actually very much exist, and they're the people that I'm really connecting with and thinking about for this leadership role.

(Joel Beasley at 00:33:42) Yeah. No. They definitely exist. They're rare, special people, though.

(Joel Beasley at 00:33:46) I don't think they're super—I mean, look. I think the narrative that there are these engineers out there who want to get back to getting things done. Yeah. I think that's super common. I don't know how many people there are that want—I'm thinking in my own personal Rolodex right now.

(David at 00:34:03) I know a couple of these people.

(Joel Beasley at 00:34:04) The problem is the people that I know that are really good at it—

(David at 00:34:07) Yeah.

(Joel Beasley at 00:34:07) They've built companies successfully, sold them off, and they have a bunch of money, and they're kind of hanging out right now. And I'm like, well, maybe I should tell them, introduce them or something. But it takes a while for them to get bored and then—

(David at 00:34:20) I mean, I think boredom comes from not being able to apply everything that you—all of your skills against the problem. And if you say, like, hey. I know you spent 15 years as one of the best engineers, and now but now all you do is review performance reports and sign off on the next quarter's agenda. And I'm not being somewhat dismissive of the hard work VPs of engineering do.

(David at 00:34:43) But, no, I think it's like you need to feel like if you have the skill, you're applying it against the problem. And so I've had some incredibly exciting conversations with leaders where they've gotten the chance to do both, but they've not gotten the chance to do them together. That is the company I want to build. And so I actually have this all the way through. We have no middle managers within engineering.

(David at 00:35:04) It's, you know, small teams with tech leads, and those tech leads report up to me at this point. But, you know, this future engineering leader.

(Joel Beasley at 00:35:12) And you're just going to roll with that until you can't?

(David at 00:35:15) I hope we can roll with it indefinitely. And there's some evidence that you can. Right? There's companies who have tried this and done this quite, tried this now, and I think jury's still out on how effective it is. But what I don't ever want to become is that CEO, you know, three years from now with a thousand employees where you ask me, and I'm like, uh, don't make me talk about it. Right? We haven't been able to ship anything meaningful in six months because of this process that everything grinds through.

(Joel Beasley at 00:35:43) I don't think you'll let that happen. I'm not the type of person to let that happen.

(David at 00:35:46) It's amazing how often it—I mean, yeah. I think you've gotten in to fix some of these things. But amazing how often it happens, man. People start scaling and just you stop shipping.

(Joel Beasley at 00:35:55) I guess what I wanted to say earlier was that I agree with you when that person exists. The thing that was sort of bothering me that I'm trying to articulate now is that, take away engineering entirely.

(David at 00:36:07) Yeah.

(Joel Beasley at 00:36:07) The human that can sit there and decide that, hey, I'm going to run this. Like, Elon Musk just walked into Twitter and he's like, this is what we're doing. This is how—that person is fairly rare. Yeah. I try to hire people like that all the time at our company because I'd say 80-plus percent of the workforce is like, tell me what to do.

(David at 00:36:31) So I think this comes back to sort of who you hire at a company like this or at any company where you want this to be the culture. I think that is a very hard remote where, hey, we want people who are able to sort of manage their own time, not have to be told what to—you're all one step in the right direction there. But then when it comes to, you're like, hey, we're going to cut out the management layer as much as we can, then you have to have people that are able to make decisions and be comfortable being wrong because that's a skill that people have to learn. Right?

(Joel Beasley at 00:37:01) That's a maturity thing in life. You have to wait for people to hit that stage.

(David at 00:37:05) So what's interesting is I think it comes down to the framework of accountability. Right? So traditional accountability matrixes within an org are built sort of optimizing for the mean for the most part. Right? Like, hey, how do we get the average person in the business to perform? And then managers are there to sort of get the low performers up to the mean. But a manager's job is rarely set up in a way where they can make everybody a top performer. Right? There's almost a competitive aspect of that sort of implicitly in there.

(David at 00:37:36) You can only have a few top performers. And I know there's a lot of management practices that have evolved to try and optimize more for that. But I think the thing that gets there the fastest, and I think this is something that's really changed things at Flatfile meaningfully, is being able to hold individuals accountable for outcomes versus sort of collective organizations. And that requires the ability for that individual sort of in leadership to actually do the thing that you're asking them or their team to do. Right?

(David at 00:38:06) If your only job is to manage the outcome, then that's a very different type of management than if you know exactly how this sort of thing is built, how it can be crafted, how people make the trade-offs, etcetera. The number of times, I think, as leaders, we've gotten into sort of a retro, we find out somewhere in there a mistake was made and it was because communication was poor and the manager wasn't sure why we were making this trade-off, etcetera, it is extremely high. Right? And that ability for decisions to be made by people who understand the problems that they're dealing with, I think, is critical to pace and sort of accountability in the business. I do not believe it is necessary for there to be purely middle management within most build functions.

(David at 00:38:51) And I think there's people who swear by this, and it's like everybody who leads has to be able to do the thing that they're leading. That's how I think about leadership in engineering at Flatfile. If you're owning the thing, if you're making the decisions about it, you better be able to tell me everything about that decision. And if you're managing the execution, you also have to be doing that. And that's where the sort of management layer starts getting messy.

(David at 00:39:13) Oftentimes, you start scanning these teams where the people sort of managing the execution of it aren't necessarily the people who really know how to do it.

(Joel Beasley at 00:39:20) Yeah. And that's almost so far from reality in my life, it's hard for me to understand. Because I don't—I guess my company is smaller.

(David at 00:39:28) Yeah.

(Joel Beasley at 00:39:28) Right? And so I don't run into it, and I haven't worked at a larger company. I believe you when you tell me that these people exist.

(David at 00:39:35) Oh. The people who—

(Joel Beasley at 00:39:38) No. The people who—

(David at 00:39:38) Well, no. Right? There's a lot of people listening to this podcast. The question is, does anybody—has anybody who's built the engineering org believe in this world where the entire tree in the engineering org can be builders? Or is it absolutely necessary to end up with this sort of management layer that starts optimizing the mean?

(Joel Beasley at 00:39:57) It's hard for me to believe the management layer that doesn't know how to do the work.

(David at 00:40:01) Oh, interesting. That's what—

(Joel Beasley at 00:40:02) I'm saying. I'm on that side of the fence because I'm like, alright. If I'm going to—let's say that you pay me, and I'm going to go work at a biotech company and manage scientists because you like my podcast. Right?

(David at 00:40:17) Job offers to [email protected].

(Joel Beasley at 00:40:18) And I go to that biotech company, and I run a team of scientists that are trying to achieve this result of some blood thinner drug or whatever. Right? How on earth am I going to do this? How am I going to have confidence in what's going on? How am I going to be able to pull people out that are incompetent or that don't have the skill set that we need?

(Joel Beasley at 00:40:39) How can you do that effectively? And the answer is you can't really do it effectively. You can do it very inefficiently—

(David at 00:40:45) Yeah.

(Joel Beasley at 00:40:45) Right, where you get a bunch of bloat, but I would never run my company like that. I hope I wouldn't.

(David at 00:40:51) Yeah. I mean, it is interesting because I think a, this sort of comes to some of the impact of venture capital on companies that, you know, grow from five people to 5,000 people in just a few years. You know, we have examples of these companies who've literally gone from 50 to a thousand in nine months. Yeah. And you're like, the only way you could possibly effectively do that is if everybody's sort of operating their world like the original startup.

(David at 00:41:20) Right? Where decisions are being made ridiculously close to the metal, and that's chaos. That is pure chaos. And so many business systems are designed to actually avoid chaos and thereby, right, start optimizing for process and slowing things down because you have to make sense of them. And I think chaos is mostly a feature.

(David at 00:41:40) There's this example that I learned from this one engineering leader. He's like, there's two ways you can build an org. You can build an org as a cathedral, or you can build an org as a bazaar. And I'm like, I'm the bazaar guy. Right?

(David at 00:41:51) It's noisy. It's a little bit smelly. There's three different vendors selling the same thing.

(Joel Beasley at 00:41:56) Everyone gets a lot. Yeah. Yeah.

(David at 00:41:58) And guess what? Things are getting done there. Right? And they change shape every day, and you can sort of ship—apply this to engineering. Right?

(David at 00:42:05) You can ship a lot of things quickly. And, yes, there's some chaos that comes with it, but your pace of innovation is so much higher than if you treat it much more like a cathedral.

(Joel Beasley at 00:42:15) Yeah. Yep. No. I like that. Yeah.

(Joel Beasley at 00:42:17) Yeah. I'm a big fan of, you know, because I told you my background, software engineering. And I'm just thinking through all the times where I was running the team because while I haven't worked at a large company, three separate times I've gone from myself as a sole engineer to building some basic variation of it or proof of concept, to building a team and through it becoming teams of teams. And the entire time, I never ever hired a manager that's not at least coaching the engineers. They might not be responsible for features.

(Joel Beasley at 00:42:53) I'll give you that because I'm just trying to be honest. There's been times that they're not responsible for features, but they are 100% involved in code reviews and coaching the people on code structure and best practices and things like that. And there's always one rule when I hire these people. They have to be better than me. I only hire engineers that are better than me. And so that's my rule.

(David at 00:43:15) Yeah. No. I think it's good. I think the question is, can you play that out across the entire org structure as you grow? Everybody generally agrees you can do it early. Right? You can do it. Two, three best engineers end up leading the team, et cetera. But at some point, right, this seems to fall apart for everybody.

(David at 00:43:33) And eventually you get to these—and as a consultant, I'm sure you've joined companies where you're like, we spent three months shipping a button? How did that happen? And you get into it, and it's like, somewhere there was scrum run every day on that button. Right? There is a process. There is a system in place, and we shipped a button in three months. Right? And that can happen. It happens a lot. And I think, you know, I think it's actually very hard to prevent against that based off of just what we see and sort of how a lot of these companies have been able to scale.

(Joel Beasley at 00:44:02) Do you think tech coming out that makes it easier, like LaunchDarkly? They're a company that does feature flagging, but they do it on a whole other level. A lot of people roll it themselves. Right? But I got to talk with them a couple times and see what they were doing, and I thought it was pretty interesting. But do you think that the technology of, you know, them taking it from a GitHub project that some people know about and then making it into sort of a business product and then them teaching the businesses and all of that, do you think that's affecting our ability to get stuff shipped?

(David at 00:44:36) I mean, I think she's built an incredible company there, trying to do that as the core ROI. Right? You can build faster, iterate faster, you know, give teams the ability to move sort of independently while reducing risk for the business. To the extent that there's operational solutions, I think that we will continue seeing innovation there. You know, for me as a CEO trying to build a company from scratch and trying to avoid these problems, it primarily has to be a cultural solution because operations will grow as the company grows, but hopefully in as light a way as possible.

(David at 00:45:11) And so I think for me, it's like, what's the cultural thing that avoids us sort of grinding to a halt? And I've already experienced this in just, you know, the three years building this company, where if you look away for a minute or if you start treating it like a process problem, it will very quickly start falling apart. And so I think to the extent that things are process problems, I think that we've missed a step. Right? If it's an individual accountability problem, that person will build the process they need to make sure things get done. And so I think what I found is at Flatfile and historically at other companies, the best way to sort of get rapid change is just make individuals responsible and hold them accountable.

(David at 00:45:55) And accountability is one of these beautiful things where, people want ownership as engineers, especially. Right? I really want to own this thing, and I want to be responsible for the decisions. But accountability is the beautiful part of ownership in that if you're accountable for an outcome, you, by default, have all the ownership necessary to produce it. Right? But if you're given ownership of something, you're not necessarily accountable for it. It's this interesting sort of bifurcation of the way we think about, like, if I say, how am I going to give you ownership of this component?

(David at 00:46:27) Okay. That's great. You have ownership of this component. Um, and we need to ship it in three months. Wait. Wait. Wait. I thought you just told me I own this component, but you're telling me now that I need to ship it in three months. Hold on a second. What if I—

(Joel Beasley at 00:46:42) I'd cut scope. Alright?

(David at 00:46:44) But now you're like now there's a question about how much you actually own. So, you know, it's like, okay. But you don't own the timeline. But then you start building, and it's like, well, you know, somewhere along there, you get feedback from someone maybe outside of your org or higher up. Like, hey. I really don't—you think you should build the component this way. Well, I have ownership of this component. So now there's going to be some defensiveness around this. Like, now there's going to be some contention around there.

(David at 00:47:09) And ownership oftentimes starts emerging that way where people just want to have these special things that they own and feel like are theirs. But I don't give out ownership. I give out accountability. It's like, you, the best way to get responsible for something is to just take accountability for it and get it done. And then from there, right, the feedback cycle actually starts emerging very differently.

(David at 00:47:31) Hey. You're accountable for shipping this thing by this date. Now feedback, trade-offs, everything's there in service of what the measure of judgment is for the individual, and then you can lose your job over not doing these things. So take your accountability seriously as no longer this sort of protected area of building that you just own. It's you have an objective in the business. You have to deliver.

(Joel Beasley at 00:47:57) Yeah. There's a guy, Adam Barrett. He's going to kill me for ruining his last name, but he's coming up. He's coming to the house in a couple months, but he's been on the show before. He wrote a book about—he did a lot of work popularly with reliability engineering inside of manufacturing.

(Joel Beasley at 00:48:15) Yeah. And when I talked to him the first couple times, he was saying virtually exactly what you're saying. Yeah. When you're shipping physical product, it—I thought it was pretty cool for him to come teach us the difference between, like, building a heart monitor and then releasing that because you build the hardware—

(David at 00:48:31) Right. Right.

(Joel Beasley at 00:48:31) From nothing, and then you put it out into the world. So there's a whole different set of design. And when you're doing that, the timelines matter even more.

(David at 00:48:39) Right. Right. Yeah.

(Joel Beasley at 00:48:39) Because software, you can kind of push stuff and you can wiggle a little bit differently, but when it's hardware and it's shipping to stores and vendors and stuff, so he was describing exactly what you said. So there's some external proof for what you're saying.

(David at 00:48:52) Yeah. And I mean, what's really interesting is, like, you take the variables away and everybody knows these things on first principles. Right? Like, you and I are experienced engineers. I ask you to build something. You can immediately see all the parts in your head, and you can go do it. And you can make all the decisions necessary to get it done. But somehow you start adding team and adding process to that. People stop using those skills as much.

(David at 00:49:19) Because they're like, well, hey, this component, they said it was going to take an extra two weeks. And you're like, but why? Right? If you're going to unpack that, you would never have made that decision. But somewhere along the way, right, we start letting these areas just devolve. Right? To maybe the decision was right, but it wasn't right for the outcome. And I think the ability to scale a team and keep that individual accountability, make the team decision just the same way you would make it for yourself and not let anybody make excuses sort of down the chain, it's magical. Right?

(David at 00:49:47) And it's not micromanaging because you're not making the decisions, but you're holding people accountable to the outcome that you think is right. And there's this element of respect that you don't get out of traditional sort of management processes. It says, hey, I know I could do this really well, and I also know, and I expect you to do it at least as well. And, oh, I'm not going to accept anything less. And this is for, I think every engineer who's ever become a manager. Right?

(David at 00:50:19) You go have drinks with them later. Like, oh, man. I can't believe it's taking us so long to do this. If you just gave it to me, I would've just gotten it done in a week. Right? This is the most common refrain—

(Joel Beasley at 00:50:27) Conversation ever.

(David at 00:50:27) Yeah. And you're like, but that is a problem. We allow that to get pervasive. Right? The people who are leading sometimes are not empowered to make really tough decisions on their team about how to get it done. They literally are sitting there laughing about or like, woah—and we've all been there, right? We're laughing about the fact that we can't do anything. Our hands are tied. This is going to take us three months.

(David at 00:50:53) It could have just taken us three days. Right.

(Joel Beasley at 00:50:55) And—

(David at 00:50:55) I think it's empowering the leaders to keep operating the way they are when they're individuals as a larger org is hopefully the solution here.

(Joel Beasley at 00:51:04) One of the things I found, so I'm going to check this with you. Yeah. I used to get really frustrated that some of this wasn't happening as well as I'd hoped it would. Um, and then I realized—I don't know who I heard. I heard somebody, but the bottom line was I realized that I needed to be continuously vocal about the behaviors that I wanted to see happen.

(Joel Beasley at 00:51:23) Because by default, I will just go do things. Yeah. But other people, you know, because I'm the CEO and the founder and everything. Other people are scared or hesitant. They're working for someone, you know, type deal. Yeah. And so I'm constantly telling people, like, hey. You know, ask for forgiveness. Go figure it out. You know, go charge towards this objective. Yeah.

(Joel Beasley at 00:51:43) Here's the outcome I want. You can figure out how to get there the best way you can. And if along the way I see you doing something that I think is unacceptable, I'll help correct you, but I'm not going to hold your hand through the whole thing.

(David at 00:51:55) Yeah. We have this rule at Flatfile called "plan lightly." And it basically says, for the most part, planning a lot is hubris because it implies you think that you can figure everything out before you get started building. Right? And so when I see plans taking more than a week to build for pretty much any area in the business, it starts looking like a bug. Right?

(David at 00:52:22) So it's like, hey, what could we build that sort of like get iterating towards this outcome. Don't spend too much time trying to get it right before you start going. And there's—this is actually really important to enforce because there's an artifact of doing something that you planned for a long time. That is when you get to the end of building that first version, you are really closed to feedback. Right? You will literally hear people say, the time to give feedback was before we started building this, you know, when we were in the planning stage. And like, no, build your first version in a way where you could throw it out every single time. Get moving.

(Joel Beasley at 00:52:58) I love this.

(David at 00:52:59) Because it's culturally critical to be willing to accept feedback on something you've done. Right? That PR you put up, if you're not willing to delete that PR and start over again, you spent too much time on it. Right? So when that senior engineer comes in and is like, oh my god. You did this with this particular way, but if you do it this other way, it's going to be so much better. That shouldn't feel like an insurmountable point of feedback. There shouldn't be this like, oh, man. I just spent a week building this thing, and now you're going to make me go back to the drawing board on it. And so it's interesting that the amount of time you give people to do that first version actually affects culture very meaningfully.

(David at 00:53:34) And it is so critical to get that first version, get everybody feeling that first version can be a throwaway if necessary.

(Joel Beasley at 00:53:41) I love the feeling of when new team members started to realize that this is how it operates. Like, at our company, they'll be like, oh, we just do it like that because—the phrase I use is—when I was doing software, it's like I should be able to—well, when I was doing software, it's like I should be able to drop dead and there should always be a version that's working that's really close behind it.

(David at 00:53:57) Right. Right. Finding people who are high energy and finding people who are really skilled and then finding people who just want to build is what I'm about here, and that's what the culture is at Flatfile. Ridiculously high energy, and we have so much fun just building stuff.

(Joel Beasley at 00:54:11) Where did this come from? Did this come from you watching your dad's business operate? What's this energy, this attitude?

(David at 00:54:18) I think that sort of founders have to be, to some extent, idiotically audacious. And I just generally have a high level of confidence that I can solve problems, um, and that leads to trying. Um, and so I think that's what I've done since I've been young, whereas I wanted to build a website. I didn't know how, but I was like, I'm sure I can do it.

(David at 00:54:41) I think that does come very much from the reinforcement. So, you know, got young where it's just like, hey—or my dad is a hardliner. He'd just be like, hey. Go do this. And, like—

(Joel Beasley at 00:54:52) You'd have to figure it out.

(David at 00:54:53) I'd figure it out. Right? And, you know, sometimes that's tough. Um, but I think at the end of the day, you start really believing that you can. Right? After you successfully do something that you weren't sure you could do a couple of times, you start really leaning into it. And I think that audaciousness is important in children, for sure, to help them grow and learn. But I was reading this book recently. I can't remember the—or it was called—recently from a book. It was just like, the—we lose the more we lose that sort of inner child, that curiosity, or that sort of willingness to experiment and break things, the more we grow up.

(David at 00:55:30) But growing up is sort of this implicit slowing down of growth and learning and innovation. I think the features of childhood, right, are bravery and audaciousness. And I think those features, if you can bring them over into sort of adulthood and into your career, they can take you a long way. If you can learn as fast as a five-year-old, you'll never stop learning.

(Joel Beasley at 00:55:53) Yeah. The way you get that is by doing difficult things and that builds character. Yeah. I like it. Alright. So I think we're good. I think we did everything. Sweet, man. We made a podcast. How do you feel?

(David at 00:56:02) We did. I love it.

Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.